可用性测试：准备和执行研究活动

通过前三天的介绍，我们已经知道可用性评估包括分析法和实验法两类，林林总总N多种方法。

之前的内容都是方法的基本介绍，本节我们聊聊，当我们进行一场可用性测试的研究活动时，如何准备和执行。

简单地说，可用性测试是针对特定功能的结构化访谈，一般使用产品原型进行。这包含三层含义：

1. 可用性测试属于用户访谈，因此基本的技术与用户访谈是一致的，不过它是结构化的；
2. 可用性测试针对特定功能，因此它比一般的访谈更具体，重在测试一系列任务能否顺利完成；
3. 除了产品生命周期晚期的总结性评估，可用性测试一般使用纸原型、模拟机或功能样机进行。

1 可用性测试的时间计划

可用性测试的活动本身时间很短，但从准备到完成，需要大约3周时间。

在筹备早期，你可以列一个大体的时间计划表。

时间	活动
t-2周	确定受试用户特征；启动用户招募
t-2周	确定需要测试的产品功能
t-1周	撰写测试活动脚本；创建测试任务；与产品团队讨论；检查招募进展
t-3天	完善测试活动脚本；检查测试任务；与产品团队讨论；完成用户招募
t-2天	完成测试活动脚本；安排测试活动预演；设置并检查活动设备
t-1天	基于预演略调活动脚本和测试任务，再做一次活动预演
t	测试活动 [通常进行1~2天，取决于用户和轮次]
t+1天	与观察员和团队讨论；收集所有资料，进行初步整理
t+2天	稍加放松，如有可能则休息一天，做做其他工作
t+3天	观看活动录像，做好记录
t+1周	整理笔记；写出分析报告
t+1周	将结果报告给产品团队；讨论并记录下一步研究方向

可用性测试其实是一种用户访谈，用户招募、活动主持、实验室设置等与用户访谈类似，本文不作详细展开，以下主要突出一些可用性测试比较特殊的内容。

2 确定需要测试的产品功能

为了不让可用性测试太过仓促，1小时到1个半小时的访谈只能安排不多于5个功能的测试。另一方面，测试活动时长不宜超过两小时，以免人员疲惫影响测试效果。

决定待测试功能时，应从功能集的情境下考虑，不考虑整体情况的局部测试是没有意义的。经验法则是，如果30秒能够画出界面草图，就可以对此功能进行测试。例如，你画一个导航栏草图，接下来考虑测试整个导航栏，而不是仅仅测试首页链接。

确定待测试产品功能时，首先应与产品团队会谈，至少包括产品经理、交互设计师和信息构架师，共同列出需要测试的五个最重要的功能。在讨论确定哪些功能之前，可以先查看：

• 经常使用的功能
• 新功能
• 主推功能
• 之前版本反馈中认为有问题的功能
• 如果使用不当就有潜在危险或不良副作用的功能
• 用户认为重要的功能

可以按照以下步骤确定功能优先级排序：

1. 让小组成员列出界面上最重要的内容，包括新功能或上轮测试后有重大改变的部分。重要性不仅体现在界面视觉上，更应该从业务需求优先级出发，例如：业务上关注下季度的盈利，那么相关功能就是重要的，即使在界面上非常不明显。
2. 画一个表格，第一、二列按重要性列举功能，并按1~5分级，5代表最重要，1代表不重要，第三、四列按满意度列举功能，最满意的功能标为1，最不满意的标为5。如有争论，可以请产品团队一起讨论。
3. 将重要性和满意度的得分相乘，将结果列在第五列，找出数值最高的功能，那就是最需要的测试。
4. 加一列备注，总结团队最想知道待测试功能的内容。

列出需要测试的功能清单后，就可以开始创建任务来检验这些功能了。

3 创建测试任务

测试任务，需要能够代表典型用户活动、并且只集中关注产品的某个功能。精心设计的测试任务应具有以下几个特点：

• 合理。应该代表用户的典型活动。例如，很少有人买90个不同的餐盘，快递到38个不同地址，一般可能是买几个盘子快递到同一个地址。
• 场景。产品只是用户的工具，本身不是最终目的。即使用户花很多时间来使用，也只是用产品来达成自己的目标。因此，用场景来描述任务，能让用户购买产品的理由和使用情境具象化。例如，“她的车轰轰作响像台喷气机，她需要一个消声器。”“这里有张小明的照片，PS一个傻乎乎的帽子微信给他吧。”
• 明确。为了保持受试用户之间的一致性、并将任务集中在希望测试的功能，应该设定明确的任务测试目标。例如，不要说“去买些东西”，而应该说：“你在商店橱窗中看到过一条很漂亮的裙子，就像图片上的这个，从产品目录中找到它，买一件吧。”
• 可行。不能设计用户无法实现的任务。通过产品信息结构只能找到可以找到的内容，而不能让用户去寻找不存在的东西。
• 顺序。任务应当按使用产品的实际流程来安排，让测试更真实。例如，电商网站将浏览任务安排在搜索任务之后。
• 通俗。理想的任务是每个受试用户对产品略知一二，但又不会了解太多。不要用专业术语。
• 长度适中。绝大多数功能，在可用性测试时都都不应该超过10分钟的时间。任务的时长度由3个因素决定：访谈时长、任务结构及待测功能的复杂度。

对于每个待测功能，至少安排一个任务进行测试，重要的功能应该设置2~3个任务。

此外，用研员也可以根据自己的经验和考量，提出自己的任务设计。例如，请用户测试电商务购物流程时，向用户提供已充值100元的账户会让用户很高兴，虽然他知道这钱其实不是真的归他所有。

尽管可用性测试总体上是定性研究，但也可以给任务设置一些定量指标，例如：

• 完成任务的速度
• 用户所犯错误的数量
• 从错误中恢复的数量
• 成功完成任务的人次

4 撰写测试脚本

完成任务创建之后，就可以开始撰写测试脚本。测试脚本其实是测试流程的列表，用来指导主持人保持访谈的一致性、并保证整个测试活动顺利进行。

测试脚本通常包含三部分：介绍和初步访谈；任务；总结。

可用性测试是结构化访谈，可以安排1/3内容来了解用户的兴趣和习惯、1/3内容关注任务执行，对重要功能进行测试、1/3内容用于测试活动管理。

可用性测试的访谈过程可以参考用户访谈部分，这里不作详细展开。

小结

本节我们介绍了可用性测试的准备和执行工作。鉴于可用性测试属于结构化访谈，部分准备工作和几乎全部执行工作未予详细展开，重点介绍了4项工作：

1. 可用性测试的时间计划；
2. 确定需要测试的产品功能；
3. 创建测试任务；
4. 撰写测试脚本。

微信 复制链接 X