无实验室的可用性测试：初学者指南

由FabricLoop团队 · 2026年5月 · 4分钟阅读

可用性测试有一个不应得的昂贵和缓慢的名誉。当人们听到"用户研究"时，他们会想象一面单向镜、一个拿着夹板的主持人和两周的时间表。那种测试版本存在并有其用途——但它不是大多数产品团队大多数时候需要的版本。

大多数团队需要的版本更简单：五个用户、一个Figma原型或一个测试环境、一个视频电话和每个会话45分钟。做得好，这会在他们出货前表面化大多数严重的可用性问题。持续做——甚至每个冲刺一次——它会产生对产品质量的复合改进，任何数量的发布后分析都无法复制。

这是如何从头开始做的。

"五个用户会找到85%的可用性问题。其他15%通过发货和观看找到。不要让完美样本量的追求阻止你运行任何会话。"

四步测试会话

可用性测试会话流

招聘

找到5个与你的目标用户匹配的参与者。质量优于数量。

脚本

将3–5个任务写成逼真的场景，而不是指令。

运行

不引导地观察。你的工作是观看和倾听，而不是帮助。

综合

同一天汇报。将观察分组为模式，而不是引用列表。

五个参与者是大多数可用性测试的正确数字。Jakob Nielsen的研究确立了五个用户发现大约85%的可用性问题，此后有递减回报。在设计过程的不同点上运行三个五个用户会话比一个有十五个的会话更有价值。

招聘标准比数字更重要。与五个与你的目标用户密切匹配的人进行可用性测试会揭示真正的问题。与不匹配的十五个进行测试会产生噪音。定义两到三个筛选标准——角色、使用背景、技术舒适度——并坚持下去。

对于大多数团队来说，最快的招聘路线是给已经给予联系许可的现有用户发邮件。提供适度的激励——£20礼品卡对于45分钟的会话就足够了。目标是在同一周内安排会话；招聘和测试之间的间隔越长，缺席率越高。

最常见的脚本错误是将任务写成指令："单击设置，然后导航到通知，并将你的偏好更改为..."这告诉用户要做什么，这意味着你在测试他们是否可以遵循方向，而不是界面是否直观。

将任务写成场景代替："想象你收到太多通知，你只想在有人直接提及你时收到警报。给我看你会做什么。"这给了用户一个逼真的目标，让你观察他们实际如何导航——包括他们在哪里感到困惑。

试点会话规则 在你的第一个真实参与者之前，总是与队友一起运行脚本。当写出的脚本在大声说出时一致地产生困惑看起来清楚。15分钟的试点揭示了尴尬的措辞、模糊的任务和时间问题——修复几乎不需要成本。

主持可用性测试最难的部分是抵制帮助的冲动。当用户感到困惑时，每个本能都说要跳入并显示他们在哪里点击。但困惑就是数据。一个在努力的用户告诉你界面有问题——当你介入时，你失去了信号。

要求用户在整个会话中大声思考："当你进行时，只是告诉我你看的是什么和你在想什么。"这产生了关于他们心理模型的持续数据流。注意不仅仅是错误，还要犹豫——在单击正确按钮之前暂停三秒的用户仍然揭示了设计问题，即使他们最终成功。

鼓励陷阱 "你做得很好"是你在可用性测试中应该从不说的谎言。感到他们做得很好的参与者停止报告困惑。保持中立："谢谢，继续。"承认努力，而不是表现。

综合步骤是创建大多数价值的地方——也是大多数团队削减角落的地方。五个会话的原始笔记不是发现。当你作为一个团队汇报、按主题对观察进行分组并分配严重程度等级时，它们就成为发现。

在会话的同一天进行汇报，观察仍然新鲜。将问题分组为三个桶：关键（用户无法完成任务）、中等（用户完成任务但有显著困难或错误）和轻微（未阻止完成的摩擦）。关键问题需要在启动前修复。中等问题应该在下一个冲刺中优先考虑。轻微问题进入待办事项。

在一页中写发现：前三个关键问题，来自至少两个参与者的证据，以及每个的建议设计更改。任何需要超过那个的空间的东西都属于单独的文档。

FabricLoop如何支持可用性测试 会话笔记、录音、综合和设计决策属于一起。FabricLoop线程让你从每个会话附加原始笔记、与更广泛的团队分享综合并直接链接到随之而来的设计更改——所以未来的团队成员可以看到不仅改变了什么，而且为什么。