不需要实验室的可用性测试：入门指南

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

可用性测试背着“昂贵又缓慢”的冤枉名声。人们一听到“用户研究”，脑海里浮现的就是一面单向镜、一个拿着记录板的主持人，以及长达两周的时间表。那样的测试确实存在，也有它的用武之地——但它并不是大多数产品团队在大多数时候需要的那种。

大多数团队需要的版本要简单得多：五位用户、一个 Figma 原型或测试环境、一次视频通话，每场45分钟。做得好，就能在产品上线前发现绝大多数严重的可用性问题。持续去做——哪怕每个迭代只做一次——产品质量就会获得累积性的提升，这是任何上线后的数据分析都无法替代的。

下面介绍如何从零开始做起。

四步测试流程

第1步：招募——测试谁，比测试多少人更重要

对大多数可用性测试来说，五位参与者是合适的数量。Jakob Nielsen 的研究表明，五位用户就能发现约85%的可用性问题，再增加人数，收益会递减。在设计过程的不同阶段各做三轮、每轮五位用户的测试，比一次测试十五位用户更有价值。

招募标准比人数更重要。五位与目标用户高度吻合的人参加测试，能暴露真正的问题；十五位不吻合的人参加测试，只会产生噪音。请确定两到三条筛选标准——角色、使用场景、对技术的熟悉程度——并严格执行。

对大多数团队来说，最快的招募途径是给已授权联系的现有用户发邮件。提供适度的激励——一场45分钟的测试，£20的礼品卡就足够了。争取在同一周内安排好测试；从招募到测试之间的间隔越长，爽约率越高。

第2步：脚本——写场景，而不是写指令

撰写脚本时最常见的错误，是把任务写成指令：“点击设置，然后进入通知，把你的偏好改成……”这等于告诉用户该怎么做，意味着你测试的是他们能否按指示操作，而不是界面是否直观。

请改为把任务写成场景：“想象你收到的通知太多了，你希望只在有人直接提到你的时候才收到提醒。请给我演示你会怎么做。”这样既给了用户一个真实的目标，也让你能观察他们实际是怎么操作的——包括他们在哪里感到困惑。

第3步：执行——你的任务是观察，而不是帮忙

主持可用性测试最难的地方，是克制想要帮忙的冲动。当用户感到困惑时，本能会驱使你冲上去告诉他们该点哪里。但困惑本身就是数据。一位正在挣扎的用户，是在告诉你界面出了问题——而一旦你介入，就失去了这个信号。

请用户在整个过程中边做边说出想法：“请一边操作，一边告诉我你在看什么、在想什么。”这样能持续获得关于他们心智模型的数据。不仅要记录错误，也要记录犹豫——用户在点击正确按钮之前停顿了三秒，哪怕最终成功了，同样暴露出设计问题。

第4步：归纳——找出规律，而不是堆砌引语

归纳这一步创造了大部分价值——也是大多数团队偷工减料的地方。五场测试的原始笔记并不等于发现。只有当你们作为团队一起复盘、按主题归类观察结果并评定严重程度之后，它们才成为真正的发现。

在测试当天就完成复盘，趁观察还记忆犹新。把问题分为三类：严重（用户无法完成任务）、中等（用户完成了任务，但遇到明显的困难或出错）、轻微（有阻碍但没有妨碍完成）。严重问题必须在上线前修复。中等问题应在下一个迭代中优先处理。轻微问题放入待办列表。

把发现写在一页纸上：最严重的三个问题，每个问题附上至少两位参与者的证据，以及针对每个问题建议的设计改动。超出这个篇幅的内容，应放进另一份文档。