可用性测试：五个人、三个任务、一张表

可用性测试不是考试，是找碴；它衡量的不是你做得对不对，是用户会不会走错。

一、第五个人之后，问题开始重复

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

宋迟做了一款合同模板工具，准备上线前找人看看。他原本打算找十个人，做到第五个时发现：前四个人已经把所有主要卡点踩了一遍——找不到模板分类、把「导出」当成「保存」、填完表单不知道下一步。

第五个人又踩了同样三处，只是顺序不同。他停了下来，把剩下五个名额取消，用省下的时间修问题。

这是单人产品做可用性测试最重要的一条经验：要的是问题清单，不是统计显著。 五个用户能暴露大部分重复出现的问题；再多人，边际收益主要落在只出现一次的边缘情况上。

宋迟还犯过一个错：第一版测试他找的全是同行。同行看完给了七条建议，五条是「这里可以加个快捷键」「那个动效可以更顺」，全都合理，但没有一条来自真实使用场景。换回目标用户之后，问题立刻变成了「我不知道导出之后文件存哪了」这种真问题。

测试的对象必须是会真的用这个产品的人。同行能评功能，不能替你走流程。

二、任务脚本：给目标，不给路径

任务脚本写得好不好，决定这场测试有没有用。判断标准只有一条：脚本描述目标，不描述操作。

反例是「点击左侧的模板分类，选择销售类，然后点右上角导出」。这是操作说明，不是任务。用户照着做，你测的是自己的说明书。

三个任务是上限，不是下限。一个人做测试，三任务 × 五人 = 15 次观察，已经足够多；任务加到五个，记录会变粗，反而看不出细节。

任务顺序也有讲究：把最重要的任务放第一个，因为第一个任务的干扰最少。不要一上来就测边缘功能，那会让用户建立错误的心理模型。

三个任务的覆盖结构建议是：一个主路径（用户最常做的事）、一个边界（失败、空数据、权限不足）、一个恢复（出错之后怎么回到正轨）。主路径看基本可用，边界看健壮性，恢复看用户能不能自己爬出来。

脚本里不要出现产品内部词汇。你叫「工作区」，用户可能理解成文件夹；你叫「发布」，用户可能理解成上传。测试时用用户的语言描述目标，才能测出他能否在你的界面里找到对应的词。

预演一次再正式约人。 自己照着脚本走一遍，或者找一个同事当零号用户。预演能抓出脚本里模糊的表述、缺失的起始状态、以及原型里根本没做的页面——这些在正式测试里出现，会浪费一个宝贵的名额。

三、不干预原则与四级问题

测试过程中最难守的纪律是不帮忙。用户点了五次都没点中，你的手会痒；用户走进一条明显更长的路，你会想提醒。但一提醒，你就测不出产品本身的问题。

只允许三种干预：

1. 用户完全卡死超过两分钟，且主动开口求助。
2. 用户在测试外的操作会改动真实数据。
3. 技术故障导致流程中断。

每次干预都要在记录里标一个「I」，并注明时间和原因。干预点高度集中，说明那里就是产品最该修的位置。

问题按四级记，不要按「用户体验好不好」记：

同一问题被三个人踩到，至少是 P1；只被一个人踩到、且能自行恢复，最多是 P3。级别由「影响完成」和「重复次数」两个维度决定，不由你的直觉决定。

不要问「你觉得这个功能好用吗」。 测试结束后可以问三句开放问题：哪一步最费劲、你当时想找什么、如果只能改一处你改哪里。前两句帮你验证记录，第三句帮你排序。

记录表至少四列，边测边填，不要靠事后回忆：

录屏是给回看用的，记录是给当场判断用的。只看录屏不写字，你会发现自己在反复拖进度条，却说不清问题出现在第几步。

不要在一场测试里改产品。 第一个用户卡住之后，不少人会立刻去改界面，再让第二个人测新版。这样五个人的数据不可比，也无法判断问题是否真的被修好。要改，等这一轮结束。

四、五个人够用的理由与成本账

「五个用户」不是随口说的数字。它的逻辑是：可用性问题在用户之间高度重复，第一个用户能暴露约三分之一的问题，前五个累计能暴露大部分高频问题。这是常被引用的经验规律，不是精确定理，但对单人产品足够用。

测试成本（教学假设）
  招募：5 人 × 80 元 = 400 元
  执行：5 人 × 45 分钟 = 3.75 小时
  整理：5 份记录 × 40 分钟 = 3.3 小时
  合计：约 7 小时 + 400 元
问题产出：通常 8–15 条，其中 P0/P1 约 3–6 条

七小时换三到六个必修问题，对上线前的产品是划算的。对比之下，上线后修一个 P0 的成本通常更高：要写公告、要处理支持工单、要重新发版。

五个人的构成也有要求：至少三个是目标用户，最多一个是同行或熟人。全是同行会得到一堆「专业建议」，全是熟人会得到一堆客气话。

测试原型和测试成品是两件事。 原型阶段测的是信息架构与流程，用户点不动是正常的，要提前说明「这是原型，有些按钮没反应」；成品阶段测的是真实操作，包括加载、错误提示与返回路径。两者不要混在一场里做。

远程测试的执行细节：让用户共享屏幕，你只开麦克风；提前说明你会保持沉默，不是不礼貌；全程录屏；结束时立刻写三条最重要的发现，趁记忆还新。

测试环境要接近真实。 用你自己的账号、造好的样例数据，不要用真实客户数据。屏幕分辨率调成用户常见的尺寸，别用 27 寸大屏测移动布局。网络条件也要考虑，加载慢的场景往往才是问题高发区。

别让测试变成访谈。 用户一边点一边讲想法，会干扰操作；全程只让他做事，做完再问。如果他不习惯沉默，可以让他「把心里想的说出来」，但要接受这会轻微改变行为，并在记录里注明。

五、行动清单与复算验收

• 写三个任务脚本，每个只描述目标与成功判据
• 招募五个人，至少三个是目标用户
• 约定不干预规则，并准备记录「I」标记
• 用四列记录：任务、路径、停顿、问题级别
• 每场结束立刻写三条发现，24 小时内补齐记录
• 按 P0–P3 汇总问题，标出被多人踩到的条目
• 决定本轮修哪些，其余写进待办并注明复查时间

验收标准：能说出 P0 与 P1 各有几条、分别被几个人踩到、修完的判据是什么。 只写「整体比较顺畅」的，不算做过可用性测试。

使用边界与实操验收

本文讲可用性测试的设计与记录，不涉及访谈提纲与观察方法，那属于第 03、04 篇；封测阶段的放行门槛属于第 51–60 天：十人封闭测试 ；原型阶段的测试思路可参考 SaaS 原型可用性测试：写代码前先看客户会不会走通流程 。

本文也不主张「测试越多越好」。上线前做一轮五人测试，比每周做一轮更有用；后者会让你忙于修小问题，反而推迟上线。测试的节奏应该跟着发布走：大改前一轮，小改靠记录。

验证以问题清单为准：如果一轮测试下来 P0 为零、P1 也只有一条，先怀疑任务太简单或用户太熟。把任务换成更真实、更长的一条，再测一轮。

关键参考与核验范围

本文的人数、时长与金额为教学演示。核验日期：2026-10-24。

• Nielsen Norman Group: Usability Testing 101 ：可用性测试的类型、任务设计与样本量的公开说明。
• GOV.UK Service Manual: User research ：可用性测试的执行规范与知情同意要求。

上述两条只用于说明测试方法的公开来源，不构成对任何工具或服务的推荐。「五个用户能发现大部分问题」是经验规律，具体比例随产品复杂度变化，本次核验未逐条比对原始研究。

系列导航

• 上一篇：观察：看操作，不听描述
• 下一篇：反馈分诊：抱怨、方案与情绪
• 回到目录：一个人把用户搞懂：访谈、观察、可用性测试与证据链
• 相关阅读：第 51–60 天：十人封闭测试 、观察：看操作，不听描述