让用户看着页面说“挺好的”，不是可用性测试。测试要观察的是：在尽量接近真实的任务里，用户能否找到入口、理解信息、完成动作，并在出错后自己恢复。
让用户看着页面说“挺好的”，不是可用性测试。测试要观察的是：在尽量接近真实的任务里，用户能否找到入口、理解信息、完成动作，并在出错后自己恢复。
01 先决定要观察什么行为
可用性测试最怕一个宽泛目标：“看看新版好不好用。”这样的目标会让主持人什么都问，最后只能得到“按钮可以大一点”“颜色还不错”之类的意见。
把目标改成可观察的行为，测试就会清晰很多：
- 用户能否在不被提示的情况下找到创建入口；
- 用户是否能根据现有信息选择正确方案；
- 用户能否理解错误原因并完成修正；
- 用户完成任务需要经过多少次返回、试错或求助；
- 不同角色是否会对同一术语产生不同理解。
测试前先写一张“风险清单”。哪些地方一旦设计错了，会导致提交失败、误操作、业务损失或开发返工？任务应优先覆盖这些风险，而不是平均浏览每个页面。
02 准备阶段：一场测试至少要有五样东西
测试目标与成功信号
每个任务都要定义“完成”“部分完成”“失败”分别是什么。成功信号可以包含完成结果、是否独立完成、关键错误、耗时和信心，但不要为了做数据看板而强行把一切量化。
参与者条件
招募实际用户或很可能使用该产品的人。角色、熟练度、使用频率和场景往往比人数更重要。针对单一流程的迭代测试，可以先进行一轮小样本研究，再根据问题是否重复出现决定是否补充。
可测试的原型或产品
不一定要高保真。测试信息架构时，线框或可点击流程已经足够；测试视觉层级、信任感或关键反馈时，才需要更接近最终界面。原型中哪些功能是假的，要提前告诉观察团队，但不要在任务中直接提醒用户。
主持脚本
脚本用于保持场次一致，不是让主持人机械念稿。它至少应包含开场、知情同意、热身问题、任务、追问、结束问题和感谢。
观察记录表
建议按“时间—用户行为—用户原话—观察者判断—待确认问题”分列。事实和解释分开写，后续分析时会少很多争论。
03 好任务不是操作指令，而是一个情境
下面两种写法看似相近，测试价值完全不同。
| 差的任务 | 更好的任务 |
|---|---|
| 点击右上角“新建”按钮，创建一个项目 | 你刚接到一个新客户，需要建立项目并邀请同事共同跟进，请在系统中完成准备 |
| 在筛选器里选择“待审核” | 主管让你找出本周仍未完成审核的申请，并处理其中一条 |
| 修改地址后点击保存 | 你发现订单收货地址写错了，请在发货前完成修改 |
好的任务要清楚、相关、有挑战，但不能包含界面上的具体词语或操作路径。任务还应使用参与者理解的业务语言，而不是产品团队的模块名称。
04 主持时，少解释，多追踪
主持人的工作不是教用户完成，而是让思考过程可见。开场时可以说明“我们测试的是产品，不是你”，并邀请参与者边操作边说出正在寻找什么、为什么犹豫。
当用户停住时，优先使用中性追问：
- “你现在在找什么？”
- “这里让你想到什么？”
- “如果我不在旁边，你接下来会怎么做？”
- “你预期点击以后会发生什么？”
不要问“这个按钮是不是不明显”“你觉得放左边会不会更好”。这类问题已经把答案塞进了用户嘴里。
一段可直接使用的主持开场
05 观察什么：别只记“完成/没完成”
一次任务至少可以记录六类证据：
| 证据 | 例子 |
|---|---|
| 路径 | 从哪里进入，绕过哪些页面，是否回退 |
| 理解 | 如何解释标签、状态、费用、权限 |
| 行为 | 点击、搜索、对比、反复查看、跳过 |
| 错误 | 误选、漏填、重复提交、无效尝试 |
| 恢复 | 是否发现错误，是否知道如何修正 |
| 情绪信号 | 犹豫、确认、担忧、意外，但不替用户下心理结论 |
观察者不要在会议里实时讨论设计方案。可以把问题和灵感分开记录，避免某个强势观点影响后续观察。
06 问题分级：影响、频率和恢复成本一起看
单靠“出现了几次”会低估低频但高风险的问题。界达设计在项目中更倾向把严重度拆成四个判断：
1. 任务影响：是否阻断核心任务，还是只增加一步操作；
2. 出现范围：是个别用户、某类角色，还是普遍问题；
3. 恢复难度：用户能否自行发现并修正；
4. 业务风险：是否可能造成误批、错款、隐私泄露或不可逆操作。
| 等级 | 典型表现 | 建议处理 |
|---|---|---|
| P0 阻断 | 核心任务无法完成，或存在严重安全/业务风险 | 暂停上线，先修复并复测 |
| P1 严重 | 多数目标用户失败，或错误后很难恢复 | 进入当前版本必须修复项 |
| P2 明显 | 可以完成，但理解成本高、效率差或依赖帮助 | 排入近期迭代，验证方案 |
| P3 轻微 | 不影响结果，主要是局部表达或一致性问题 | 与其他优化合并处理 |
这是一种项目管理方法，不是通用行业标准。团队可以调整等级，但必须保持判定规则一致，并保留证据。
07 测完当天就做快速合并
不要等所有场次结束后一周才开始看记录。每场结束后用15分钟回答三件事：
- 今天出现了什么新问题；
- 哪些问题重复出现；
- 下一场需要验证什么，而不是立刻改什么。
全部场次结束后，将相似证据聚类，再写成“问题—证据—影响—原因假设—建议—验证方式”。原因要标明是推断还是已经验证，避免把设计团队的解释当成用户事实。
08 一个典型场景：数据导入流程
团队准备测试一套Excel导入功能。最初任务只写了“上传文件并完成导入”，结果用户顺利点击了按钮，团队以为流程没有问题。
重新设计任务后，参与者需要下载模板、填写两条含错误的数据、上传、理解校验结果，并修复失败行。新的测试暴露出三个真正问题：用户分不清“文件上传成功”和“数据导入成功”；错误信息没有定位到具体单元格；修复后必须整份重新上传。
这说明任务覆盖的不是页面，而是完整工作闭环。否则测试只会证明按钮能被点击。
09 复测比“已修改”更重要
修复方案通过设计评审，不代表问题已经消失。P0和P1问题应尽量复测，尤其是团队改变了流程、术语或信息结构时。复测可以缩小范围，只招募相关角色，但任务应保持可比，并记录是否出现了新问题。
常见问题
一轮可用性测试需要多少人？
没有一个适用于所有项目的固定数字。范围单一、角色一致的迭代测试可以先做小轮次；角色、设备或业务场景差异较大时，要按关键人群分组。是否继续招募，取决于关键问题是否仍在增加，以及重要用户群是否被覆盖。
测试时可以回答用户问题吗？
先判断测试目标。若要验证产品能否独立支持用户，主持人应尽量延迟帮助，并记录求助点；若测试的是培训后的业务操作，可以按照真实场景提供约定范围的支持。无论哪种方式，都要保持各场次一致。
远程测试和线下测试怎么选？
远程测试适合分散用户、数字产品和快速迭代；线下更容易观察设备、纸面材料、多人协作与工作环境。选择取决于真实使用情境，不是哪个工具更方便。
测完后一定要写长报告吗？
不一定。迭代项目更需要清晰的问题清单、证据片段和决策记录。长报告适合跨团队沉淀，但不能代替一次让产品、设计和研发共同看到证据的复盘会议。
10 让研究和设计真正进入产品决策
链接复制成功
