前段时间做过了一次比较系统的可用性测试。因此写了这篇文章作为个人对可用性测试的梳理和反思。
可用性测试是一个体量很大的学科，仅仅从形式和平台两个维度去分，就可以细分出十几种不同的可用性测试，而每种不同的测试其研究方法还有相当大的不同。
而且我相信，即使是同样的一个目标，由不同的角色去设计和执行（比如咨询公司的用研人员，某些公司专门的用研部门，或者业务线上的产品经理）也会有不同的方法和侧重点，因此本文数千字的篇幅是不可能涵盖可用性测试的方方面面的，甚至连作为某一种特定的可用性测试的工具书都不够详尽。
这里只是我作为一个业务部门里的交互设计师，就我们采用的实验室的可用性分析（usability lab studies）来谈一谈进行可用性测试的一些技巧和需要注意的点——总的来说，站在测试的大目标下，我们的每一个决定和方法都需要紧贴在目标上，每一个步骤都需要有合理的前因后果和清晰地逻辑。
本文分为“可用性测试的时机”，“可用性测试的目标”，“以目标为导向的方案设计”和“测试的过程”四个部分。
可用性测试的时机
广义的可用性分析是指让用户使用真实材料（包括真实的产品，模块，页面，原型，概念等）来探索其可用性的研究。包括了概念测试（concept testing），实验室的可用性分析（usability lab studies），远程的有指引可用性测试（moderated remote usability studies），快速迭代的测试和评估（rapid iterative testing and evaluation），眼动分析（eyetracking）等。 我们将这些可用性测试的方法放到用户研究方法的“定性—定量／态度-行为”坐标系中，我们发现各种可用性测试方法涵盖了定性到定量的整个坐标轴，而在纵坐标轴上，可以看到可用性测试是偏向行为的。 因此，不论是要对系统的可用性得到一个概括性的结论，还是要针对一个模块的可用性进行精确的数据分析，我们都可以通过不同的测试方法来完成。然而不论是哪一种方法，可用性测试的核心都是建立在观察上的。
那么，我们应该在什么时候去发起一次可用性测试？NNG的联合创始人Jacob Nielsen列出了以下三个场景：
- 在迭代的过程中，特别是两个迭代之间的时候。我们需要知道我们本期的设计是否解决了之前的问题，或者我们还需要继续改进我们的设计方案。
- 数据不会骗人——对于竞品的可用性分析，可用性测试得到的指标是非常有用的。
- 在每一次新的发布之前，我们需要在脑海中有一个清晰的目标。当我们对现在的设计方案没有很大的把握的时候，一次可用性测试可以告诉我们，新的版本是不是已经准备好发布了。
可用性测试的目标
这一部分我分两点来说，第一是什么是可用性以及我们是怎么用可用性测试来衡量它的，第二是可用性测试是用来做什么。 usability.gov为可用性给出的定义是“用户与一个系统交互时体验的质量”，而构成可用性的三个因素包括效度，效率和主观满意度。一般来说，我们通过以下的几个维度来衡量系统的可用性：- 设计的直观性：产品的整体架构符合用户的心智模型，换句话说，用户可以轻松直观的了解产品的结构，并利用导航系统在界面间清晰的移动
- 清晰性：界面元素表意清晰，交互方式和结果符合用户的预期
- 可寻性：用户可以快速准确的找到界面的关键信息
- 易学性：一个新用户可以轻松的完成一个任务
- 使用的高效性：一个老用户可以用系统高效的解决问题
- 可记忆性：在第一次访问这个系统后，用户可以记住足够的内容来帮助他在以后使用的时候可以高效的使用
- 发生错误的频率和严重性：用户在使用系统时发生错误的频率，这些错误的严重性，以及用户能否修正这些错误
- 主观满意度：用户在使用时的总体体验，以及他们有多喜爱这个系统
- 衡量产品的可用性
- 定位产品问题及产生的原因。总的来说，可用性测试用于优化产品，但是不能告诉我们应该去做什么需求，或者是用户想要什么。
以目标为导向的方案设计
以目标为导向其实是我一直非常认可的一种设计思想，这种思想同样也体现在了我的用户研究上。这里也分为两个方面：- 一是和其他所有的用户研究方法一样，我们采用研究学习螺旋模型来规划我们的可用性测试。这种模式的核心在于，研究的每一步都是建立在目标之上的；
- 二是，我们方案里的每个行为都必须是有目的的——在我刚开始做用户研究的时候，常犯的一个错误就是全套照搬别人的流程，然而在研究结束后的反思里才意识到，每一个行为都应该是有意义的，根据实际情况的不同，我们也需要对标准的流程进行修改或者补充。
设计了一个好的研究方案，就成功了一大半了。如上文所说，可用性测试的最大目的就是：
- 研究用户是否能顺利的通过系统达成目的
- 定位问题。第一点比较简单，第二点稍微复杂一些。
- 通过关键假设将目标拆分为可以度量的条目
- 在完成了任务的设计后，需要在任务流程里设置详细的观察点。
- 用户可以清晰的理解每条记录里具体信息的意义
- 我们提供的按价格，评分，星级的排序机制可以满足用户需求的
- 用户在寻找左侧边栏的筛选控件时会遇到困难。那么根据这样一些假设，我们只要设计出可以全部覆盖它们的任务流程，就可以很顺利的达成目标了。
至此，我们已经走在了正确的道路上，我们的任务可以覆盖我们目标可能存在的所有问题。现在再来回想一下我们在一场可用性测试里的目的：精准的定位问题，以及挖掘问题发生的原因。
那么，我们还需要一些方法来将测试的过程更加的精细化。在这里我采用了设置观察点的方法，这种方法的机制是：尽量将页面上可能的触点罗列出来，而所有的触点分为和任务主流程有关的触点（A）和无关的触点（B）。
在用户完成任务时，我们需要观察所有的触点，此时对A类触点的观察可以覆盖到所有和测试目标有关的用户行为，而对B类触点的观察可以覆盖到系统里一些其他的可用性问题。
在用户完成任务后的复盘过程中，我们需要就关键的，以及刚才出现问题的触点与用户进行访谈，以便确认问题发生的原因。这个方法的意义在于，在访谈的过程中，观察者可以带着目的和清晰地条例去观察用户行为，在之后的复盘中，可以更加系统的去还原用户的行为，特别是那些通过直接观察没有办法得出结论的点。
打个比方：如下图所示：还是预订酒店的例子。
我们的目标是测试酒店搜索结果页对于一个新用户的的可用性，用户任务是在该页面找到一家价格适中，位置靠近老城，评价优异，可供全家4人住宿的房间。
在酒店信息页，可能的A类观察点就包括了展示酒店信息的所有卡片；卡片内的所有字段，链接，标签，图标，按钮；筛选控件；排序控件；地图入口；切换浏览方式的控件等。可能的B类观察点就包括了重新搜索的控件，该目的地其他日期的预定情况等。
在一场真实的可用性测试中，我们需要知道完成任务的所有路径，以及最高效的那些路径，而用户很有可能会采用一些更低效的路径，我们需要去观察用户是如何做出这样的选择的，并且在测试完成之后的复盘中，我们需要去向用户了解是如何去认知其他的路径的。
比如在这个例子中，如果用户想要高效的找到合适的住宿，他可能需要采用地图视图，价格筛选器，以及按照用户评分对列表进行排序。而在实际的操作中，用户有可能不会用到这些组件，他们甚至可能会不对列表进行任何操作就直接在列表中逐项浏览。那么在测试的过程中，我们就需要去留意用户是怎样选择并使用了一个组件，在过程中是否有误操作，犹豫等。
在测试完成后，需要去询问用户“请问你注意到列表上方的排序控件了吗？”，“我注意到你刚才想要去点击地图，但是最后放弃了，这是为什么呢？”，“你有没有想过需要将可以住4人的酒店筛选出来呢？你觉得你应该怎样去操作才能完成筛选呢？”等。
在完成了目标，关键假设和观察点的梳理后，我们就可以开始拿着我们的测试计划开始准备材料，数据，脚本以及用户招募了。但是在走进房间开始和用户进行近距离接触之前，我通常会建议团队再做以下这件事情：对可用性测试的计划本身进行一次测试。一是为了保证测试过程的流畅，二是为了再次检查我们的测试方案是否已经足够细致和全面了。
在这样一个非正式的测试里，我们通常会邀请一个同事（被试者对系统的熟悉程度需要根据测试目的来定），并严格按照正式测试的环境和流程进行。
在这个流程中，我们可以看到准备的材料和数据是否合理，能否覆盖我们的测试目的；对于那些设计多平台多设备多端口的任务，我们需要去保证数据和流程的流转可以正常的进行。在这样的测试里，得到的关于可用性的结论是没有太大参考意义的，但是我们可以通过走完一个完整的流程对之前列出的观察点进行查漏补缺。
最后就是招募用户的数量。根据Nielsen和Landauer的研究，可用性测试发现系统中问题数量与测试人数遵循以下公式：
P=N （1-（1- L ） n ）
其中P为发现问题的数量，N是系统中存在问题的总量，L是通过研究单个用户可以发现的用户比例，根据经验L的值一般被定义为31%。 此时我们可以绘制出P关于n的曲线，如下左图所示。 此外，Nielsen还给出了以下的一份数据：根据83例NNgroup最近进行过的可用性咨询的案例分析可以得出下右图的可用性问题数量——招募用户数量的关系。我们可以看到，在招募5-8名用户的时候，就足以暴露出系统中的大部分可用性问题了。而此时再测试更多的用户，并不会为我们的洞察带来明显的提升。 因此在我们的可用性测试中，我通常会遵循以下的原则——这也是其他定性用户研究用户招募的一个通用原则——至少对5名用户进行测试，当测试完第五名用户的时候，如果我们发现问题的分布足够集中，或者是不再出现新的问题，那么针对这个目标的可用性测试就可以结束了。如果此时还在暴露出新的问题，那么我们就还需要继续进行测试，直到不再暴露明显的新问题为止。
测试的过程
关于测试的过程我就不在这里详细描写一次可用性测试所有的步骤了，下面列出几个我认为可以最大程度上提升研究质量的点。不要试图去消灭测试的“人为因素”
一次典型的实验室环境的可用性测试包括了一把椅子，一张桌子，用户坐在屏幕前完成任务，由录像机和各种传感器来追踪所有发生的事情——包括眼动，面部表情，身体语言等等。这样做的目标就是试图消灭掉试验中的一切实验因素。甚至有一些用研人员建议“不要和用户说话”。 虽然我完全同意倾听多于说话的观点，但是——即使我完全保持沉默，甚至是躲在另外一个房间，用户总是会知道他们是正在被观察着的，我不用做任何事情，我的身份就是一个观察者，这个时候适得其反的事情就发生了。- 用户会把我视作一个标杆或者权威，他们会用他们的答案和行为来取悦我
- 因为他们惧怕在我眼中显得愚蠢，因此他们会惧怕犯错
- 他们的行为模式会和自然状态下截然不同，他们会使用一些前所未有的方式去和我们的产品交互
Think Out Loud&测试后的复盘
测试的目的之一是挖掘出更多的信息，而用户的操作只能展示出测试时所发生的事情的很小一部分，除了仔细的观察之外，我们会要求用户在使用时将自己的思考/决策过程说出来，包括- 当进入这个页面的时候，我首先注意到了哪些东西？
- 我认为这个页面是做什么用的
- 我下一步想做什么？我觉得页面上哪些元素可以帮助我？
- 当我完成某一操作后，我预期会有怎样的反馈？那真实的反馈是怎样的？
- 界面上有哪些元素是我不明白的？
- 我进行了误操作，我应该怎么消除这个错误？
- ……
- 你为什么要点击多次撤销，而不去点击清空按钮呢？
- 我注意到你将鼠标移到了A按钮上，但是最后又没有点击呢？
- 我注意到你在进行B操作的时候显得有些焦躁，这是为什么呢？
- ……
对测试方案的迭代
如果我说“我需要在研究的过程中修改我的研究方案”，很多研究者心中的第一反应多半是WTF？我理解很多人将中途修改方案视为洪水猛兽，因为这和“得到一个客观的结论”的目的似乎是相悖的。他们说你需要5名用户去做一模一样的任务，这样才能得到一个有意义的结论。 我当然同意要想办法得到更客观的答案，但是这并不意味着我们的研究方案就自始至终一成不变的了。我们应该在保证目标和关键假设不变的前提下，在每一次测试之后，对我们的观察点以及复盘时的问题进行迭代——这个习惯同样适用于其他的定性用户研究方法——因为我们的观察点和问题的拟定都建立在我们对系统了解的基础上，但是有的时候，用户和我们设计的体验是两回事情，曾经有同事反馈说，自己设置的观察点很多都没有用上，而用户的很多行为完全出乎了他的意料。 打个比方，如果前两个用户在任务的最开始都统统选择了一条我们预料之外的路径，而我们都没有在这条路径上设置任何的观察点与问题。那么，如果我们不在后续的研究上加上“你为什么会点击这个入口”这样的问题，那么我们永远也不会知道用户这样奇怪举动背后的原因。参考文献
- Usability Engineering, 1993, Jakob Nielsen
- Qualitative Research Design, 1996, Maxwell, https://www.sagepub.com/sites/default/files/upm-binaries/5057_Maxwell_Chapter_5.pdf
- UX Research Cheat Sheet, 2017, Susan Farrell, https://www.nngroup.com/articles/ux-research-cheat-sheet/
- How Many Test Users in a Usability Study, 2012, Jakob Nielsen, https://www.nngroup.com/articles/how-many-test-users/
- Why You Only Need to Test with 5 Users, 2000, Jakob Nielsen, https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
- How Do I Do User Research, 2014, Katerena Kuksenok, https://medium.com/hci-design-at-uw/how-i-do-user-research-fabc89acc7c9
- Don’t Listen to Users and 4 Other Myths About Usability Testing, 2016, Icon8, https://uxplanet.org/dont-listen-to-users-and-4-other-myths-about-usability-testing-a061a0b746b8
- UX Design Process Best Practices, UXPin, https://www.uxpin.com/studio/ebooks/ux-design-process-documentation-best-practices/
- The Guide to Usability Testing, UXPin, https://www.uxpin.com/studio/ebooks/guide-to-usability-testing/
- A 5-Step Process For Conducting User Research, David Sherwin, 2013, https://www.smashingmagazine.com/2013/09/5-step-process-conducting-user-research/
爱盈利-运营小咖秀(www.aiyingli.com) 始终坚持研究分享移动互联网App运营推广经验、策略、全案、渠道等纯干货知识内容；是广大App运营从业者的知识启蒙、成长指导、进阶学习的集聚平台；
想了解更多干货知识，请关注公众号运营小咖秀（微信搜索: yunyingshow）
【转载说明】 若上述素材出现侵权，请及时联系我们删除及进行处理：8088013@qq.com
