用户体验

    用户体验是一个很大的话题，先从一个故事说起。

    周末参加了两天的PMP培训，听课期间注意到老师的一个细节，在讲选择题的时候，选项A、C读音正常，而“B”老师读为Boy，“D”老师读为Dog。

    刚听到的时候大家莞尔一笑，以为这是个善意的玩笑。但是以后的题目都是这样读音。

    很快，我想明白了，B和D的发音类似，容易混淆；Boy和Dog是简单的单词，发音能够明确区分，也没有类似Bog和Doy的读音混淆。

    这是什么？这就是用户体验。

    用户体验这个词似乎突然流行起来，似乎因为以前过苦日子，不在乎衣着打扮，最近大家富足了，审美提高了，突然迸发出了需求。

    当然也和大环境有关系，比如苹果的成功，很多人就认为是用户体验至上；360不管口碑如何，产品也经常被（包括Pony）作为用户体验的榜样。

    我们公司也是如此，大家言必称用户体验，就像前两年的“敏捷”一样。上个月隔壁的老赵问我有没有做UE的朋友，能够出到15W的年薪。虽然在北京，我认为这也是个不小的数字，可见我们对UE是多么地求“贤”若渴。

    如何做用户体验，我一向反对把“最佳实践”、“方法论”、“框架”挂在嘴边，也反对固守己见，不接受别人的见解。没有任何两个项目是完全相同的，也没有任何两个产品面临的现状一样。因此，我们应该以“清零”和“包容”的心态学习成功的经验；同时以“怀疑”和“批判”的态度进行分析；最终形成自己能够想得明白，有可操作性的方法。一句话，反对照抄和不抄。

    我们的产品规模很小，功能也很少，这就意味着我们和大型项目的处理方法可能会不同。如何让我们的产品能够拥有良好的“用户体验”，从而获得用户的认可，并且叫好又叫座，这是我最近一直在思考的问题，当前主要的结论如下：

    第一步，分清责任人，用户体验是产品经理的活。

    不要片面把用户体验看做是UE的活或者需求的活或者开发的活。现实情况中，UE未必懂业务，需求未必有美感。如果恰巧你的开发也把用户体验看的很重要，在设计或者编码的时候会自然而然考虑，那么，恭喜你，捡到宝了。这是不现实的：一方面，一个各个岗位都很强而且能够自组织的团队，搭配一个Sales就可以了，还要产品经理干嘛？另一方面，每个人的审美是不同的，每个人编码的时候都考虑到了界面展示，风格都未必统一。再培训一下，统一界面风格，统一色彩搭配，统一控件形状，统一命名规则……如果这样，还是搭配一个专业UE吧，开发好好考虑一下性能、开发效率、Bug数和扩展性吧。拿建筑做比喻，需求就像是设计师，决定做什么；开发负责土建部分，搭建毛坯房；UE负责装饰装修，让建筑适宜人居。因此，除非扩专业的人才，这几个角色都无法单独承担用户体验的工作。产品经理重要的一个职责是整合，他需要从全局和整体处理用户体验的问题。用户体验的好坏往往从需求定义的时候就开始受影响了，因此产品经理需要贯穿项目始终。

    第二步，创造氛围

    这个氛围指的是让大家认可用户体验很重要，但是避免夸大用户体验的重要性。

    产品经理需要采取一些措施使得团队成员，不管哪个角色都认可用户体验很重要，当涉及到分派的与用户体验相关的问题的时候需要积极配合。

    通过创造氛围，也欢迎团队成员就用户体验提出自己的建议，产品经理需要作出判断。

    这些措施可能包括一起学习用户体验的相关知识、内部培训、换位思考等等。

    至于不要夸大重要性，是说真的没有必要在你做需求的时候，脑子里面框个用户体验的框框；在编码的时候，想着怎么配色；在UE的时候，想着客户的骂声。同时，避免镀金的行为：很多时候，加多了，意味着出错的几率大了。

    第三步，分清先后

    把握先能用，再好用的原则。在项目的初期，要高效率完成能用的版本，这主要为了验证业务思路，确定产品方向。

    我们做成GCL、GQI两个亿级产品的肖工，曾经分享了一张PPT，给我印象深刻：每个迭代的交付物都是可以独立工作的产品。

    一定要避免做一个完美的半成品。这里引用百度的一句话：快速迭代，越变越好！

    第四步，单独处理

    我们的任务安排往往过于追求功能性需求，而忽略非功能性需求。比如在我们的一个Sprint（Scrum术语，表示一个迭代周期）中，往往功能项嫩巩固排到这个迭代的最后一天。大家都忙于做功能、改Bug，有哪门子闲情逸致考虑你的用户体验？能赶上每天的末班车就谢天谢地了，难道真的希望我们通宵达旦地天天干啊？

    因此，建议将非功能需求单独列为一个Sprint或者功能点（敏捷中常常称为Story），不要将这些想当然认为是功能性需求的一部分。

    第五步，验证

    我们所做的不仅仅是客户验证。在《Show stopper》中提到卡特勒在微软NT开发期间提倡的吃狗食，也就是说所有的人必须在尚未开发完毕的NT上进行开发。

    因此，一方面，验证分为内部和外部。在产品上市之前，要求我们团队的所有成员都会用我们的产品做工程，都能够帮助用户解决问题，都习惯给我们自己的产品挑刺。我们还需要走出去，找不同的用户或客户对我们的产品进行试用，还需要能够做到试用第三步的方法，快速迭代，越变越好！

    另一方面，拿实物验证，不要用原型或者口对口进行用户体验的验证。即使高仿真的原型也不是用户真实工作的软件，因为你无法验证是否会关键时刻出Bug、是否存在性能问题、是否出现令人啼笑不得的提示、是否出现数据的逻辑问题……

    第六步，平衡

    很多人会乐道苹果是怎么追求用户至上，怎么样追求完美到偏执。如果成功有现成的流程，那么苹果不会这么少。产品经理一项基本技能就是平衡能力：用户体验和进度冲突了怎么办？和成本冲突了怎么办？和资源冲突了怎么办？

    谨防借着用户体验之口的需求蔓延。举个例子，你花1000元买个相机，你会要求它给你配2个镜头、采用航天材料做外壳、采用顶尖的卡尔蔡司镜头、具备单反能力……

    用户体验往往和进度、成本、资源等是有关联的，因此如何做好平衡非常重要。

    第七步，总结

    不管这个产品成功还是失败，一定要做阶段总结，这样才有可能越做越好。实际上，找一个有做产品经验的人（比如Jobs或者周鸿祎）可能比学习所谓的“最佳实践”，做成产品靠谱得多，这就是总结的作用。

    声明：这仅仅是我自己的思考，不代表正确，更不代表我们公司的观点。欢迎大家一起讨论。