有关用户体验的点点思考

反对把"最佳实践"、"方法论"、"框架"挂在嘴边
服务器君一共花费了215.216 ms进行了5次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

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

本文地址:http://www.nowamagic.net/librarys/veda/detail/1163,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/1163

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《Python学习手册(第4版)》 鲁特兹(Mark Lutz) (作者), 李军 (译者), 刘红伟 (译者), 等 (译者)

《Python学习手册(第4版)》学习Python的主要内建对象类型:数字、列表和字典。使用Python语句创建和处理对象,并且学习Python的通用语法模型。使用函数构造和重用代码,函数是Python的基本过程工具。学习Python模块:封装语句、函数以及其他工具,以便构建较大的组件。学习Python的面向对象编程工具,用于组织程序代码。学习异常处理模型,以及用于编写较大程序的开发工具。了解高级Python工具,如装饰器、描述器、元类和Unicode处理等。

更多计算机宝库...