这本书是关于用户体验与可用性测试的入门级读物。作者基于多年的经验,围绕用户调查、原型制作、产品可用性评价、用户测试,结合具体案例,提供了极其实用的方法和实践技巧,同时也介绍了敏捷用户体验开发的相关内容。
作者:[日]樽本徹也,产品可用性工程师、UCD咨询师、敏捷UX培训师。在用户调查及产品可用性评价方面有丰富的经验。
翻译:陈啸
摘自《用户体验与可用性测试》,人民邮电出版社,2015年4月
为什么不能指望用户的意见?
所谓的头脑风暴,真的有用吗?
应该如何限定你的目标用户群?
怎样的用户调查才是真正有效的?
如果你是设计师或程序员,学会了产品可用性的技术,就能以“更高的效率、更小的代价”来提高工作质量。
产品可用性≠产品易用性
第一部分
1、产品可用性可有可无吗
Usability 经常会翻译成易用性。在做市场调查时,易用性也经常会和 功能、性能、价格等一同被视为用户购买产品时的重要考虑因素,可见其重要性毋庸置疑。
然而,如果把 Usability 理解为易用性,就很容易和为用户着想、对用 户友好这类比较感性的概念相混淆,进而导致设计团队把它和对用户而言 “有则更好,没有也 OK”的开发需求混为一谈。 在实际开发项目时,对成本、完工时间、产品质量等的要求是比较严格 的。为了满足这些高要求,企划、设计、安装、质量监督、市场等部门如临 大敌,奋战在产品开发的第一线。而处于这种极端环境下的设计团队如果只抱着“可用性=易用性”的想法,就会越来越不重视产品的可用性。
但是,产品可用性却包含非常重要的意义,即“可用”。如果产品出现 不能用的情况,相信设计团队也一定会更加认真对待并解决产品可用性的问题。设计团队中如果没有产品可用性工程师,设计出的用户界面往往会带 有严重的产品可用性问题,这会直接造成不少项目在用户界面完成之后的用户测试阶段,才发现设计出来的用户界面根本不能用。
要想不屡次犯这种错误,就一定要认识到,Usability 不是易用性,而是可用性。
2、根本没法用的产品
大家也许会认为,用户界面可能多少有些不太好用,但完全不能用的状况就属于极端事例了吧。然而,实际上有很多项目在开始时都是以“好用”为目标开发的,但完成后的测试结果却非常糟糕,最后只能将开发的 目标转变为“能用”。
大家在上网时遇到过以下情况吗?
▎乱七八糟的搜索引擎
登录某家电厂商的官网搜索产品名称时,搜索到的全是产品宣传广告。 另外,如果产品名称里有英文字母,检索时即使只是搞错了一个字母的大小写,也会“搜索不到您想要的产品”。
▎繁琐的订单页面
某网店的订单页面里要客户填写的内容有 20 项,而且每一项的内容都 有严格的要求。比如,邮政编码里请不要加“-”,姓与名中间请输入全角的空格,电话号码的区号后面请加“-”,日期必须要凑足两位(例如 09/11) 等。更过分的是,要是输入错误,在按下提交按钮后,就会逐个弹出提示 每一个错误信息的对话框。
▎没法后退的网站
使用某金融机构的网站搜索门店时,会弹出专用的小窗口。只不过, 在这个小窗口上没有任何的返回键或返回链接。如果用户在搜索过程中不小心弄错了什么,是无法退回到上一步的,只能从头再来。
用户使用这种“乱七八糟的搜索引擎”,若得到的都不是自己想要的搜 索结果时,就会失去搜索的积极性,也不会再想了解产品信息了。
要是用户碰到了“繁琐的订单页面”或“没法后退的网站”,虽然可以 在反复修改多次之后达到最终目的,但一旦操作结束,大家也许马上就会表示出强烈的不满:“这是什么破网站!我再也不用了!”
从产品制作人员的角度来看,上面的例子也许只是“稍有些不好用”, 但从用户的实际体验来看,就上升到了“这东西根本没法用”。所以说,从产品制作人员的角度来判断产品可用性是一件非常危险的事情。事实上,能代替你的产品的东西实在是太多了,只要你的界面让用户感觉到“没法用 ”,他们马上就会使用其他产品。正因如此,杰柯柏• 尼尔森(Jakob Nielsen)在他的著作中才会这样说:“能左右互联网经济的正是产品可用性。”
作为产品可用性工程师和用户界面设计师,如果把对产品可用性的理 解停留在“可用”上,实在是有辱自己的头衔。因为同领域的设计专家们早已把目标定为“产品设计就是为了实现在确保安全性和正常可用的前提 下,让产品更具魅力”。
交互系统的用户界面设计确实是一件非常复杂的工作。当务之急,是先 把我们的水平提升到“至少保证用户界面已经达到了正常可用”的高度上。
3、产品可用性的定义
国际标准 ISO 9241 把产品可用性定义为“特定的用户在特定的使用场 景下,为了达到特定的目标而使用某产品时,所感受到的有效性、效率及满意度”。
该定义的前半部分,出现了好几次“特定”这个关键词。实际上,对 于某些产品或网站而言,无法简单地判断其是否有用。只有在确定了用户、使用情况和目标这些前提之后,才能使用有效性、效率、满意度这些标准 来对其进行评价。
▍有效性
有效性(Effectiveness)指的是用户能够达成自己的目标。比如在网上 书店购书,有效性就是指用户能够买到自己想买的书。如果买不到,这个网上书店也就没有存在的价值了。因此,有效性问题是无论如何都必须要 解决的一大问题。
▍效率
效率(Efficiency)就是用户不必做无用功,就能以最短路径达成目的。 仍以网上书店为例,如果购物车的操作很麻烦,用户反复操作很多次才买到自己想买的书,那这个网站就存在效率问题了。而且,严重的效率问题实际上就是有效性问题,因为这样的产品,用户用了一次之后,再也不会使用第二次。
▍满意度
满意度(Satisfaction)就是即使有效性和效率两方面都没有大问题,也要从更深层面来考虑,即有没有给用户带来不愉快的体验。比如,注册会员时要求用户提供过多的个人信息,或者要求用户同意单方面制定的使用条约,或者系统的反应速度非常迟钝等。一旦发生这样的情况,马上就会招致用户的抱怨,严重的话,可能导致用户不会使用第二次。
只有符合 ISO 9241 的定义,满足以上三个要素,才称得上实现了产品可用性。然而,实际操作时并没有这么容易。比较现实的一个做法是,在权衡问题严重性的同时,首先解决有效性问题,然后在时间和成本允许的情况下,尽量解决效率和满意度的问题。
产品失败的原因
第二部分
我认识的一些用户界面设计人员和软件程序员,他们无一例外都尽心尽力在为用户考虑。而且,他们也确实做到了不单纯注重市场和技术,想方设法做出了舒适好用的用户界面。然而,无论他们多么为用户考虑,结果总是不尽人意。很遗憾地讲,他们大半的精力都浪费在了不切实际的讨论和活动上。
1、橡胶用户
导致产品不能用的常见原因之一就是“用户定义失败”。如果大家听到有一款车是“敞篷越野面包车”的话,会做何感想呢?如果想让一个产品满足所有人的需求,最终设计出来的恐怕就是类似“敞篷越野面包车”这样的东西。当然,世上肯定不存在这样的车,即使存在,应该也不会有人买。在设计用户界面时,如果把所有用户都当作对象用户,就犯了类似的错误。
那么,只决定假想用户就足够了吗?比如说,现在把用户群假设为“关注时尚、注重自我的成年人”。但是,这样的假设是不严谨的,和不定义对象用户没什么区别。阿兰• 库珀(Alan Cooper)把类似这样的假定用户群戏称为橡胶用户(Elastic User)A,意思就是这样的定义可以根据设计人 员的想象而随心所欲地变化。我们经常会遇到这样的团队:在项目启动后的第一次会议上提到产品 的假定用户群时,大家先是短暂地不知所措,然后郑重其事地提出我们的 假定用户群就是所有的顾客。像这种没有任何条件限制的假定用户群,范围也太大了。
在项目开始阶段,设计团队无论是时间还是精力都十分充沛。为了能够提供更好的用户体验,在新功能和如何改进用户界面方面,团队成员会提出各种各样的创意。然而,无论是多么优秀的创意,只要其他人能够想出哪怕一个不喜欢的用户,该创意也极有可能被搁置。如此反复,原本的创造热情会慢慢消退,也可能会出现团队成员感情用事、互相揭短的情况。
随着这种没有结果的争论持续升温,危机在不知不觉间就到来了,因 为“交货”的时间快到了。危机面前,马上就变成由“声势大”的成员主导,假想出一些勉强可以使用现有用户界面的用户形象。对于其他团队成 员而言,一是团队目前已身处悬崖边缘,再者自己对这种没有结果的争论也颇感无奈,于是也不会再反对,只好稍微改变一下自己一直以来主张的 用户形象(因为是“橡胶制品”,简单可变),投了赞成票。就这样, 没法 用的用户界面诞生了。
2、产品使用背景
在浏览产品可用性的相关图书和网站时,我们经常可以看到产品使用 背景(Context)这个术语。这个单词经常会被翻译成“上下文”,在英语文章里,常见的意思也是事物的“前后关系”或“状况”。
其实,产品使用背景就是类似舞台剧里场景设置那样的概念。举个例 子,虽然是使用同一个旅游信息网站,但是“女大学生 A 在大学的电脑教室里计划和朋友的毕业旅行”这个场景,和“商务公司的业务员 B 使用办 公室里的电脑安排下周的出差计划”这个场景就完全不一样。因此,不难想象用户在使用网站时用的功能和信息也是大不相同的。
可以说产品使用背景是“产品可用性的关键因素”。产品使用背景不 同,即使是同一个系统或产品,也可能会出现不能用或非常好用这两种截 然相反的结果。
例 1:转接非常麻烦的公司分机
我经常会因为接待访客、开会或者去做用户测试而不在办公室,因此使用固定电话是非常不方便的,所以公司把小灵通作为内部分机使用。无论在会议室还是在实际调查现场都可以使用小灵通接听电话。
但是,这种小灵通电话也存在很严重的问题,那就是转接功能不太好 用。因为是公司内部分机,所以经常有打给同事的电话打到了我这里,然 后由我转接的情况。当然,如果严格按照正常步骤来操作,肯定是可以转 接的,但是一旦搞错了中间的一个步骤,电话马上就会挂断。大家都知道 ,无端挂断客户的电话是一件非常不礼貌的行为,也是绝不应该发生的。那么,发生这种情况,真的是小灵通设计上的问题吗?
话说,大家有在自己的手机上使用转接功能的经历吗?估计大多数人一次都没用过吧。实际上,上面提到的小灵通,其设计初衷和其他手机是一样的,就算不能转接电话也很好用。所以说,犯错的并不是小灵通的设计师,而是我们这些把小灵通当成办公室分机使用的人。
例 2:销声匿迹的 BP 机
20 世纪 90 年代前期到中期,高中生之间曾出现过一阵 BP 机热潮。 1996 年,NHK 曾热播过一部纪录片,名为《BP 机友• 12 字的青春》。然 而,这股热潮并未持续多久,20 世纪 90 年代后期便逐渐销声匿迹了。
BP 机本来是商务上用来有效传递信息的工具。比如,它很适合用于上 司给正在出差的业务员新的指示,或者在医院或工厂内部传递信息。但是 用于高中生们闲聊的话,它还欠缺一个很重要的功能,那就是发送消息。 大家都知道,BP 机是专门用来接收消息的。这种只能用来接收消息的BP 机根本称不上是交流工具。
那么,那个时候的高中生是怎么发送消息的呢?答案就是固定电话。他们使用家里的电话,或者特意跑到有公用电话的地方发送消息。因为在当时,手机的价格非常昂贵,这样做也是无奈之举。虽说固定电话不太方便, 但是只能接收消息的 BP 机再配上发送消息的电话,也勉强能达到目的。
后来,当高中生也买得起手机时,BP 机也就退出了历史舞台。
例 3:不会用到的重置按钮
卓别林的《摩登时代》用讽刺手法描述了“人类被机器耍得团团转” 的情景,用户界面的设计原则之一就是必须具有可以让用户随时取消操作的“紧急出口”。
比如,Windows 里的程序,所有的对话框窗口上都设置了取消按钮, 用户可以随时取消之前所做的操作。只要没有按下 OK 按钮,无论在对话 框里做过怎样的操作都不会执行,因此用户可以安心使用。可以说,像这 样在用户界面上设计了 OK 按钮和取消按钮的做法是非常好的。
但是,这只是窗口的情况。如果是网页,取消按钮就不是必备的了。 在订单或注册页面里,如果并排放置发送按钮和清空按钮(也叫重置按钮),用户就很容易按错按钮,本来想发送,结果却清除了之前辛辛苦苦填 写好的内容。
如果是纸张,与其用修正液修正或直接划掉,不如把写错的那张纸扔掉,重写一张反而更快。但是在网页上输入的时候,有谁会清空所有已经填好的内容重头再来呢?显然只修改输错的地方更快一些。再者,如果确实想放弃此次填写的所有内容,点击浏览器的按钮退回到上一步就行了。
不管你熟知多少设计原则,一旦理解错了产品使用背景,就不仅仅是没有意义这么简单了,反而给用户添了麻烦。
3、用户体验的点与线
改进用户界面时,有不少人会使用常用的市场调查方法。比如,通过 问卷调查或者对用户访谈的方式,询问用户他们认为使用该产品(或该网站)最麻烦的地方是什么。
当然,这种方法也能发现问题,只要调查人数足够多,也可以找出用户界面存在的大多数问题。然而,即使通过这样的方法修改了所有发现的问题,用户体验也不会得到很大改善,因为在“重要路线”上还存在着不少问题。
用户界面的作用就是引导用户达成自己的目标,而用户在达成目标的 过程中肯定存在着一条路线,在这条路线上但凡存在一个不能通过的关卡, 就会使用户达不成目标。而且,即使只存在一个比较麻烦的关卡,也会使 用户耗费不少精力。
即使已经优先解决了用户界面上存在的重大问题,但只要用户经常通 过的那条路线上还有残留问题,用户体验就得不到很大改进。换句话说,必须要有一种能够清除所有问题的方法。
UCD的最新四原则
第三部分
UCD 的流程本身就比较简单,再加上从用户角度考虑问题的理念早已 潜移默化地植入大家脑中,因此乍一看可能不会有什么新鲜感。然而,它的背后却隐藏着一些非常独特的原则。
1、不要盲从用户意见
“你们的产品如果有这样的功能(特色)就好了”——很多产品正是在 开发时听从了这样的用户意见,导致最后的结果都不太理想。即使找借口说“用户的需求反复无常”来推卸责任,也不能从根本上解决问题,因为以“满足用户要求”为前提进行开发本来就是错的。
用户的意见肯定是基于自身体验提出的,因为大多数用户在反馈时经常提到“我用了 ×× 但不太好用”“花费了太多时间”“让我很烦躁”等。
用户所说的不过是对自己的亲身体验做了分析后的结果,并不会向你保证分析结果的正确性,因此即使反复分析这些意见,也不会有新的发现。
而用户体验却是未经分析的第一手数据,如果能对此进行谨慎细致的 分析,反而能发现一些甚至连用户自己都未发觉的潜在要求。也就是说, 我们需要关注的并不是用户的意见,而是用户的体验。
2、只为一人设计
用户肯定是为了处理某项事情才使用我们的产品。其潜在的含义就是, 如果不事先琢磨清楚“是哪些人为了什么目的而使用我们的产品”,就不能设计出符合用户要求的产品。但是,我们也经常会遇到这样的团队,他们 在提及产品的用户群时,大家先是短暂地不知所措,然后郑重其事地提出 我们的用户群就是所有的用户。
然而不幸的是,如果你想满足所有用户的需求,那么最终开发出来的产品(如敞篷越野面包车)一定是谁的需求也满足不了的。
那么,我们大胆地设想一下“不要为所有用户设计,而只为一个人设计产品”。抛弃那些没用的功能,确保产品的简洁性。那些具备了所有功能的产品,不是经常被人指责“常用功能只有 20%,将近 45% 的功能基本上用不到”吗?
3、边做边想
一个人绞尽脑汁地想,或者一群人在会议室里无休止地讨论,这样是 不会得到好的创意的。相比之下,边做边想(绘制一些简单的图,用身边的工具先做起来)反而更能发散思维。
也许大家会认为,能够快速且高质量地作图是设计师才具备的专业技能,但是“是设计师”和“像设计师一样(边动手边)思考”完全是两码事,这和画功的好坏也没有关系。比起口头说明,你画出来的图即使简单到只有线和圈,也更具有说服力。
无论是设计师、技术人员还是管理人员,如今我们都应该做到“像设计师一样思考”。
来吧,把会议室的桌子和投影仪搬到角落,大家都到白板前画出自己的创意吧。
4、早期试错
虽说世界发明大王爱迪生曾经说过“失败乃成功之母”,但一味地失败 是肯定不会带来成功的,愚蠢的失败只会带来损失。事实上,失败也是有 “窍门”的。
Fast: 趁早试错。
Small: 重大失败会带来致命的结果。因此,要把失败的影响尽量控制到最小。
Often: 不可失败一次就气馁,要多失败几次。
Smart: 绝不可反复犯同一个错误。要彻底查明上一次失败的原因,再“聪明”地失败。
纸制软件也是可以测试的。不要把不会编写程序、没有预算、没有时间这些借口作为不去做的理由 ,只要是在力所能及的范围内进行尝试就可以。在设计的最初阶段就应该反复进行试作和测试,而且要“善于”失败。
更多推荐
回复“61”——马化腾内部分享:三个问题说透如何做产品
回复“62”——鸟哥笔记VS知乎刘锤:一个运营牛人的进化论
回复“63”——前苹果副总裁:20-40-60法则
回复“64”——鹅厂顶级产品课程:产品细节中的情感化设计
回复“65”——如何用互联网思维卖辣条
回复“66”——马化腾亲身分享:腾讯兵法教你做一款高口碑的产品
回复“67”——去哪儿产品总监:先解构,再设计,把握产品经理的核心竞争力
回复“68”——一份优秀的竞品分析报告的撰写方法
回复“69”——阿里收购惊人内幕,支付宝出大招颠覆式创新-人人都是ATM
回复“70”——你的微信朋友圈让你焦虑了吗?
原创或推荐文章请发送至邮箱:xiaoxi@pmcaff.com
PMcaff合作媒体:Chinaz