小雪碎碎念：作为用户的时候每次看到有更新提示小红点的时候都会不自觉兴奋，产品更新实在是值得期待的事；作为产品就不一样了，每一次更新都伴随着痛苦的过程，如何有效把握用户预期？跟着小雪看下文吧。

衡量体验与符合期望

既然已经定了产品方向，那就可以写文档进行开发工作了。虽然是敏捷迭代，但依然要付出两个星期时间去开发产品——假设产品研发完成之后，不符合用户的预期怎么办？

在日常的项目阶段，开发结束之后都会进入一个名为“产品体验”的阶段。在这个时期内，产品经理会不断地针对产品进行使用并优化方案。在这个时期内，常常会遇到几个问题：

●开发完成的功能和需求文档有所出入。

●有一些边界数值问题没有进行限制。

●流程体验不是闭环。

●有些真实操作的体验还有点不爽。

产品经理注定是解决问题的人。产品体验的阶段是针对产品进行最后调整的时期，产品经理不仅需要确保产品的正常交付，还需要确认用户需求是否发生改变，市场是否出现相应的变化。很有可能在开发阶段已经有其他相似的产品提供对应的功能，或者是用户有了新的途径去满足对应的需求。不仅如此，产品是值得打磨的，尤其是用户体验——什么叫用户体验？用户体验是用户在使用产品时候产生的感受。

张小龙曾说，产品要满足用户的“贪嗔痴”。这个描述很准确，大部分时候人对于产品都有一个期望，而能否满足他们的期望，就是产品体验好坏的衡量标尺。如果要用一个公式去表达体验好坏，可以这样看：

实际操作带来的感受大大超出期望，那用户体验则是好，反之为不好。如果要让产品实现最佳的体验，产品经理不得不做两件事情：

●提升实际操作的“快感”。

●把控用户的期望。

提升实际操作的“快感”非常考验产品经理的功力。我认为，提升实际操作的体验取决于这样几个因素：

●便捷性

●反馈性

●感官性

便捷性是指用户在使用过程中总会有一个使用的目标，我们可以让他最快最方便地达成目标。对大部分用户来说，他们缺乏对于流程化概念的理解，不会对烦琐的流程和操作有太多的耐心，因此少一步操作，就可以留住更多用户。众所周知，汽车一般分为手动挡和自动挡。在自动挡没有出现之前，许多人认为自己学不会驾驶汽车的能力，什么时候要踩离合器，什么时候要加挡，什么时候要空挡……如此多的判断就好像一个一个复杂的流程，让人望而却步。自动挡汽车出现之后，人们的心理门槛就降低了，之前觉得自己学不会的人也开始试图学车，因为自动挡很简单。只要你把挡位调整为D 挡，然后就只需要踩油门和踩刹车即可。这一功能大大简化了操作，带来了便捷性，提升了驾驶体验。产品经理应该注重化繁为简的能力，让操作更便捷，这一点必不可少！

反馈性是指用户在使用中，每一个操作都要有对应的反馈。比如，按下按钮需要有一个与平时状态不同的点击状态，操作失败时要有错误提示，游戏产品中要有虚拟道具奖励用户，这些都是反馈的作用。我曾经上过内部的一个测试课程，发现测试工程师对于反馈和体验有着丰富的经验。例如，从Windows 的启动界面、传文件进度条提示和Photoshop 的启动界面，都可以看到反馈的重要性。对于用户来说，Windows XP 系统的启动界面（参见图3.6）绝对是再熟悉不过的——但大家看到这张图片后能否告诉我还有几秒钟，Windows 才能正常启动进入桌面呢？乍看之下没有太多方法，对于用户来说，这个图基本就是没有反馈的，没有提示可以告诉用户Windows 要启动好了。如果机器性能比较差劲，有可能会在这个界面一直卡住。

图3.6 Windows XP 系统开机启动中出现的加载画面

但是，真正熟悉Windows XP 系统的人应该都明白一个“潜规则”，这个进度条走满5 次就可以进入下一个启动界面了。所以，了解的人可能会通过这种方式去判断开机速度，而大部分人可能都不知道自己的电脑什么时候可以准确启动。

如果遇到一些不明白这个“潜规则”但是急需要使用电脑的用户，或许早就恼羞成怒了。所以，明显的反馈是非常重要的。

相比之下，Windows 7 系统的传文件界面（参见图3.7）就做得非常好，它准确地描述了传文件的情况：速度、剩余时间等。如果性急的用户看到这个传文件的过程总共要花大约2 分钟时间，那他可以准备点爆米花、上个厕所，轻轻松松地度过传文件的等待时间，而不是焦虑地等着——那会让人很不爽。

图3.7 Windows 7系统中移动文件出现的传文件窗口

感官性是指通过界面变化来示意用户操作，或带来视觉上的体验。例如，日本的一个名为Yoritsuki的APP（参见图3.8）绝对称得上是艺术品。因为它让人觉得打开这个APP 就会带来美的享受，让人愉悦。这就是感官性对于产品的意义。

图3.8 日本知名的iPhone应用，通过设计庭院展示禅意

把控用户的期望是产品经理常常面临的问题。为了推广产品，产品经理大部分时候必须通过各种方式去宣传产品的易用性、强体验等，但如果宣传过度则有可能会引起用户期望太高，而等到新产品推出之际，发现产品使用低于预期，这时常会造成一些负面的效果。因此，产品经理不能把用户的期望提得太高，而应该考虑如何避免产品和用户的期望脱节而产生明显的心理落差。

iOS 7 的发布就非常有意思：发布前大家都对iOS 7 非常期待，库克在发布会上发布了之后，许多用户开始吐槽对应的界面设计，下载beta 版的用户都开始抱怨各种bug。正式发布了之后，之前强烈反对的一些用户又觉得这个系统在手机上看起来还挺顺眼的。

用户的期望是一个很难琢磨的东西，大部分时候产品经理都很希望有一个测量仪，可以准确地把用户的期望量化——显然，这个很难做到。或许我们可以使用用户调研的方法去判断用户的期望：用户的行为和态度表达了对应需求的期望值。产品经理可以考虑进行灰度测试，看看用户的反馈和需求是怎么样的——通过这样的方法，搜集用户的反馈内容并提炼出关键词进行优先级排序，这样可以看出一些问题。

当然，这个时候不能忘记了重要的决策工具——人物角色。在之前通过人物角色进行用户调研的时候，我曾提到人物角色应该贯穿整个项目决策，并成为有效的依据。通过核心人物角色进行描述，并结合真实的用户访谈结果，可以有效地了解用户的预期。

在写作本书期间，我突然迷上了看电视剧。之前我从来没有关注过太多电视剧，觉得它们剧情又臭又长，需要花费大量时间，而且人物刻画很糟糕——但是在我迷上看电视剧的这段时间里，我发现一个很有趣的现象：人物角色的原理可以运用到电视剧中，而理解电视剧（尤其是情景剧）人物刻画和剧情推动的方式可以反过来更好地理解人物角色在互联网产品中的作用。

通过版本迭代把控用户预期

说到看电视剧，我时常听见身边的人在吐槽：

●《纸牌屋》第二季怎么还没有出来呀？

●《生活大爆炸》还演得下去吗？

●最近都没有什么剧可以看，如果重新看一部电视剧，又要追剧，好累……

换个思路，产品经理是不是也经常看到用户反馈：

●夜间模式怎么还不出来啊？

●上次提到的增加管理功能都等了好几个版本了！

●说好的高清图片呢？我才不想要为了省流量的小图。

因为开发成本及版本迭代计划等原因，大部分时候产品经理不得不背着“骂名”推动每个功能的排期。比如，夜间模式和管理内容这两个功能，如何判断优先级呢？在日常产品需求排期会议上，时常会遇到下面这样的对话。

产品经理：好像夜间模式反馈的用户比较少，不如我们先做管理功能吧？

项目经理：本次需求排期要优先考虑几个大功能，开发人力不足以支持再去做这两个功能。

每个项目计划都会遭遇到很多变故。随着市场变化和用户需求的变化，产品计划也需要有所变更，可能彼时用户还在反馈某个功能不好用，此时就再也没有用户吐槽这个功能了。假如把产品迭代看成美剧，就可以发现这些编剧对于节目的编排值得借鉴，以《生活大爆炸》为例。

●场景：场景布局基本在室内，且不做变化。

●演员：每个人物角色都非常饱满——社交能力很弱的技术宅、性感的金发女主角、有点萌的女博士、努力融入美国文化的印度人和犹太人等。

●剧情：每个人的个性都很突出——冷笑话及冲突大部分发生在谢尔顿身上；关于种族的剧情总是出现在霍华德和拉吉身上；爱情故事主要由佩妮触发；而莱纳德是最圆润的人，大部分时候都是在扮演和事佬的角色。

●发布日期：每一季之间大概间隔半年到一年时间；每一季内的片集则是每周三准时播出。

如果把每个剧情都看成是一个版本迭代，产品经理就会发现美剧虽然迭代时间比较慢，但是用户的抱怨比较少，而且每次新的一季内容一出现，大波人马上开始观赏并津津乐道。对于用户来说，提前知道了产品迭代的周期就容易消除期望的起伏。例如，小米公司的MIUI 形成了一个有趣的风格：每周五都会更新一个版本。

MIUI 为什么要每周五发布？这个项目开始的时间是2010 年4 月底，项目负责人是黎万强，工程师是我和刘新宇，然后就没有其他人了。新宇负责电话相关的改动，我负责系统升级，要保证可以在线升级（OTA）到下一个版本。两个人非常兴奋，也非常努力，畅游在Android 代码的海洋里面，很顺利地在劳动节放假前发布了第一个内部版本。

那一天，2010 年4 月30 日，正好是周五。在那之后，公司内部的版本总是在周五发出来，当时是每周工作六天，周六还有时间修复周五版本的问题，有时候会发一个紧急更新，确保小米公司的同事们都能用上放心的系统。

2010 年8 月16 日MIUI 正式发布之后，我们还是坚持每周五发布，其实没有什么特别的，因为之前已经是那样了，每周五发布和OTA，就是MIUI的基因。做到每周五按时发布，其实并没有那么轻松，不同的时期，不同的团队规模，都有不同的挑战。随着MIUI 的团队规模越来越大，累积的功能越来越多，用户预期也越来越高，开发流程也跟着变化。从开始到现在，MIUI 大概分为狂野、克制、精准三个阶段。新功能都在体验版开发，开发版的用户其实不会受到影响，因为这些用户喜欢体验完整的新功能，而不是带有问题的新功能。

体验版上的新功能完整之后，提交到开发版分支上，发出去之后对于开发版用户来说还是新鲜的。现在MIUI团队有300 人，同时开发的项目有十几个，每周达到完整的新功能很多，这样可以保证开发版的新功能足够吸引人。

其实开发版还有内测，每周二下午开始，每天都有一个版本，提供给那些稍微喜欢折腾的开发版用户，同时也能帮我们发现问题。写了这么多，不知道有没有回答问题，总结起来就是MIUI 一直都在尝试更好的开发模式，同时满足不同用户的需求，又能够保证作为基因的每周发布。很多事情做不到，不是没有能力去做，而是没有想到可以那么做。

当然，如果能够有MIUI 这么一个既有创新能力、又有执行能力，既充满激情、又能够克制的团队的话，做到每周发布就太容易了。——摘自小米工程师孙鹏在知乎问题“为什么小米的系统MIUI 能够一周更新一次，而魅族的固件更新周期很长？”的回答，http://zhi.hu/UJgUMIUI 的开发风格是不是有点美剧的风格？定期更新、绝不延误、尽量满足用户。

但和美剧一样，这样的节目编排计划就对编剧能力要求特别高，不仅需要保证内容合理而超出观众预期，还要定时定点输出对应的内容。正如孙鹏所言，MIUI在尝试更好的开发模式，同时满足不同用户的需求，又能够保证作为基因的每周发布。因为MIUI 的这种开发风格和及时响应用户的习惯，MIUI 在近两年来获得了许多用户，让人称赞。

控制迭代节奏，把控用户期望不仅仅是产品经理所需要关注的事情，还是整个项目都需要关注的问题。毕竟，真正做到定期更新版本、交付符合用户预期的功能和产品，非常考验整个团队的凝聚力和战斗力。

文章来源：腾讯大讲堂