当我们去做一个项目的时候会脑海中提前预估项目的投入和收益,因为有资源占用的问题。

    因此也就决定了项目的优先级别,所以当我们的项目真正投入到上线后的过程中我们会综合算出项目的效果,这里的效果指的就是投入和产出比是多少。

    但是总归还是会遇到不好估算的项目,比如只是用户体验的优化呢?
    产品迭代如何量化收益 - 图1
    This photo is ©A倪吖

    我们一般正常会碰到两种项目优化的结果。
    1、数据提升
    2、数据降低

    1、数据提升
    这个部分说的是应该提升的数据,比如说订单总量、用户新增、用户日活、活动有效参与量。这些数据的提升占据了绝大部分的前台项目的数据汇报。

    2、数据降低
    这个部分相对于前台来说就是后台效率提升的问题了,比如人工数量的降低,操作时长的降低、操作流转次数等等。是比较能清晰地划分为和数据指标考核的。

    3、不太好量化的收益问题
    今天其实是在想一个不太好考核的数据指标,这部分是用户体验优化后带来的疑问。比如说我们设计小组进行一次页面的调整优化,用到的资源就是设计团队和部分前台的研发团队。

    那么综合人力就是:
    页面设计2人/天
    前台研发4人/天
    测试人员3人/天

    但是带来的是什么?这是一个比较难以衡量的数据标准。其实仔细想一下是不是将口碑提升加入提升收益的范畴。

    1、口碑体验提升多少,可以从已有的比如NPS项目中来考察用户对于新优化的页面的整体评价
    2、如果页面有综合业务的入口,比如有一个商品或者多个商品的聚合入口,那么这些入口的点击是否比之前的要高。

    想到数据又想起来前两周做的项目,因为是后台项目所以综合的项目目标是:提升操作效率降低人工时长。

    结果是我们做到了21%的降低效果,但是同时也发现了很多小的问题。

    真实的使用场景中来说,就是他们每个阶段想看到的信息都是不一样的。

    比如A同时仅仅关心的是最初始的信息展示问题。姓名,订单内容。
    B同事看的就是订单的一些政策性问题和备注性问题,以及和外部客户互动的信息。

    所以这些都是要增加提示的,在主要信息节点的时候设计认为这个姓名就是一个正常的信息,但是在操作人员手中这是一个首先要阅读信息。

    然后在信息报给服务商的时候会遇到明显的有些名字生僻导致无法阅读给服务商。这时候如果可以解析名字又变得比较重要。

    所以综合考量来看一部分数据指标的降低带来的是项目操作效率的提升,一部分数据指标的增加带来的是阅读的困难,信息模块划分的不清晰。

    所以从简短的上线后的数据上来看就能发现问题,及时的补充。当真正的使用人员反馈问题的时候不是不加思索而是分析自己最早设计的初衷与目前问题的差距在哪里。

    这个的差距就是这个项目当中我们取得的经验,所以还是很重要的要频繁的看数据来调整项目。

    接着来反思一个问题,为什么苹果的设计很多系统中的设计没有经过很多的改动?

    说明苹果一次性解决问题的能力还是尤为突出的,像微信的基本架构一样,除了最近的公众号和小程序在不断的调整。

    大的方向来说是正确的,但是在实际的执行过程中遇到了与自己设想不太相同的结果。
    这个就是我上面的所说的“差距”或者叫“经验”的积累。然后将公众号和小程序标的更加的完善。

    总体来说:
    小程序还是满足了即来即走的目标设定,完成简单的操作了流程,尤其是简单的不频繁的需求,比如停车,比如电影票,比如付款,比如点单,比如会员收集,比如叫个车。
    所以小程序满足的还是企业的需求比较多。然后反过来解决用户需求。

    综上:

    1、想透了用户体验也是可以衡量的只不过是好衡量和不好衡量的问题,以及从哪个维度衡量。
    2、在真正的项目中及时出找出设计和现实的差距是一个设计师从专业到优秀的一个提升过程,所以频繁的数据验证和用户调研必不可少。