用户体验是一个很大的话题,先从一个故事说起。周末参加了两天的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或者周鸿祎)可能比学习所谓的"最佳实践",做成产品靠谱得多,这就是总结的作用。