绝对干货丨用户研究方法之可用性测试

【文章摘要】可用性测试是我认为在所有用户研究方法中能够呈现出最直接、最具有效结果的研究方法之一，掌握好可用性测试研究方法，对于产品的帮助很大。

可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。该产品可能是一个网站，软件，手机，或者其他任何产品，它可能尚未成型。测试可以是早期的纸上原型测试，也可以是后期成品的测试。

拿手机来举例子吧。通常有用户体验意识的设计人员或会在产品（这里指典型模块，比如通讯录、短信、电话、设置等）初成雏形并版本运行稳定的早期向用户研究部提出可用性测试需求，以便在产品面向用户开放之前提前得到用户的使用感受及反馈，及时做出迭代优化，进一步提高产品上市后的用户体验感。

我们通常建议设计人员在早期预留足够时间可以让我们对产品进行测试及迭代，这样也避免许多其他的不良状况出现，很多设计人员对产品开发流程和时间没有合理规划好，没有多余的时间让用户研究部进行目标人群的用户招募及计划有效的测试方案，又希望产品拥有良好的用户体验，通常就会把自己或公司内部员工当成目标用户，过一过用户的常用操作，然后快速迭代。但是，他们都忽略了，自己是设计该产品的专业人员，即使是同公司的其他部门的同事，作为整天浸泡在手机堆里的公司员工，你确定你能代表可能是小白的目标用户？结果很可能是，你觉得根本不是问题的问题，用户却摸不着头脑，用得苦不堪言，这对于设计人员而言，没有比这更糟糕的情况了。或许，这样的方法只能在测Bug的时候使用。

所以，设计人员或PM拥有研究意识，能够尽早提出需求，保证有足够时间给予用研人员去计划及实施，这点是非常重要的。

和需求方（这里指设计人员或PM）确认好需求后，项目马上展开了。整个可用性测试流程大概如下：

1.项目方案

项目执行前，计划好一份项目方案，包含项目目的，时间，招募用户人数，费用，输出物等；通常情况下，我们会先拟好用户招募标准给予第三方报价（为了节约时间），再撰写项目方案，但如果是用研部门自行招募用户(这里要考虑到实验室的问题，如果要设计人员一起参与，那就需要有单向透视玻璃实验室，避免测试时现场人数太多给用户造成紧张感影响测试效果)，费用可以预先大概估算；关于项目时间安排，建议和需求方进行讨论，执行时尽量让需求方参与，在旁听室里听听用户对他们设计的产品的真实反馈，冲击力非常大，我认为这比百页PPT要有效得多了。

2.用户招募

交给第三方市场调研公司招募用户，你一定要拟好目标用户的招募标准；首先你要清楚，你的产品是给什么人群使用的，或者是哪些人群使用你这款产品居多，这里可能包含他们所在的区域，年龄，学历，性别，使用行为等；不同产品对用户的使用经历要求也可能不一样，可能是曾经使用过你们公司产品的老用户，也可能是要新发展的潜在用户；在招募期间，你要跟踪招募进度，核实用户信息，确保有足够的备份参与者，尽量避免执行时发现各种不符合招募条件的意外情况，影响整个项目进度和质量。

3.专家走查

这里的“专家”当然指的是用户研究员，比起设计者开发者，用研员接触用户的机会更多，也更了解用户的行为与想法，在撰写执行方案之前，用研人员对要进行测试的功能或模块应该有一定的了解，将其进行详细全面的走查测试，找出可用性问题，这样做的优点第一可以有助于执行脚本设计，将严重级别高的问题设计在执行脚本里，探索用户对这些问题的反应及态度；第二可以增加用研员对即将要测试功能的熟悉度，避免执行时用户操作到哪个层级，可能会遇到哪些问题，甚至可能向你求助这些情况无可预判或不知所措；第三这也可以将用研员找出的可用性问题做一个吻合程度验证，考验用研员对用户使用行为的了解程度。

4.撰写执行方案

执行方案既是访谈脚本，内容主要根据需求方的具体需求来进行详细设计，哪些模块、功能是希望了解用户的反应及看法的，在上一段我说到专家走查的结果可以引进访谈脚本里进行设计；设计脚本时要特别注意以下几点：

1）用户信息验证

尽管在招募期间你会从第三方招募公司得到招募进度，里面包含了用户的基本信息及相关功能使用行为，但在你和用户未面对面接触之前，通过电话或网络沟通所得到的信息是不同的，所以在开始进行功能测试之前，第一模块先确认好在你面前的这位用户是你想要的，你能从他身上得到有效的反馈；如果实际情况不符合，那么和第三方沟通，及时停止访谈，不要觉得尴尬，这样才不会浪费彼此的时间。

2）模拟场景及任务设计

这是整个脚本设计的重点模块，你最好的连贯合理的场景将所有要测试的功能串起来，这样做的好处是能够让用户身临其中，想象自己在该场景下有可能做出的反应，比如通常我们测试手机的通讯模块，我们会这样设计：“故事背景：假设您刚刚购买了这个手机，我们接下来的操作都会在这个手机上进行。 任务一：今天我们是第一次见面，为了方面今后联系，请您将我的联系方式保存在手机上。“而每个任务，我们都会标注好这个任务的探寻点、观察点及控制点，哪些地方是需要在用户做出反馈后进行深挖及追问的，哪些地方是需要你观察用户的反应的，探索到哪些点可以截止追问，因为任务不同，你要侧重了解的内容也不同，”保存联系方式“我们是想了解用户的新建联系人方式，可能会涉及拨号盘，电话本，甚至是通过短信保存号码的短信功能，而当我们的重点是想了解用户对拨号盘的新设计反馈时，除了对他们本身操作习惯的了解和探索之外，我们也应该恰当地让用户尝试使用拨号盘，看看他们对这个模块的设计感受及反馈。

3） 用户的使用评价

通过了多个任务的使用操作后，用户对新功能的设计也有一定的主观感受和评价了，在脚本的第三部分，不妨设计一份用户的功能使用评价问卷，最好是选择题或分值题，便于统计，题目设计性质当然包括产品的易用性、提供的反馈、是否能快速帮助用户完成任务等，通过正反向的问题去设计，这样也可以验证用户的评价是否自相矛盾。

4） 用户的意见与建议

在用户操作任务的过程中，肯定会针对当下的操作说出他的想法或建议，在整个脚本的最后部分，可以再让用户总结回顾所有操作他认为好或不好的地方，是否需要改进，他有什么改进建议，当然，包括他对整场测试的想法，过程，也都可以提意见；最后部分属于是开放性的总结。

5.预测试

撰写完执行方案，并非就可以坐等执行日了，还需要找2-4位非专业人士（可以是朋友，同学、或者是公司行政、HR同事）对执行脚本进行测试，不要想着是预测试就随随便便过一轮，按照真正执行时的态度对待，这样可以测验脚本的细节，主持人（用研人员）也可以熟悉脚本，测验整场测试下来需要的时间是否在预期内，脚本是否需要修改，优化，语言是否通畅易懂等。

6.测试执行

经过一番辛苦的筹备，执行日终于到来了。工作人员这天请尽早抵达执行现场，检查设备是否齐全及完好，包括视听设备、录音录像设备，桌上还可以放些小零食、饮料、矿泉水等，在用户抵达之前做好这些准备工作；现场装饰最好营造轻松、自然的氛围，降低用户的紧张感。

执行时，不同角色有不同的任务。

主持人：拥有良好的主持仪态，注意着装大方，手机调静音，语速不紧不慢，不要紧张，你要知道，用户比你还紧张。测试开始，告知用户你们的测试目的，测试时长，现场的录音录像设备只是为了方便后续的结果分析，不会暴露个人隐私，让用户放松；在测试过程中，耐心观察用户操作，脑要比眼快，你要预测到下一步用户可能会做什么操作，你可以追问哪些问题，不要过于生硬依赖脚本，脚本只是辅助作用；你可能会遇到反应比较慢，操作比较慢，或者是不知道如何操作的用户，给予耐心，尽量鼓励对方，让对方独立完成操作，引导性的话语是在不得已的情况下才使用的。要谨记，可用性测试是为了测试产品而不是用户的能力。有时候用户的反应或说的话会很幽默，不要忘形大笑，这或许会伤害到对方。整个测试过程，要把握好每个任务的时间，不要在前面花费了过多时间，后面发现时间有点紧，就囫囵吞枣了。

记录员：为了不错失一些重要的原始数据，通常的情况下，会有2个记录员在观察室进行现场记录，在测试现场所记录下的第一手资料，将比测试后观看视频、听录音的效果更加深刻、真实。记录员在记录过程中，有以下六点要注意：

用户操作任务是否顺畅（遇到的阻碍）

我们想从用户身上得到什么信息（例如是否使用常用短语）

用户是否按照正常的操作路径去完成任务

用户是否知道自己在做什么？

用户遇到了什么问题？

例如：

1）不理解功能的命名等

2）术语（有利于产品开发的共同性和差异化个性

3）不知道在哪或不知道该怎么做

当用户进入错误的操作区域，能否自主从错误中恢复过来（是否需要帮助完成任务）

旁听人员（开发、设计、PM等）：每天泡在办公室里忙于开发迭代规划，如此近距离接触你的用户的机会可能不常用，在测试过程中，你可能会从用户嘴里听到关于对你所设计的产品的褒贬，不要激动，失望，生气，这些都属于正常现象，你来旁听的目的是为了得到用户的真实反馈，为了更有方向性地改善你的产品，在观察室这样的小黑屋里呆上一两天，可能会很烦闷，但尽量不要走神玩手机聊天，主持人和记录员比你还累，你可以认真记录下每个任务中你发现的不解问题，在测试结束时通知主持人将问题补上，几场测试下来，你一定收获良多，对你的设计方向豁然开朗。

7.数据分析

可用性测试完成后，需要根据记录员的记录、录像录音等资料，整理出用户在使用过程中遇到的可用性问题。

1）什么是可用性问题

典型的可用性问题会描述一个或多个参加者所遇到的问题并评估背后可能原因，典型的可用性问题包括：

l 任何影响了任务完成的情形

l 任何让用户产生某种疑惑的情形

l 没有看到应当注意的内容

l 任何导致错误的情形

l 错误的操作行为

l 不理解导航（结构）

2）辨识问题

非常有挑战性的工作之一就是确定哪些问题是真正的可用性问题、哪些问题只是偶尔发挥失常的结果。最明显的可用性问题通常是多数参与者都遇到过的问题，比如我们曾经测试短信功能，发现大多数用户都不理解“插入名片“的意思。

但是有些问题是比较模糊、不明确的。比如，在我们的翻盖产品W100的可用性测试中，仅有一位参与者无法认知到“摩天轮”关闭和开启的方式。这类问题是看作可用性问题，还是认为属于该位参与者的个人能力问题？在这种情况，我们应更多地关注用户的行为、思路、感知或者决策是否符合逻辑。也就是说，这些行为或想法背后是否有一致的说辞或者逻辑。比如，在测试中观察到一个参与者因为没有找到功能入口而无法进行语音功能的操作。任务结束后，你可以问他是否看到“语音图标”，如果看到为什么没有尝试点击。如果用户回答说这个图标是麦克风，认为该图标是录音功能的入口。这种情况很可能就是真的可用性问题。

3）整理可用性问题列表：

确认问题之后，将所有的问题整理成问题列表，方便之后的整理和分析。问题整理应包括以下内容：

问题位置：描述发现可用性问题所在的页面，如某些问题反复出现于多个页面，则标为“非特定单独页面”；

问题描述：对可用性问题具体含义的阐述，用语需简明扼要、易于理解；

分析建议：依据已制定的可用性原则，阐明目前的设计是如何违反原则的，基于该问题所提出的有针对性的解决方案，解决方案必须是直接可操作性；解决方案相对已存在的可用性问题，要更加简洁易懂，符合逻辑，参考用户的使用习惯。当研究人员对建议内容持有疑惑时，可与其他组员进行细致分析，做出合适建议。

违反原则：该问题所违反的可用性原则（这里指Nilsen十大可用性原则，针对不同产品有细节修改），如：一致性、符合用户认知、易学性等；

以上三项内容都是为了让研发相关人员能够快速定位问题和了解问题，让跨部门的沟通能够客观标准以及快速。因为问题列表作为可用性测试的输出物，会在交互、软件等部门流通和传递，因此“问题位置”可以让未参与测试的相关人员迅速地定位问题。“问题描述”则是对可用性问题进行简单明了的描述，快速地了解问题的具体情况。“分析建议”是用研人员从自己的专业角度和目标用户定位出发，结合违反的原则，具体地分析问题的情况，并提出可行性的意见。如果问题比较复杂，或者属于框架性问题，涉及范围比较大，可以跟的同事讨论。

“违反原则”中的原则是指尼尔森提出的可用性十项原则。最初十项原则是针对网页设计的，不过随着不断的完善和改进，对于手机的交互设计也很有指导意义。以十项原则为基础，除了可以在查找问题时有依可循，有统一的标准，更可以增加问题列表的权威性，便于推动后续的改进工作。

可用性十项原则具体如下：

l 系统状态的可见性

l 将真实世界与系统联系起来

l 用户的自由与控制权

l 一致性

l 预防出错

l 认知优于记忆

l 使用的灵活和有效性

l 美感及极简约主义设计

l 帮助用户识别，诊断和从错误中恢复

l 帮助和帮助文档

4）严重等级评估

不可能所有的可用性问题都是一样的，有些问题会让用户的操作无法继续进行，而有些问题让用户感觉使用起来不习惯，感觉心烦。在时间资源有限的情况下，应该集中精力解决严重的问题，因此对可用性问题的严重等级进行评估是很有必要的。

可用性问题的严重等级评估的方法有很多种。Nielsen（1993）提供了一种简便易行的方法，通过综合对用户体验的影响和相关任务的使用频率这两个因素来进行严重等级评估。这个评估系统非常直观，而且便于解释。

在实际的操作中，除了对用户体验的影响、使用频率这两个因素之外，加入了可克服度，从这三个因素综合评估可用性问题的严重性，评定优先等级。

问题频度：是指出现此问题的参与者数量；

影响程度：若一个问题直接导致用户无法完成任务，则此问题的严重程度较高，反之则低；共设三级评估系统。

1：不严重，对完成任务或进入下一界面影响较小；

2：较严重，对完成任务或进入下一界面有明显影响；

3：非常严重，导致无法完成人物或无法进入下一界面；

可克服度：是指用户克服可用性问题的难易程度；三级评估系统：

1：即使首次使用也容易克服；

2：需要学习或多次使用，渐渐克服；

3：多次使用都无法克服；

综合优先级=【严重程度分值+可克服度分值+（问题频度/参与者总人数）】/3

优先级说明：
2.4-3.0：问题严重，优先需要修改

1.8-2.3：问题较严重，次优先修改

0.1-1.7：存在改进空间，可跟进修改成本考虑修改

5）问题归类

在可用性问题的描述分析和严重等级评估完成之后，需要对问题进行归类。将问题归类，可以从战略的角度来分析应当着重改进哪些方面的设计。正常情况下，可将问题分为导航、内容、呈现方式和交互四大维度。

架构导航：为用户提供路径引导，帮助用户了解当前所处位置及如何到达目的地。包括在多个页面、视图或者应用之间的导航、在工具和菜单之间的导航，以及信息导航。

内容：提供给用户具有价值的信息点、功能和信息；

交互：系统的操作方式与用户的操作习惯是否一致。当系统模型与用户的心理模型一致或接近时，用户进行操作会非常顺畅，不需要付出额外的认知和学习；

呈现：系统界面的颜色、形状、大小、位置以及图标等设计；

将通过可用性测试发现的问题，一一归类到以上四种维度，合计之后得到各种维度的问题数。通过问题归类，可以很清楚的了解，设计或产品在各个维度上的情况。尤其是在进行竞争产品分析的时候，通过将问题归类比较，可以很清楚地看到产品的优势和劣势，为下一步的改进提供大方向。

需要说明的是，架构导航维度的问题一般都是比较严重、影响广泛的，并且在软件稳定、产品成型后，对其修改的成本是非常巨大，甚至是无法改进的。因此，在产品开发前期，对产品的架构进行合理的规划是非常重要和必要的。

掌握好一场可用性测试十分不易，需要投入许多精力，考虑许多细节，愿本文能给大家带来有价值的帮助！