编辑导语：做可用性测试时，要注意什么？大厂在做可用性测试时有什么不一样？找多少个用户做可用性测试才合适？本文就此问题做了分析和解答，希望对你有所帮助。
你是否常常觉得看不懂“可用性测试”这个东西，感觉它做法复杂、又不知道具体哪些环节必须做、哪些环节不用做？“大厂”做可用性测试是否会更严谨、写更多文档？究竟找多少个用户做可用性测试才合适？
假如你有以上疑问，这篇文章适合你继续阅读。本文部分观点来自《人因学手册》handbook of human factors and ergonomics的“可用性测试”一章。
我之前反复提过，我们体验设计现在的主流研究方法大部分从社会学或者心理学里移植而来，而可用性测试就直接脱胎于认知心理学的看家研究方法“实验法”。
假如有读者小时候上幼儿园的职业理想曾经是“做实验、当科学家”，那么恭喜你，当设计师会做可用性测试，某种程度上也算是部分实现了你当年的心愿。先给自己一点鼓励。
认知心理学的基本思路是把人的心理活动理解成一套像精密机械一样的信息加工系统，里面的各个零件可以拆开来各自研究的：比如人的注意力、记忆，或者某种感受。它有许多的研究内容都是很微观的概念和现象，这些（短期）现象发生得非常快、并且在自然环境下受各种因素影响干扰，很难测量。
因此为了在现象或概念间建立有力的因果关系，认知心理学作为横跨社科和自然科学两个领域的一门学科，向自然科学取经从而发展出了很成熟的控制实验技术（包括咱们比较常见的眼动仪实验）。
这个方法后来辐射到了各个其他社会学科中，又诞生了“实地实验”（field experiments，自然实验/社会实验）的说法，其思路很像我们今天经常做的AB test。
还是拿我们上篇文章的“可爱小猫论”作案例，假设你是一个很有才华的心理学家，发现小猫可爱程度会影响人的身心健康，养越可爱的猫越有利于身心健康。你要如何证明这一点？
答案是在实验室环境下严格地控制变量，通过对实验环境和环节的科学设置、对被试者情况的筛选和抽样来确保得到精准的结果。
比如你可以假设被试对猫的喜爱程度、猫的可爱度都可能影响实验结果，所以你可以被试分成4个单元小组：不可爱的猫配不喜欢猫的人、可爱的猫配不喜欢猫的人、不可爱的猫配喜欢猫的人、可爱的猫配喜欢猫的人。
在测量了人的初始身心健康程度后，让他们与猫呆3小时，然后再次测量人的身心健康程度。此外还需要配备一个对照组，这个组的人只能看3小时动画片——这就是一个很简单的小实验。
由此可以看出控制实验法和其他的研究方法相比，完全脱离了情境，所以实验室内的结果是否可以推广到实际生活中去，是需要打一个大大的问号的，但正因为如此，实验法也为验证因果关系创造了可能性。这一点也就是我之前在不要从“交互设计定理”入门交互设计中强调的。
说回到咱们的可用性测试，根据《人因学手册》的说法，可用性测试在80年代初被提出后马上在80～90年代风行于业界，影响了施乐（Xerox）、苹果、IBM等一代明星公司的产品评估流程。
在可用性测试引进之初从业者仍然比较严格地遵守控制实验的方法，对测试的环节设计、环境设置要求十分严格，是一种主要用于评估/对比设计方案的、定量的、脱离情景的手段。
举个例子，为了得到比较严谨的结果，可用性测试应该：
此外，各个公司会为了可用性测试搭建专门的、昂贵的可用性实验室。在实验室环境下对用户发布任务、进行测试，主要是为了规避噪音、灯光、外来人员打断等干扰因素对实验结果的影响。比如下图就是一个典型的可用性测试实验室。
90年代后随着可用性测试相关的应用和研究快速发展，可用性测试的概念也从验证性研究逐渐扩展到形成性的、探索性研究。
对可用性测试的要求也远远没80年代那么高了，到今天据我所知很多厂的用户研究部门把可用性测试理解地很宽泛，只要和用户有接触、只要设置了任务，都可以勉强讲是“可用性测试”。
这样做测试不再需要严格的实验室环境与变量控制技术，反而更加偏向实地调研，让用户在自己熟悉的环境中完成任务。
造成这个发展的原因其实有很多：
（1）软件开发模式变了
70～80年代盛行的瀑布流式开发，要求软件的设计开发者一次性完全完成一个环节后，再迈入下一个环节。比如你做设计时，需要提前想好未来需要应对的所有场景，一次把几千张设计图全部交付开发，开发开始写所有的页面，写完了这几千张图再上市。
这种开发模式在90年代被敏捷开发或迭代开发逐渐替代，这要求设计者出一版能用的先做出来，根据用户反馈再迭代之前的想法。因此，设计师对于快速定位设计问题的诉求大大提升，而可用性测试作为一种有用户参与的评估方式（可能是唯一一种），可以满足这种诉求。
（2）从调研目的的角度上来讲，我们作为设计者说到底和科学家做的事儿是不同的
对于科学家来讲研究概念之间的相互关系是有意义的，其最终的目的是形成一个具有解释力的学说。但对于设计师来说我们需要选出更优的设计，但并不关心究竟是哪个变量导致了设计最优、变量之间相互的关系是啥。
比如你可能做了两个稿子，A稿红色按钮放右边、B稿橙色按钮放左边，最终用户觉得B稿好，你的研究就结束了；而心理学家需要去思考到底是位置、颜色，还是别的什么因素影响了用户的什么体验，最终导致用户的决策？
对控制变量的严格要求，最终导致做一场严格的控制实验成本超高，除去复杂的控制变量带来的成本以外，为了让整个实验可以使用统计学分析，一般会要求每个单元小组的样本量大于30——做学术也许可以不那么考虑成本，但企业总是会思考投入产出比。
比如90年代软件业界就曾经把当时出现的专家启发式评估、认知走查这些无需用户参与、专家进行即可的方法当成可用性测试的廉价替代品。虽然后来被证实没有方法可以替代用户评估——专家走查出来的问题往往不是真实用户遇到的问题，而往往是一无伤大雅的小细节。
（3）90年代尼尔森写了一篇关于可用性测试样本量的文章，极大地鼓舞了用可用性测试做探索性研究、寻找可用性问题的做法
这篇文章我最开从《用户体验度量》里读到，我把这个理论叫“5个就够了”论。
尼尔森将此前为一些产品做的可用性测试与专家评估结果整理了一下，用一个泊松模型来预测参与可用性测试的用户数或参与评估的专家数与最后找到的可用性问题的比例之间的关系，最终“发现5个用户就能发现83%的问题”。
下面这张图能看出来假如拆分了可用性测试和专家评估，那么可用性测试需要的人数稍微多一些，5个用户大约能发现70%的问题。
现在看来尼尔森这个模建得说不上多么精细。注意这个图里的因变量是百分比，“1”代表“所有被发现的问题”，而不代表“本系统所有可能存在的问题”，所以尼尔森这个结论正确的解读方式是，假设他们测试了20个用户最终发现了10个问题，那么5个用户就能发现其中8个问题。
这种问题的重叠很有可能是因为对用户的不当抽样带来的。比如我们现在很多系统存在不同的用户角色与用户场景，用户个体的技能水平也有差异，因此不同用户组的关注点、问题点可能都是不一样的，很可能这一组用户找不到另外一组的问题，这一点在《用户体验度量》也有所说明。
后来尼尔森在他公司的网站上对“5个就够了”论做出了补充，当前版本的可用性测试结合了设计迭代的动作，更偏向定性的、个案研究的思路。按他现在的话来讲，可用性测试这个事情应该多次多轮的进行：首先选取5个人可用性测试-然后马上对设计进行修改和迭代-再找另外5个人重复进行可用性测试，看看他们有没有新的观点，如此多轮往复，最终打磨出一版好设计。
我们总结一下：假如你不太熟悉可用性测试的发展脉络，那可能会对这个东西有点犯迷糊：一会要设置任务，一会要发问卷，一会又要观察用户的动作；一会5个就够了，一会又要多找几个人。简单来讲：
最后关于样本量的事情我再多说两句。虽然调研的用户数量是一个困扰大部分设计师的问题，但根据我个人的经验来看，可用性测试是“多做比少做好，但做了一定比不做好”的一件事。对上线前的飞机稿来说，即使你只找1个用户看了你的设计，甚至你只找同事看了一眼你的设计，都会比你闭门造车要更好。不要惧怕做体验调研，也不要认为非要花多大代价才算在做体验调研。
作者：白话说交互；微信公众号：白话说交互（ID：gh_96e304585325）
本文由 @白话说交互 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。