这篇文章，希望整理一些东西，让大家对快速可用性测试（Guerrilla 可用性测试）有初步的了解。

作为产品经理，真的会、也的确是会遇到用户测试的各种问题，如何针对目标实施巧妙、灵活的用户研究，这一定让不少产品、设计师死了很多脑细胞。

可用性测试这个系列，从第一篇 Whatsapp 相关的可用性测试文章之后，到现在将近两个月的时间，我通过翻译、自己撰写，甚至是自己操作可用性测试，不能说是完全掌握，但入门应该是可以了。

这篇文章，希望整理一些东西，让大家对快速可用性测试（Guerrilla 可用性测试）有初步的了解。当然，如果可能的话，希望你能在工作中运用起来，并形成自己的方法。

什么是可用性测试？

从非严谨的角度来说，可用性测试大多是针对用户对产品“可用”和“好用”的测试，而较少的涉及“有用”的测试。我的理解是：“有用”大多是商业价值和市场研究的重点。

当然，如果你是市场研究院或者是战略计划制订者，使用快速可用性测试来达到目的也是可行的。这里有一些实例，能够帮助你了解可用性测试是什么：《6 个实例告诉你：可用性测试究竟是什么？》

从严谨的角度来说——相对的，而且是我自己的理解——可用性测试涉及产品的各个环节，而且相关方了解可用性测试，并且有意而为之的话，会对各环节的相关方有一定的帮助。你可以从《如何激发益相关者开展可用性测试？》这篇文章，初步了解下利益相关方可用性测试。

可用性测试获得的大多是定性的结果，主要是针对用户任务过程中，使用、操作、体验产品的时候的动作、表达等，总结归纳出对产品的简介，从而为后续调整优化产品简历一定的数据基础。

可用性测试的技巧

可用性测试是一种非常流行的技术，或许产品经理、设计师、UX设计师在以各自的理解实践和运用着。它快速、低成本，而且能获得真实的用户反馈。快速可用性测试的实施要从其自身情况决定，但有一些简单实用的技巧能够确保测试产生更好的结果。

这包括：

1. 确定目标；
2. 注意偏见；
3. 让参加者之情；
4. 给予奖励；
5. 保持真诚；
6. 鼓励用户反馈中；
7. 参与而不是主导；
8. 随时记录；
9. 有一个正式的反馈提取过程；
10. 按时完成。

你可以阅读《有了这 10 个技巧，做好 Guerrilla 可用性测试不用愁》来详细了解以上这些技巧。

7 步可用性测试

在《Guerrilla 可用性测试：7 步 DIY 属于你的可用性测试方法》一文中描述了，在开始快速可用性测试前，需要和团队一起了解以下 3 个问题：

• 可用性测试如何起作用？
• 从哪去找合适的测试志愿者？
• 什么时候开始测试？

接下来，你可以用这 7 步实施一次可用性测试：

• 第一步：设计任务列表；
• 第二步：定任务优先级；
• 第三步：将任务设置在场景中；
• 第四步：开始测试；
• 第五步：发现问题；
• 第六步：解决问题；
• 第七步：再次测试、验证，形成常态。

如果你觉得实施过程中依旧存在一些问题，希望你能阅读下《如何像专家一样针对原型进行可用性测试？》。文章中，对原型前的可用性测试、招募用户、撰写任务描述、原型保真度等做了详细的讲解。

可用性测试任务描述

测试过程中任务描述（或者说测试脚本）也对测试有重要的影响，任务描述、尝尽设置的优劣，对测试有不可忽略的影响。如果任务不对，你做什么都是错的，当然可用性测试也不会收到什么有效的反馈。

在《Guerrilla 可用性测试：7 步 DIY 属于你的可用性测试方法》中，你应该对可用性测试的任务有了一定的了解，文中还举了几个什么是好、一般和不好的任务例子。而在如何把可用性测试的任务描述写的更好？中，比较详细清楚的介绍了如何写出更好的可用性测试任务描述，你不想了解下？

具体操作

在实施快速可用性测试的具体操作过程中，需要测试多少用户，才能满足测试的目的呢？

《可用性研究中要测试多少个用户？》和《做可用性测试时，只需要5名用户参与测试就够了》两篇文章中对快速可用性测试用户数量做了阐述，精心设计可用性测试无疑是浪费资源，最佳的结果是测试用户不超过 5 个用户，在测试过程中尽可能多地采用小测试。

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

其中： N 是设计中可用性问题的总数，L 是测试单个用户时发现的可用性问题的比例。 L 的典型值为 31%，在我们研究的大量项目中取平均值。

绘制 L = 31% 的曲线得出以下结果：

曲线中，最引人注目的事实是：零用户给出的洞察数为零。

只要你从一个测试用户那里收集数据，洞察数就会出现，你已经学会了近三分之一的知识来了解设计的可用性——零和即便是一点点数据之间的差异是惊人的。

当你测试第二个用户时，你会发现这个人和第一个用户做了一些相同的事情，所以你掌握的东西有一些重叠，人们是完全不同的。所以从第二个用户那，也会有一些第一个用户那没有的新的东西出现，所以从第二个用户那也会增加一些新的洞察力，但不像第一个用户那么多。

第三个用户会做很多事情，这些事你已经从观察过的第一个用户或第二个用户那观察过了，甚至有些事情你已经看过两次了。此外，第三位用户当然也将产生少量新数据，这些数据仅是第三位用户产生的。

来自《做可用性测试时，只需要5名用户参与测试就够了》。

如果你想了解有关卡片分类测试以及定量研究测试的测试用户数量，推荐阅读以下两篇文章：

《卡片分类法解析：究竟要测试多少用户？》

《定量研究：需要测试多少用户？》

案例

整个系列中的最后一部分是案例，开始的时候我提及了 WhatsApp 的案例，后面我又补充了一些其他的案例，以加深对快速可用性测试的了解和运用。

案例主要有：

《WhatsApp Web 端应用可用性测试》

《Guerilla 可用性测试案例之一：Airbnb 愿望清单功能》

《Guerilla 可用性测试案例之二：Dropbox 照片功能》

《快速可用性测试案例之三：Apple iCloud 照片共享功能》（自测并实施）

《快速可用性测试案例之四：Yelp 提升 Web 体验》

《快速可用性测试案例之五：SoundCloud 移动应用重新设计》

《快速可用性测试案例之六：卫报变身之旅》

#专栏作家#

郑几块，人人都是产品经理专栏作家，前新浪微博产品经理。

本文系作者@郑几块 独家授权发布，未经本站许可，不得转载

题图来自Unsplash，基于CC0协议