只找 5 位用户的可用性测试怎么做才有效：从任务设计到问题定级

很多团队做可用性测试时，第一反应是担心“只有 5 个人，结论会不会不可信”。如果目标是证明某个问题影响了多少用户，5 个人确实不够；但如果目标是发现任务流程中的阻碍、判断问题是否值得优先修复，小规模测试反而更容易快速形成决策。关键不在于把人数做大，而在于让每位参与者都面对真实任务，并把观察结果转化成可排期的问题清单。

先明确：5 位用户能回答什么问题

5 位用户适合回答的是“用户能不能完成任务”“卡在哪里”“为什么会卡住”“哪些问题会阻断目标”，而不是“有多少比例的用户会遇到这个问题”。前者属于发现问题和改进方向，后者需要更大规模、更加标准化的研究设计。

因此，测试开始前要先写清楚决策目标。例如，不要把目标写成“验证新版本体验是否良好”，而应改成“判断新用户能否独立完成首次配置，并找出导致中途放弃的步骤”。目标越具体，任务脚本和观察重点就越容易收敛。

小样本测试还有一个前提：参与者不能完全偏离目标用户。与其招募 5 个身份差异很大的人，不如围绕一个明确用户群体招募。若产品同时服务新手和熟练用户，也不要把两类人混在同一轮测试中再强行得出统一结论，可以先选择当前最关键的一类用户，后续再补充其他人群。

把产品目标拆成 3—5 个真实任务

任务不是功能清单，也不是让用户逐项点击按钮。好的任务应该还原用户为什么来到产品、手上有什么信息、希望完成什么结果。

从目标结果而不是界面入口开始

可以先用一句话描述产品希望用户完成的结果，再补充必要背景。例如：

你刚加入一个项目团队，需要找到最近一次项目资料，并确认自己是否已经获得编辑权限。

这个任务比“请点击项目列表，再打开权限设置”更适合测试。它给出了动机和目标，却没有提前告诉用户路径。用户选择的入口、对页面信息的理解、对“编辑权限”的判断，才是可用性测试真正要观察的内容。

每个任务脚本通常包含四部分：

• 场景背景：用户为什么现在要做这件事。
• 起始状态：用户从哪个页面、什么账号状态或已有信息开始。
• 目标结果：完成后应该得到什么，而不是必须点击哪些控件。
• 结束标准：什么情况下算完成，什么情况下算失败或需要帮助。

脚本应尽量接近真实使用情境，避免出现“请测试一下某个功能”这类没有上下文的要求。用户在真实环境中很少因为想体验功能而操作，他们通常是为了完成工作、解决问题或确认某个结果。

让 3—5 个任务覆盖一条完整路径

任务数量不宜按页面数量计算，而应按关键目标和风险节点计算。一个新功能可以拆成“找到入口”“完成核心操作”“确认结果”“处理异常”几个阶段，但不必每一步都单独变成任务。

例如，测试一个面向团队协作的资料提交流程，可以设计为：

1. 用户找到适合提交资料的位置，并判断应该选择哪种提交方式。
2. 用户提交一份资料，同时补充必要信息。
3. 用户检查提交结果，确认其他成员是否能看到。
4. 用户发现资料信息有误，尝试修改或撤回。
5. 用户遇到权限限制时，判断下一步应该怎么处理。

这组任务覆盖了发现、操作、确认和异常处理，比单纯要求用户“把资料上传成功”更容易暴露问题。若时间有限，应优先保留会影响核心目标的任务，删去只验证边角功能的部分。

任务顺序也有讲究。通常先安排较接近真实使用的主流程，让用户在没有太多疲劳的情况下完成核心目标，再安排修改、撤回或权限异常等压力更高的任务。不要在任务开头就介绍产品结构，否则会提前替用户完成了理解过程。

招募筛选：不只看身份，还要看使用场景

招募时，岗位名称往往不够用。两个都叫“项目经理”的人，可能一个每天使用协作产品，另一个几乎不接触相关流程。筛选问题应围绕实际行为展开，例如：

• 最近是否做过与目标任务相似的工作。
• 通常如何完成这件事，使用过哪些替代方式。
• 使用频率大致如何，最近一次是什么时候。
• 是否参与过该产品的设计或内部评审。
• 是否属于本轮想重点观察的用户类型。

筛选问题最好询问过去真实发生过的行为，而不是让对方自我评价“是否熟悉”。“你是否熟悉权限配置”容易得到模糊回答；“你最近一次给同事开通资料访问权限时是怎么做的”则更接近可验证的经验。

同时，要避免招募过度熟悉产品的人作为唯一参与者。内部同事、参与过方案讨论的人，往往会沿着设计者预设的路径操作，不能代表首次接触或普通用户。若确实只能找到熟悉用户，应在记录中标记这一限制，不要把结果直接推广到所有用户。

测试时：观察行为，不要急着教学

主持人的主要任务不是让用户成功，而是了解用户如何理解任务。用户停顿、反复查看、返回上一页、点击错误入口、询问“这里是什么意思”，都可能是重要证据。即使用户最后完成了任务，也不能据此认定流程没有问题。

测试开场可以告诉用户：这次是在测试产品，不是在考察他本人；遇到困难时可以说出想法，但不必为了迎合主持人而努力完成。这样能减少用户把失败归因于自己，也更愿意表达真实判断。

观察记录应区分事实和推断。比如：

• 事实：用户在权限页面停留较久，先后打开了两个下拉选项，然后问“编辑和查看有什么区别”。
• 推断：权限名称或说明可能不足以支持用户做选择。
• 待验证问题：其他用户是否也会混淆这两种权限。

不要只记“用户觉得不好用”这种结论性描述。它无法帮助团队定位问题，也很难指导修改。更有用的记录包括用户说了什么、做了什么、在哪一步停顿、是否需要提示、是否改变了原计划，以及最终有没有完成目标。

条件允许时，一位主持人负责沟通，另一位观察者负责记录。观察者不应在用户操作过程中频繁发表意见，否则用户会把观察者的反应当作提示。只有当用户长时间停滞、测试约定规定可以介入，或者继续操作已经无法产生有效信息时，才需要结束该任务或给予有限帮助。

追问要帮助解释行为，而不是引导答案

用户完成一个操作后，可以围绕刚才的行为追问：

• “刚才你为什么先选择这里？”
• “你当时以为下一步会发生什么？”
• “这个词在你的理解里是什么意思？”
• “如果没有主持人在旁边，你接下来会怎么做？”
• “你在什么时候开始不确定？”

这类问题能帮助团队理解用户的心理模型。相反，“你是不是觉得这个按钮不明显”“如果把它放到这里会不会更好”容易把答案带向主持人预设的方向。

追问也不宜在每个停顿后立即打断。用户有时只是需要短暂思考，过早介入会掩盖真实的摸索过程。可以先观察一小段时间，确认用户是在继续探索还是已经陷入无法推进的状态，再决定是否询问。

不要把“测边讲”误当成帮助用户

常见误区是看到用户卡住，就解释功能、指出入口，甚至直接告诉对方下一步怎么做。这样做看似提高了任务完成率，实际上把产品问题变成了主持人的教学问题。

更稳妥的做法是分阶段处理：

1. 先等待并记录：用户是否能自行发现方向。
2. 再询问理解：例如“你现在觉得这一步应该完成什么？”。
3. 最后才给予有限提示：如果测试设计允许，可以只说明任务目标，不指出具体控件。

如果用户在提示后完成了任务，要明确记录“在提示后完成”，不能和独立完成混为一谈。提示本身也是结果的一部分：它说明当前界面可能无法让用户独立理解下一步。

测试前可以讲解操作规则，例如如何返回、哪些数据是模拟的、遇到系统异常如何处理，但不要提前讲产品结构、功能位置和推荐路径。否则测到的就不再是产品的可用性，而是用户能否复述主持人刚才的说明。

从观察记录到问题清单

测试结束后，不要只按参与者逐人写流水账。更有效的整理方式是把相似现象合并成问题。例如，三位用户分别在不同步骤中询问“是否保存成功”，表面上是三个事件，背后可能是同一个反馈不清晰的问题。

每条问题至少应包含以下信息：

• 问题描述：用户在什么任务、什么步骤遇到了什么障碍。
• 证据：具体行为、原话或任务结果。
• 影响范围：只影响某个边缘场景，还是会影响大多数完成核心任务的用户。
• 阻断程度：用户能否继续，是否必须依赖他人或主持人。
• 建议方向：需要进一步修改、补充验证，还是暂不处理。
• 关联任务：这个问题对应哪个业务目标。

问题描述应尽量避免直接把解决方案写死。“增加一个按钮”通常不是问题描述；“用户找不到提交后的状态，也无法确认资料是否已被其他成员看到”才是问题。前者限制了讨论，后者保留了设计空间。

按影响范围与阻断程度定级排期

不要只按“出现了几次”排序。一个只出现一次、但会让所有新用户无法完成关键任务的问题，优先级可能高于一个出现三次、但用户很容易绕开的文字表达问题。

可以用两个维度做初步判断：

按照这两个维度，问题可以形成四类：

• 广泛影响且强阻断：优先处理。它会让较多核心用户无法完成关键目标，通常应进入当前迭代或尽快安排专项修复。
• 影响较窄但强阻断：需要确认业务价值和用户群规模。虽然不是所有人都会遇到，但对目标人群可能是完全不可用的问题。
• 广泛影响但弱阻断：适合纳入近期体验优化。用户大多能完成任务，但会产生犹豫、误解或额外操作。
• 影响较窄且弱阻断：可以记录并观察，不必为了清空问题清单而立刻投入开发。

还可以补充一个判断：问题是否涉及核心业务风险。比如一个视觉层面的轻微困惑，和可能导致错误提交、错误权限设置的问题，不能因为两者都被两位用户提到就放在同一级。

排期时不要直接把所有问题分成“严重”和“不严重”就结束。可以在问题清单中增加“下一步动作”：立即修复、设计方案后复测、补充特定用户验证、进入后续优化池或暂不处理。这样研究结果才能接上产品和研发流程，而不是停留在研究报告里。

小样本测试的可信度来自过程，而不是人数

“只有 5 个人，所以结论不可信”把两种研究目的混在了一起。小规模测试不能说明问题在全部用户中的发生比例，却可以帮助团队发现高风险路径、识别理解偏差，并决定下一步应该改什么或继续验证什么。

为了让结果更可靠，需要把限制说清楚：本轮测试覆盖了哪类用户、完成了哪些任务、哪些问题被多人独立表现出来、哪些判断仍然只是单个案例。对单个用户出现的问题，不必直接宣布它普遍存在，但也不能因为只出现一次就忽略，尤其是它涉及核心流程或强阻断时。

一轮有效的 5 人测试，通常应当留下三类产物：经过筛选的参与者信息、带有行为证据的观察记录，以及按影响范围和阻断程度整理的问题清单。团队不需要等到拥有完整研究资源才开始行动。先围绕最重要的业务目标设计少量真实任务，保持主持人中立，再把发现的问题转译成明确的排期判断，小规模测试就能成为一种低成本、可重复的产品决策工具。