你只需要5个用户去做可用性测试

设计文章 / 用户研究 | 2017-05-10 | 发布者: mobileui

有些人认为可用性测试的「投入产出比」比较低，只有罕见的网页设计项目才有资格使用这种研究方法，才能承担大额的预算和奢侈的时间表。这是不对的。过于精心设计的可用性测试是一种资源上的浪费。最好的结果来自不超过 5 个用户的测试，尽可能分解你的可用性测试变成小测试。

在更早的研究中，Tom Landauer 和我表明在 N 个用户的可用性测试中发现的可用性问题的数量是：N(1-(1-L)n)

其中 N 是设计中可用性问题的总数，L 是测试单个用户时发现的可用性问题的比例。 L 的典型值为 31％，这是我们研究的大量项目的平均值。绘制 L = 31％的曲线得到以下结果：

曲线最引人注目的真理是：零个用户只会发现零个问题点。

从第一个用户开始测试，你就会开始发现问题点，而且几乎已经发现了近三分之一可用性问题点。从 0 到 1 数据之间的差异是惊人的。

当您测试第二个用户时，你会发现此人执行的某些操作与第一个用户相同，因此你能得到的内容会有所重叠。但人不是绝对相同的，也会有一些不同于前者的新的发现。所以第二个用户添加了一些新的见解，但不会像第一个用户那样多。

第三个用户可能会做一些你已经看过两次的事情。当然，第三个用户将继续生成少量的新数据，即使不像第一和第二用户那样多。

在第五个用户之后，你就会常常浪费你的时间在重复观察相同的结果上。

迭代设计（Iterative Design）

译者：在一个可用性测试中，大约 15 个用户可以发现 100% 的问题。但是，并不建议这么做，更好的方案是，把这 15 个人分成 3 组（每组 5 人）进行测试。第一组的可用性测试就可以发现大约 85% 的问题，带着这些问题点进行设计，带着新的设计对第二组 5 人用户进行测试，不仅可以发现剩下的 15% 可用性问题点，还可以帮助用户深入地探究站点基本结构的可用性，评估信息架构、任务流程以及与用户需求匹配等问题，避免所有的用户都被表面的可用性问题困扰，第三组（5人）测试同理。

曲线清楚地表明，您需要至少测试 15 个用户来发现设计中的所有可用性问题。那么，为什么我建议用少得多的用户进行测试？

主要原因是，最好将您的预算分配给许多小型测试，而不是将所有内容都放在一个详细的研究上。让我们说，你有资金招聘 15 个代表客户，并让他们测试你的设计。这个预算花在 3 个研究，每个用户 5 个用户！

你想要运行多个测试，因为可用性测试的真正目标是改进设计，而不只是记录其弱点。在有五个参与者的第一个研究发现 85％的可用性问题之后，你将希望在重新设计中解决这些问题。

创建新设计后，你需要重新测试。即使我说重新设计应该「解决」第一个研究中发现的问题，但事实是，你认为新的设计克服了这些问题。但是由于没有人能够设计出完美的用户界面，因此不能保证新设计确实能够解决问题。

第二个测试将发现新的迭代设计到底有没有作用。此外，在介绍一个新的设计时，还存在引入一个新的可用性问题的风险，即使旧的问题已经解决。此外，第二个研究（5个用户）将发现在第一轮测试中没有发现的大多数剩余的 15％的可用性问题。（仍然有 2％的原始问题留下 – 他们将不得不等到第三个研究被识别。）最后，第二个研究将能够更深入地探究站点基本结构的可用性，评估信息架构、任务流程以及与用户需求匹配等问题。

在初始研究中，这些重要问题常常被掩盖，用户被愚蠢的表面级可用性问题所困扰，阻碍他们真正深入思考。

因此，第二项研究将作为第一项研究结果的质量保证，并帮助提供更深入的见解。第二个研究将总是导致一个新的（更小的）可用性问题的列表，在重新设计中解决。

同样的步骤适用于这个重新设计：不是所有的迭代设计都是有用的，迭代设计后会又会发现一些更深层的问题。因此，还需要第三个研究。

最终用户体验通过5个用户的三项研究比15个用户1个研究提高的更多。

为什么不能只测试单个用户？

译者：看了上面的内容，你可能会有疑惑，按照上文叙述的思路，那研究者把 15 个人分成 15 组，每个人 1 组，15 组迭代测试和迭代设计岂不是更有帮助？下面解释你的疑惑。

你可能认为有一个单一用户的 15 项研究甚至比 5 个用户的 3 项研究更好。曲线确实表明我们从第一个用户比从任何后续用户了解更多，所以为什么要继续？两个原因：

总是存在被单个人的虚假行为误导的风险，一个人可能偶然或以不具代表性的方式执行某些行为，即使 3 个用户足以了解用户行为的多样性和洞察什么是独特的和什么可以推广。
用户测试的成本效益分析提供了大约 3 或 5 个用户的最佳比率，这取决于测试的风格。总是有与计划和运行研究相关的固定初始成本：最好从多个用户的调查结果中贬值这个启动成本。