研究报告

用户访谈报告怎么写：把结论、证据和下一步说清楚

从研究目标、参与者和方法写到关键结论、原始引文、反例、局限与建议，整理一份能支持决策、也经得起复核的用户访谈报告。

ScribeFlash 研究团队2026年10月23日约 11 分钟

先说结论

用户访谈报告不是把访谈摘要排在一起，也不是把几句有冲击力的原话贴进演示文稿。它要完成一件更具体的事：让没有参加研究的人看懂团队观察到了什么，这个判断由哪些材料支持，在哪些情况下不成立，以及接下来准备怎么验证或行动。

我更愿意把报告写成一份“带证据的决策记录”。开头用几段话交代研究为哪个决定服务；中间只放真正影响这个决定的结论，每条结论都能回到访谈原文；末尾说明建议、局限和下一步。过程资料可以留在附录，没必要把分析时产生的所有标签都塞给读者。

如果研究还没有形成可靠结论，先别急着让 AI 把文档写得很像报告。版式完整，不代表证据完整。

动笔前，确认报告要推动什么决定

同一批访谈材料，可以写出完全不同的报告。产品经理可能要决定是否调整首次使用流程；销售负责人更关心采购阻力；研究团队则可能需要判断下一轮该补访哪类参与者。读者不同，信息顺序也应该不同。

写报告前先回答四个问题：

谁会读，谁有权做决定？
他看完以后，需要选择、停止或继续什么？
哪几条研究问题和这次决定直接相关？
哪些发现虽然有意思，但不属于这份报告？

例如，“总结 8 场新用户访谈”只是工作描述。换成“帮助产品团队决定下季度先修改邀请流程，还是先补充权限说明”，报告就有了取舍标准。凡是不能影响这个决定、也不能解释风险的材料，可以放入研究库，不必抢占正文。

GOV.UK 的研究指南建议尽早向团队分享研究，让结果进入设计、优先级和路线图讨论。报告因此不必等到写成一本“大部头”才出现。研究周期较短时，一份能独立读懂的简报通常更有用。

一份够用的用户访谈报告，通常有这些内容

报告结构不必固定，但下面这套顺序比较稳：

摘要

用一页以内说明研究背景、最重要的两三条结论、当前建议和仍待确认的风险。摘要不是正文的目录。读者只看这一页，也应该知道团队为何做研究，以及哪些决定需要被讨论。

研究目标与问题

写明这轮研究想支持什么决定，以及访谈材料能回答哪些问题。不要事后把目标改成“验证我们原来的想法是对的”。

参与者和方法

说明访谈时间、场次、筛选条件、角色差异、访谈方式和分析方法。参与者不需要具名，但读者需要知道结论来自什么范围。若中途有未完成访谈、录音缺失或招募偏差，也在这里交代。

关键结论

正文的主体。每条结论包含简洁标题、解释、适用范围、支持证据和必要的反例。按决策重要性排序，不必按访谈提纲顺序写。

建议与待验证问题

把可以立刻执行的动作、需要设计探索的方向、仍需研究的问题分开。研究建议可以给方向，但别装作只有一种解决办法。

局限与附录

列出样本和方法边界，并保留研究计划、访谈提纲、术语说明或详细证据索引。正文保持可读，复核所需的信息也没有丢。

把研究结论写到证据允许的边界

最常见的问题不是结论写得太短，而是写得太大。

假设 6 位首次使用产品的运营人员中，有 4 位在邀请同事前停下来确认权限。报告可以写：

在本轮受访的运营人员中，邀请步骤触发了权限风险检查。几位参与者因此暂停设置，并向主管或 IT 同事确认。

不要顺手扩大成“用户都不信任我们的权限系统”，更不要写“邀请流程导致 67% 的新用户流失”。前者把局部材料推成普遍心理，后者把一个小型定性样本包装成了流失率。

一条比较扎实的结论通常回答四件事：发生了什么，发生在谁或什么情境中，为什么与当前决定有关，证据还不能说明什么。数字可以帮助读者了解本轮材料的分布，但不能替代范围说明。

Nielsen Norman Group 把原始数据、研究发现和洞察区分开：原话只是材料，发现是材料中的模式，洞察还要结合用户与业务背景解释机会。写报告时把这几层分清，能少掉很多“听起来正确、其实没有依据”的句子。

引文不是装饰，要能回到原始材料

一条精彩引文很容易主导会议。可它可能只代表一个人的特殊经历，也可能被截掉了前后文。报告中的引文应该用来帮助读者理解结论，不应该代替结论本身。

每条关键结论至少保留这些追溯信息：

来自哪位匿名参与者或哪场访谈；
对应的原始文字稿片段；
可以定位录音的时间位置；
引文是否经过校对；
它是支持证据、反例，还是研究员备注。

文字稿中写的是参与者说了什么，研究员备注可能包含观察和解释，两者不能混成一句“用户反馈”。NN/g 在评估 AI 研究工具时特别指出，没有具体会话、时间位置或来源链接的生成结论很难被复核；工具也必须区分研究者笔记与参与者原话。

引用时不要为了语句顺滑改写原意。删掉无关部分可以用省略标记，涉及姓名、公司、客户信息时先去标识。若一句话离开上下文后会产生不同理解，宁可多保留一两句，也别只截最有戏剧性的部分。

把反例留在报告里，它们经常比“多数人”更有用

研究者很容易被整齐的故事吸引：四个人卡在同一步，于是报告只剩“主要痛点”。但另外两个人为什么没有卡住，可能正好揭示问题出现的条件。

反例可以这样写进结论：

4 位参与者在邀请同事前确认权限；另外 2 位没有停顿。他们都在访谈前获得了管理员提供的权限清单。现有材料提示，阻力可能与信息缺失有关，而不只是交互步骤本身。

这不会削弱报告。恰恰相反，它让下一步更具体：先验证提前提供权限说明能否减少停顿，而不是立刻重做整个流程。

分析阶段还要主动寻找沉默的材料。没有被问到的人群、没能完成的访谈、与主流模式相反的场景，都可能改变结论边界。报告应该让读者看见这些缺口。

建议和研究结论分开写

“用户找不到权限说明”是发现；“把说明移到邀请按钮上方”是解决方案假设。两句话有关系，但不是一回事。

把它们分开写有两个好处。一是团队可以同意问题存在，却提出更好的解决办法。二是下一轮测试失败时，不会连带否定前面的研究结论。

建议可以分成三类：

现在就能做、风险较低的调整，例如修正文案错误；
需要设计和可用性测试的方案，例如改变信息出现的位置；
证据还不够，需要补充研究或数据分析的问题。

每条建议最好写明负责人、预期影响和验证方式。不要用“优化体验”“加强引导”这类无法验收的表达。比如：“设计两种权限说明方式，在下一轮 5 场任务测试中观察参与者是否能在不求助的情况下判断该邀请谁。”这才是可以推进的下一步。

局限和隐私边界，别缩成页脚小字

局限不是客套话。它告诉读者该在多大范围内使用报告。

可以交代参与者来源是否偏向活跃用户，是否缺少某个关键角色，研究是不是只依赖自述，翻译是否可能损失语气，以及这轮材料不能回答哪些规模或因果问题。如果结论只适用于某种版本、市场或时间段，也明确写出来。

报告还要重新检查隐私。GOV.UK 建议在分享研究材料时尽量使用无法识别参与者的摘录，移除姓名、联系方式和其他直接标识；不能充分匿名的内容，只分享给参与者事先知情且确有需要的人。公开视频、截图和录音片段尤其需要谨慎，一旦被下载转发，很难再完全收回。

匿名不只是把姓名改成“用户 A”。职位、公司规模、城市和一段罕见经历组合在一起，仍可能指向具体的人。对外发布前，让不了解参与者名单的同事看一遍，往往能发现研究者已经习以为常的身份线索。

在 ScribeFlash 中完成一份可复核报告

ScribeFlash 的报告流程从已确认的研究结论开始，而不是从空白文档开始。实际操作可以按下面走：

进入项目的分析页面，逐条打开建议结论。检查标题、正文、支持证据、反例和引用，再确认或拒绝。AI 生成的文字不是最终事实。
至少确认一条可靠结论后，进入报告页面并生成报告。没有已确认结论时可以生成用于编辑的草稿，但草稿不能导出。
阅读自动整理的研究目标、方法、参与者概览、关键结论、证据、局限、建议和附录。生成结果只是初稿，需要按本次读者和决定删改。
编辑章节标题与正文。可以新建或复制章节、调整顺序，并隐藏或删除不适合当前版本的部分。隐藏章节不会进入导出文件。
打开报告中的引用，检查关联的结论、参与者、访谈、原文和时间位置。若来源材料有变化，先解决失效引用。
运行质量检查，查看已确认结论、支持证据、反例以及有效和无效引用。没有解决关键引用错误前，不要把报告标记为就绪。
确认内容后标记为就绪，再导出 TXT、CSV、DOCX 或 PDF。导出任务完成后，从记录中下载对应文件。
如果之后修改了文字稿、证据或结论，创建新的报告版本并重新检查，不要把旧导出文件当成当前结果。

更细的界面说明可以查看研究报告创建与导出指南。如果上游结论还没审完，先读研究结论复核指南。

分享前，再用五分钟检查一遍

摘要有没有直接说明研究服务于哪个决定？
每条关键结论是否写清适用人群和情境，而不是把小样本扩成“所有用户”？
引文能否回到参与者、访谈、文字稿和时间位置？
报告有没有保留改变结论边界的反例？
建议是否与结论分开，并写成可以验证的下一步？
局限是否具体，隐私处理是否符合参与者知情和团队规则？
隐藏章节、旧版本和无效引用是否已从最终导出中排除？

报告发出去以后，最好安排一次讨论。让产品、设计、研发或业务负责人说明他们如何理解结论、准备采取什么动作、还有哪些地方不信。真正的研究交付不止是一个文件，而是团队基于同一份证据做出更清楚的决定。

参考资料

从已确认结论生成可编辑研究报告

检查支持证据、反例和引用，再把报告整理成适合团队使用的版本。

创建研究项目

查看样例报告选择研究模板

用户访谈报告用户研究报告研究结论访谈分析

ScribeFlash 博客