相比 5 年前，明显感觉，资本对产品投资回报周期要求越来越短。
出于盈利的需求，产品的变现必须要影响用户体验？
怎么在用户体验与商业价值之间取得平衡？落到公司内部，保证产品持续健康地发展是个难题。
运营背负 KPI，业务驱动，关注的是短期利益。没有太多心思关心用户体验，往往会提出「割韭菜」的想法。
设计重在审美，感性驱动，关注的是界面优雅美观。少有人去理解功能背后业务逻辑，设计出来的界面缺少业务驱动力。
产品重在功能，任务驱动，关注的是上线发布。受之于各方资源协调，产品功能难有长足的规划和设计。
用户体验 VS 商业价值
用户体验与商业价值看起来像是跷跷板，有一边高，就有一边低。公司存在的价值本身就是盈利，业务自然会受 KPI 驱动。除非是初创公司，刚开始为了获取用户，用户体验至上。但这个时期不会太长，就会受营收增长的压力。
当营收压力过大时，为了获利快速增长，对用户体验的关注就不够。
滴滴打车是典型的例子。由于各个城市政策限制的原因，能够申请滴滴司机的人数有限。而司机人数不足，对用户及时约车的影响非常大，这也直接影响到滴滴的业务增长。
有限制必然就有人钻空子。有人在淘宝提供认证服务，利用外挂绕过「滴滴出行」软件视频认证程序进行虚假注册，帮助那些不符合条件的司机认证通过。比如，驾龄不够，车辆不符合条件。如此一来，必然会吸引不法分子趁机混入其中。
关于司机虚假注册的信息，在过去几年里，一直都有报道，滴滴肯定是知道这些事情。从安全管控力度和客服响应的速度来看，滴滴对安全重视的态度是远远不够的。甚至在乘客的隐私上，采取激进的态度。司机可以对乘客打标签和评论，这些内容对所有的司机都是透明的。空姐事件中，有些司机对该乘客的评论很露骨：「不化妆也漂亮」，「美女下车时丝袜容易走光看的想入非非」等等。
如果滴滴能严格把守安全底线，类似安全事件肯定少很多。更何况，对滴滴来说，用户安全应是用户体验中的重中之重。
Google 的 HEART 框架
当有人关注量的增长的时候，需要有人关注质。这种压力不仅来自于未来可持续性发展，也会来自于用户的反馈和竞品的差异化运营。现实的问题是，
如何将用户体验与商业价值绑定一起？以用户为中心，通过量化的视角，既能够驱动业务的发展，又能兼顾良好的用户体验。
Google 内部，用户体验有一套数据框架：HEART 框架。这套框架在几年前，已经应用了 20 多个产品和项目。
Google HEART 框架从五个维度去衡量用户体验：
Happiness - 愉悦度
Engagement - 参与度
Adoption - 接受度
Retention - 留存率
Task Success - 任务完成率
有了上面的五个维度后，怎么去设定目标，进行量化，把他们与业务关联一起呢。比如，商业策略，运营策略，技术能力。让那些与产品核心工作关联较少的人员，在关注用户体验之外，也能理解产品的业务目标。
针对上面的目标，可以使用「目标 - 信号 - 指标」的方法。把每个维度的抽象概念转化为具体可行的方案。
定义产品或功能的目标。在用户体验方面，用户需要完成什么任务？设计的意图是为了达到什么目的？比如，吸引新用户，提高用户活跃率。
定义实现目标的特征。什么信号表示目标已经达成？哪些用户行为与目标实现相关联？与信号相关的数据源会是哪些呢？比如，完成下单，分享给好友。
将信号转化为特定的指标。方便产品人员持续跟踪产品的变化。注意：定义的数据最好为常态数据，而非原始数据，随着用户数据的增长而增长。比如活跃用户数，尽管是非常重要的业务数据，但也属于虚容指标，容易让产品人员忽略了留存率的考虑。增加留存率和渗透率能帮助产品人员监控产品运行的健康状态。
下面以快递柜的寄件业务，应用 HEART 框架来分解下用户体验。
提高用户愉悦度
用户对产品的态度比较感性，呈现两个极端：非常喜欢或者讨厌的才会发出声音，这部分用户比例较小，大多数是都沉默的用户。所以，如果用户评论或反馈上很难量化用户对产品满意的程度。
但并不代表愉悦度没有可量化的空间。应用市场的打分，单用户平均分享次数都可以用来长期追踪，衡量用户对产品的好感。如果你的产品属于即时完成任务的，在结果页就可以提示用户打分。
寄件体验跨越周期比较长。从寄件人下单投递，快递小哥揽件，发出快件，再到最后收件人确认收件，才能算一个完整的取件。像这样的任务周期长，用户不能进行即时反馈的，可以向用户推送评价提醒，用奖励的方式引导用户完成评价。比如，京东的评价提醒。
在网上浏览 HEART 框架相关文章时，有些作者表示，能够量化的指标很少。我的感触是，只要你深入业务内，可以挖掘到很多的指标的。不知道，是不是写文章的人大多数是从事用户体验工作的，对业务欠缺深入了解。
量化统计方法的缺陷也很明显：用户可能仅使用部分功能，根据自己的感知对整个产品进行打分，无法细化到某个具体的功能上。特别是当你的产品集合了多个业务的时候，核心业务的功能打分可能掩盖了其它功能的不足。增加用户反馈和用户调研是非常必要的。如果你的产品是在微信体系内的，使用腾讯的「吐个槽」就非常方便。
顺便提下，「吐个槽」可以引入星级评分，像滴滴打车样。让用户评价更轻量化，在不需要用户反馈的情况下，引导用户打分。产品人员能看到不是反馈的问题，还能看到量化的数据。「吐个槽」本身就是属于腾讯的工具，实现这点，也能帮助开发人员完善微信工具的生态。
提升用户参与度
这个数据放到寄件业务再合适不过了。身边的大多数朋友，每次跟他们提快递柜寄件功能时，他们都表示惊讶：快递柜还可以寄件？更惊讶的是，就连我们公司一些同事，也不知道快递柜有寄件功能。而我们有一条主业务线，就是寄件业务。
仅是周围朋友简单的调研，就知道寄件业务渗透率了。换一个角度来看，寄件业务有很大的渗透空间。但首先，需要让别人知道有这个功能。到底有多少人用过这个功能呢？100 个用户里有多少个人用过这个功能呢？我做了一个简单的推导：
寄件用户必须注册公众号，主动使用快递柜，属于主动用户。
收件用户是快递员投递产生，被动取件，属于被动用户。
大多数用户，收件数远远大于寄件数。
因为快递柜地理位置属性，寄件的用户几乎 100% 取过件。
所以，可以认为 参与度 = 寄件活跃数/取件活跃数。
计算得到的数值，与调研的结果是一致的，而且比想像中的还要低。实践中，参与度可以根据你关注的目标来定义，不同的公司定义的标准都可能不一样。就像活跃用户，有些公司认为登录一次的用户即为活跃用户，有些公司认为浏览过一次内容的用户即可活跃用户，不管用户是不是来自客户端，从第三方跳转过来也算在其中，比如微博。
同样，寄件的参与度，可以用下单的用户数作为标准，也可以用进入该功能模块，使用了 5 秒以上的用户作为标准。
有了用户参与度数据后，可以使用业务交叉推荐的方式来提升参与度，通过前后数据对比，能够了解实际效果如何。
提升用户接受度
接受度听起来跟参与度很相近，初次接触容易将两个概念混淆在一起。参与度一般用来衡量用户的行为，比如微信里：
社交行为。评论，点赞，转发。
发布动作。发朋友圈，发消息。
这些行为一般与产品的品牌或功能宣传相关，用户通过某渠道了解产品功能，完成了某个功能操作。
接受度较参与度更深一步。简单来说，参与度定义的是用户完成某个操作的情况，比喻活跃用户数。接受度定义的是产品或某个功能对用户的黏性情况，比如用户活跃时间。
以寄件业务为例，你肯定不会根据「点击寄件功能人数/活跃用户数」来定义接受度。因为用户可能是无意或只是好奇想了解该功能，进入了这个功能模块。但是可以使用漏斗模型来梳理寄件流程来定义各阶段的接受度。比如，
从手机下单到去快递柜投件。
从快递柜投件到投件成功。
平均单用户寄件数。
提升新用户留存率
即使抛开用户体验，留存率应该是所有产品最先考虑的指标。不论是社交产品也好，还是工具型产品也好，都需要关注留存曲线。
假想一个场景：运营人员每天拼命做拉新工作，而另一边新进来的用户随着时间推移，在第二天，第二周，第二月开始不断流失。结果是短期内活跃用户不停地上涨，但实际业务的转化效果并不好。运营人员对此并不知晓，辛辛苦苦地投放大量人力和物力，最后用户都流失完了，得不偿失。
就像一个水池子，一边往里面不停地注水，另一边在悄悄地漏水。看起来水池子的水一直在增长，一旦拉新的工作稍微放松，拉新的用户小于流失用户，活跃用户自然开始减少。长期来看，这种做法是不可持续的。健康的留存率是，将时间拉长到较远的时间，留存曲线会稳定在一个大于 0 的值。
对用户来说，寄件相对于其它产品，使用频度较低。考虑活跃用户数据，可以将周期拉到一个季度，做留存分析。留存可以根据业务需要，进一步细化，拆分出子项目：
渠道。不同渠道的用户留存率不一样。你需要知道用户从哪里来，哪些渠道用户最容易流失，减少营销投放。哪些渠道用户留存率高，需要加大营销投放。
核心功能。留存下来的用户主要使用了哪些功能，是否满足了他们的核心需求。那些流失的用户，是因为什么需求没有满足而离开呢。
留存阶段。新用户从第二天开始流失，前期阶段，用户会流失严重，到后期阶段开始趋缓。可以将留存曲线划分为不同阶段，比如，震荡期，选择期，稳定期。根据不同的阶段对相应的用户制定不同的运营策略，让用户快速进入稳定期，提高留存率。
提升任务成功率
任务成功率可以使用漏斗模型来监控数据，主要用来关注异常行为，提高效率（任务完成的时间），提高效果（任务完成的百分比）。
寄件业务里，类似指标有：
投件/下单率。从手机下单到真正投件，中间会有一部分用户流失。这些用户因为什么原因而放弃？可能是因为价格高，可能是因为不会使用快递柜，也可能是因为投递的物品格口放不下等等。了解细节能帮助产品人员分析具体的原因，改善产品的易用性，提供投件率，减少订单流失。
揽收及时率。用户投完件，并不意味着任务完成，还需要等快递小哥揽收，及时将快递转寄出去。快递小哥，能否在规定时间内进行揽收，如果出现异常，该如何解决，避免此类事情再次发生？
投诉率。即使各个任务环节都有监控，难免有遗漏地方，可能会造成用户反馈。比如，用户寄件投递到格口，关闭箱门后又不想寄件了，而柜机上「取消寄件」的功能提示有限，界面跳转后就无法操作。用户可能就无法操作处理，一时找来客服入口，可能就打电话来投诉。
HEART 框架的应用方案，简单来看，可以拆分两个点。第一，根据维度细分到具体的量化指标。第二，找到提升或除低指标的业务方案。试一试吧。
文章首发于公众号-野兽说（monster_talks）,欢迎关注，查看更多产品内容。
