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

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

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

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

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

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

便捷性是指用户在使用过程中总会有一个使用的目标，我们可以让他最快最方便地达成目标。对大部分用户来说，他们缺乏对于流程化概念的理解，不会对烦琐的流程和操作有太多的耐心，因此少一步操作，就可以留住更多用户。众所周知，汽车一般分为手动挡和自动挡。在自动挡没有出现之前，许多人认为自己学不会驾驶汽车的能力，什么时候要踩离合器，什么时候要加挡，什么时候要空挡……如此多的判断就好像一个一个复杂的流程，让人望而却步。自动挡汽车出现之后，人们的心理门槛就降低了，之前觉得自己学不会的人也开始试图学车，因为自动挡很简单。只要你把挡位调整为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 形成了一个有趣的风格：每周五都会更新一个版本。