可用性测试报告怎么写：分清观察、解释与建议

问题报告先分清三种说法

“参与者找导出时打开了账单页”是观察；“他预期导出入口会在账户设置旁边”是需要核实的解释；“把导出按钮换个位置”是设计建议。把三者分开，团队才能判断问题依据是什么、还有什么未知、下一次测试要看什么。

下面的导出场景为假设案例，用来演示报告写法，不是 ScribeFlash 的真实测试，也不能证明某次改版会提高任务完成率。

1. 明确任务，并在外部录制测试

先约定任务目标、起始状态、产品版本、设备或辅助技术，以及怎样算完成。“准备一份能发给同事的报告”保留了操作路径；“点击导出”则把可能正要研究的入口直接告诉了参与者。

GOV.UK 的主持式可用性测试指南建议使用可信、不会泄露操作答案的任务。编写任务说明时可以采用这一原则，并记录主持人何时提供了帮助。

按研究安排取得相应录制许可并处理个人信息。使用自己的研究或会议工具录制，再通过访谈上传流程上传音频或视频文件。ScribeFlash 不负责录制测试屏幕，也不会自动观察鼠标轨迹。文字稿记录的是发言；没有说出来的界面动作，需要研究员观察，并以外部录像为来源。

2. 先写证据记录，再给问题命名

假设任务 T1 中，虚构参与者 U1 打开账单页，回到项目，并在 04:18 问：“我要发给别人，从哪里拿到文件？”随后主持人指向了导出按钮。

分别记录：

• **观察：**U1 打开账单页、返回、发问，并得到提示。页面操作注明来自观察记录或录像；引文注明来自文字稿。
• **解释：**导出入口的位置或名称可能不符合 U1 的预期。权限或陌生的项目状态也可能是原因。
• **建议：**测试更清楚的入口或标签。在检查其他解释之前，这仍是建议。

不要仅凭一句话推断用户沮丧、困惑或鼠标移动路径。拿不到外部录像时，注明哪些动作无法核实。研究分析指南对观察、结论和行动的区分，也适用于这里。

3. 为每个问题留下可复查的记录

交给设计或工程团队的材料，至少应包含：

1. **问题标题：**具体障碍，例如“U1 未经提示无法找到报告导出入口”。
2. **任务与环境：**T1、起始页面、原型或构建版本、设备及相关账户条件。
3. **观察顺序：**实际看到的步骤，包括主持人的介入。
4. **来源：**参与者编号、录像时间戳、准确发言，以及另行注明来源的观察备注。
5. **任务后果：**停止、得到帮助后完成，还是找到了替代办法。
6. **解释与替代解释：**什么可能导致该过程，还有什么未确认。
7. **后续验证：**负责人、待测改动或问题，以及重新判断所需的材料。

把说出的相关段落保存为证据，把观察背景放在研究员备注里。项目研究问题可以把不同片段连接到同一任务，不必把每一句话都单独写成结论。

4. 按任务影响排序，避免虚假的精确

先约定优先级标签的含义。没有替代办法的阻断、反复操作才能恢复的困难，以及短暂的用词犹豫，应区别讨论。还要看主持人的提示是否掩盖了失败、受阻任务是否关键，以及是否存在可用的绕行办法。

报告这轮测试实际观察到的情况。“U1 需要提示”比“用户都无法导出”准确。如果写发生次数，交代哪些参与者尝试了同样的任务，以及条件是否一致。小规模、定向招募的研究不能给出总体失败率。

也要保留成功个案。若虚构的 U2 立即找到了导出，比较起始页面、既往经验和可见权限，而不是把 U2 当作无关材料。差异可能正好说明障碍在什么条件下出现。

5. 写成能支持下一次测试的问题报告

开头说明待做的决策与测试任务，再交代障碍、来源、任务后果、替代解释和下一项验证。成功尝试与未解决的问题，也应进入报告。

以假设的导出问题为例，可以在保持任务说明中立的前提下，对比现有控件和更清楚的名称。事先约定观察什么：能否独立发现、是否求助、选择了哪条路径，以及导出的文件是否满足交接要求。未来要观察的结果，不能写成已经实现的改善。

在 ScribeFlash 中，对照证据审阅结论后再确认。报告生成器可把已确认结论整理为可编辑报告。人工仍需区分发言、观察备注与建议；报告写得再流畅，也不能补出没有记录的动作。

从模板开始，再看完整示例

在研究模板中选择可用性测试，用围绕任务的问题建立项目。示例项目与下载资料用明确标注的模拟资料展示证据到报告的结构。如需跨场次比较，可参考访谈分析流程。

分享前再检查一次

每个问题都应写清任务、来源、得到的帮助与可观察后果；每项解释有边界；每条建议注明仍待验证。删去引文中不必要的身份信息，让接收者能清楚分辨：发生了什么，你怎样理解，以及准备验证什么。