可用性测试分析做完了，设计师花了三天写了一份测试报告：18 条可用性问题，每条都配了截图、问题描述和根因分析。然后她报告发给产品经理，邮件标题写的是"上周可用性测试发现，请查阅"。产品经理回了两个字："收到。" 但两个月后，18 条问题一条都没改。
要知道这并不是产品经理不重视可用性测试，而是他压根不知道该从哪条问题开始。报告里的 18 条问题，没有标注哪些最紧急，没有说先改哪个，也没有提到改一个大概要投入多少开发资源。他读完报告知道"产品有18 个可用性问题"，但下一步该做什么，报告并没有告诉他。
所以，即便报告写得再完整，如果不能帮读者做出"先改哪个"的决定，就推不动不了任何改动。
一. 报告要服务于受众
报告的目的不是展示测试做了多少工作，而是能让特定的受众采取特定的行动。不同受众关注的问题不同，写报告之前需要先想清楚谁会读它、读完之后需要做什么。
- 设计团队需要知道：具体是哪里出了问题，根因是什么，有什么设计建议可以直接执行。设计师关心的是改什么、怎么改。
- 产品经理需要知道：哪些问题影响了产品的核心业务目标，优先级怎么排，改动大概需要多大的资源投入。产品经理关心的是先改哪几个、为什么先改这几个。
- 高层或利益相关方需要知道：测试的总体结论是什么，最重要的几个发现是哪些，对产品有什么影响。高层通常没有时间读细节，需要的是一页纸就能看完的摘要。
当然，实际情况是不需要写 3 份完全不同的报告。一份完整报告搭配一份管理层摘要就够了：完整报告包含所有细节，面向设计和产品团队；管理层摘要只有一页，写最重要的三到五条发现和对应的建议，不含细节，供需要快速了解结论的人使用。
二. 报告的基本结构
1. 测试背景
报告的开头，用半页以内的篇幅交代这次测试的来龙去脉：测试了什么产品、招募了几个什么样的用户、测了哪些任务、目的是回答什么问题。
这部分面向的是没有参与过测试的读者。读者在看到发现之前，需要先知道这些结论是怎么来的——用了几个用户、测的是什么阶段的产品、测了哪些核心流程。没有背景信息，读者无法判断结论的可信度，也无法判断结论是否和自己关心的问题相关。
2. 关键发现
关键发现是报告的核心，通常占最大篇幅。按严重程度排序：严重问题排在最前面，确保读者第一眼看到的是最需要处理的问题。
每条发现用统一的结构来写：
- 问题描述（一到两句）：说清楚这是什么问题，发生在产品的哪个环节。
- 证据：支持这条发现的数据——几个用户遇到了这个问题，用户的操作行为是什么，有没有可以直接引用的用户原话，截图或视频片段的位置。
- 根因：这个问题为什么会发生，指向哪个具体的设计决定。
- 出现频率：五个用户里有几个出现了这个问题。
