做可用性测试时只需要名用户参与测试就够了

　　精心设计可用性测试无疑是浪费资源。最佳的结果是测试用户不超过5个用户，在测试过程中尽可能多地采用小测试。
　　测试用户数量曲线
　　有些人认为可用性是非常昂贵和复杂的，用户测试应该预留给罕见的网页设计项目（补充，目前常见的多是应用或者服务等产品），而且预算庞大、时间表繁琐。
　　其实，不是这样的。精心设计可用性测试无疑是浪费资源。最佳的结果是测试用户不超过5个用户，在测试过程中尽可能多地采用小测试。
　　在早先的研究中，TomLandauer和我表明，在n个用户的可用性测试中发现的可用性问题的数量是：
　　N（1（1L）n）
　　其中：N是设计中可用性问题的总数，L是测试单个用户时发现的可用性问题的比例。L的典型值为31，在我们研究的大量项目中取平均值。
　　绘制L31的曲线得出以下结果：
　　曲线中，最引人注目的事实是：零用户给出的洞察数为零。
　　只要你从一个测试用户那里收集数据，洞察数就会出现，你已经学会了近三分之一的知识来了解设计的可用性零和即便是一点点数据之间的差异是惊人的。
　　当你测试第二个用户时，你会发现这个人和第一个用户做了一些相同的事情，所以你掌握的东西有一些重叠。人们是完全不同的，所以从第二个用户那，也会有一些第一个用户那没有的新的东西出现。所以从第二个用户那也会增加一些新的洞察力，但不像第一个用户那么多。
　　第三个用户会做很多事情，这些事你已经从观察过的第一个用户或第二个用户那观察过了，甚至有些事情你已经看过两次了；此外，第三位用户当然也将产生少量新数据，这些数据仅是第三位用户产生的。
　　随着添加越来越多的测试用户，你能获得的越来越少，因为你会一次又一次地看到相同的内容。真的没有必要多次持续观察同一件事，并且你将很乐意回到绘图板并重新设计网站或者产品，以消除可用性问题。
　　在第五位用户后，通过反复观察相同的发现而浪费了时间，但没有获得太多的新东西。
　　迭代设计
　　曲线清楚地表明：你需要测试至少15个用户才能发现设计中的所有可用性问题。
　　那么，为什么我建议用更少的用户进行可用性测试呢？
　　主要原因是最好是在许多小测试中分配用户测试的预算，而不是在单个精细的研究中将所有内容都放在一起。让我们假设你有资金招募15位典型客户并让他们参与你的测试。将这些预算用在每组5个用户的3项研究上！
　　你想进行多个测试，因为可用性工程的真正目标是改进设计，而不仅仅是记录它的缺点。在进行5名参与者的第一次研究发现了85的可用性问题后，你将需要在重新设计中解决这些问题。
　　重新设计之后，你需要再次进行测试。尽管我说重新设计应该解决第一次研究中发现的问题，但事实是，你认为重新设计可以克服这些问题。但由于没有人可以设计出完美的用户界面，因此不能保证新设计确实能够解决问题。第二次测试会发现重新设计是否有效。而且，在引入新设计时，即使旧的可用性问题得到修复，总会有引发新的可用性问题的风险。
　　此外，另外5名用户的第二轮测试将发现第一轮测试中未发现的15的原始可用性问题中的大部分。（仍然会残留2的原始问题这些将不得不等待第三轮测试才能确定）。
　　最后，第二轮测试将能够深入探讨网站或产品基本结构的可用性，评估信息架构、任务流程以及与用户需求匹配等问题。在最初的研究中，这些重要问题常常被模糊处理，因为用户被愚蠢的表面级可用性问题困扰着，这些问题阻碍了他们真正深入使用网站或者产品。
　　因此，第二轮测试将作为第一轮测试结果的验证过程，并有助于提供更深入的见解。第二轮测试总是会导致新的（但较小的）可用性问题，并在新一轮的设计中得到修复。同样的见解也适用于这种重新设计：并非所有的修复都可行；清理界面之后将会发现一些更深层的问题。因此，还需要第三轮测试。
　　最终的用户体验通过3轮测试得到了更多的改进，每组5个用户，每个用户进行一轮测试，一共15个用户。
　　为什么不用单个用户进行每轮测试？
　　你可能会认为15个使用单一用户的测试甚至比5个用户的3轮测试更好。曲线确实表明我们从第一个用户那里了解的东西，比从任何后续用户那里了解的要多得多，所以为什么要继续下去？两个原因：
　　总是有被单个人的虚假行为误导的风险，他们可能会以意外或非典型的方式执行某些行为。即使3个用户也足以了解用户行为的多样性，并洞察什么是独特的、什么是普遍的。
　　根据测试的风格，用户测试的成本效益分析提供了35个用户的最佳比例。计划和运行一项测试总会有一个固定的初始成本：最好在多个用户的研究结果中降低这个初始成本。
　　何时测试更多用户？
　　当一个网站或者产品有几个高度不同的用户群时，你需要测试其他用户。该公式仅适用于以相当类似的方式使用网站或产品的用户。
　　例如，如果你有一个供儿童和家长使用的网站或产品，那么这两组用户的行为就会有很大差异，因此有必要与两组人员进行测试。对于旨在连接采购代理和销售人员的系统来说也是如此。
　　即使用户群体差异很大，两组的观察结果仍然会有很大的相似之处。毕竟，所有的用户都是人。此外，许多可用性问题都与人们与网站或产品互动的基本方式，以及其他网站或产品对用户行为的影响有关。
　　在测试多个不同用户组时，不用像单一用户组的单个测试那样，包含每个组的多个成员。观察之间的重叠将确保从针对每个组较少人员的测试中得出更好的结果。我建议：
　　如果测试两组用户，每个类别有34个用户
　　如果测试三个或三个以上的用户组，则每个类别有3个用户（你总是希望每个类别至少有3个用户，这样就能确保涵盖组内的各种行为）
　　参考
　　Nielsen，Jakob，andLandauer，ThomasK。：Amathematicalmodelofthefindingofusabilityproblems，ProceedingsofACMINTERCHI’93Conference（Amsterdam，TheNetherlands，2429April1993），pp。206213。
　　注
　　译文中对redesign（重新设计）的翻译，我理解为重新规划、调整，包括产品需求、UIUE、开发等各个环节，而不是单指设计UIUE环节。
　　另外，我仔细思考了下这里的可用性测试范围其实是针对单一功能而言的。为什么？当产品用户类型不同，层次不同的时候，总体的测试用户量会变的非常大，但就单一类型的单一层次来说，5个人基本上就符合文章中提到的范围了。
　　作者：JakobNielsen
　　原文地址：https：www。nngroup。comarticleswhyyouonlyneedtotestwith5users