analyzing-user-feedback

分析用户反馈

范围

涵盖

• 汇总并规范来自多个渠道的反馈（支持、销售、研究、评价、调查、使用信号）
• 将原始反馈转化为有证据支撑的主题和可执行的建议
• 找出阻碍因素／用户不愿使用产品的原因（而不只是验证）
• 建立可重复的反馈闭环（节奏、负责人和交接）

适用场景

• “将我们的用户反馈综合整理为主题和行动。”
• “分析支持工单／功能请求，找出主要问题。”
• “为 创建一份涵盖过去 的客户之声报告。”
• “总结用户流失原因／取消反馈。”
• “将调查问卷的开放式回答归类为洞察和建议。”

不适用场景

• 你需要先收集新的反馈（使用 conducting-user-interviews / designing-surveys）
• 你需要将待办事项优先级排序作为主要输出（使用 prioritizing-roadmap）
• 你需要为已选方案编写 PRD／规格说明（使用 writing-prds / writing-specs-designs）
• 你只需要回复单个工单（这是支持工作流，而非综合分析）

输入

最低要求

• 要分析的产品领域／工作流（或“整个产品”）
• 时间范围 + 预期数据量（例如“过去 90 天”“约 2k 个工单”）
• 可用的反馈来源（工单、访谈、销售记录、评价、调查、社区、日志）
• 此分析需要支持的决策（路线图主题、发布就绪情况、入门体验改进、消息传达、质量）
• 重要的细分维度（ICP、角色、套餐层级、生命周期阶段）
• 约束：隐私／PII 规则、仅供内部使用还是可分享、截止日期／时间限制

信息缺失时的策略

• 从 references/INTAKE.md 中提出最多 5 个问题。
• 如果数据访问受限，使用具有代表性的小样本继续分析，并标明置信度／局限性。
• 不要索取机密信息。如果反馈中包含 PII，请索取已脱敏的摘录或仅包含汇总字段的数据。

输出（交付内容）

以 Markdown 格式生成一份用户反馈分析包（在聊天中提供；如有要求，也可提供文件）：

1. 背景概览（范围、决策、时间范围、细分维度、约束）
2. 来源清单 + 抽样计划（纳入／排除的内容及原因）
3. 分类体系 + 编码手册（标签、定义和编码规则）
4. 规范化反馈表（已标记的条目；如有，包含链接／ID；不含 PII）
5. 主题与证据报告（主要主题、代表性引述、频次／严重程度、置信度）
6. 建议（行动、负责人／时间范围〔如已知〕、预期影响、待研究问题）
7. 反馈闭环计划（节奏、相关方、工程团队如何参与、洞察如何存储）
8. 风险／待解决问题／后续步骤（始终包含）

模板：references/TEMPLATES.md

工作流（8 个步骤）

1) 收集信息 + 明确决策框架

• 输入： 用户背景；references/INTAKE.md。
• 操作： 确认决策、范围、时间范围、受众和约束。定义“良好”的标准。
• 输出： 背景概览。
• 检查： 相关方能够回答：“这项分析会改变什么决策？”

2) 清点来源 + 制定抽样计划

• 输入： 来源列表 + 访问限制。
• 操作： 建立来源清单，决定纳入／排除的内容，并选择抽样策略（随机、分层、按数据量划分）。
• 输出： 来源清单 + 抽样计划。
• 检查： 抽样计划覆盖数据量最大和风险最高的细分群体（或明确说明未覆盖的原因）。

3) 初步阅读（开放式编码）

• 输入： 抽样后的反馈条目。
• 操作： 手动阅读／批注条目，找出问题所在，以及用户遇到困难或流失的原因。先记录原始笔记，再建立类别。
• 输出： 初始代码／笔记 + 候选主题列表。
• 检查： 笔记记录了拒绝原因和阻碍因素，而不只是功能构想。

4) 构建分类体系 + 代码手册

• 输入： 初始代码；产品背景。
• 操作： 定义标记方案（主题、生命周期阶段、严重程度、用户细分、根本原因、情感倾向）。编写清晰的标签定义和规则。
• 输出： 分类体系 + 代码手册。
• 检查： 两个人使用代码手册为同一条目打标签时，结果应当相近。

5) 规范化反馈表并添加标签

• 输入： 原始条目；分类体系/代码手册。
• 操作： 创建规范化表格，为每个条目添加标签，并记录证据字段（来源、日期、细分群体、原文摘录、链接/ID）。
• 输出： 规范化反馈表（已添加标签）。
• 检查： 不包含个人身份信息（PII）；每一行至少有 1 个主要主题标签，以及严重程度/影响信号。

6) 综合主题并谨慎量化

• 输入： 已添加标签的表格。
• 操作： 总结主要主题，按细分群体/来源量化频率，识别严重程度和“问题为何发生”，并指出未知因素/偏差。
• 输出： 附带置信度的主题与证据报告。
• 检查： 每个主题都包含有代表性的证据（引述/示例），而非纯粹推测。

7) 转化为行动 + 学习计划

• 输入： 主题报告；约束条件。
• 操作： 将主题转化为行动（错误修复、UX 改进、沟通、产品方向决策）和待解问题（下一步要研究什么）。将每项行动与证据及预期影响关联起来。
• 输出： 建议 + 学习计划。
• 检查： 建议具体到可以在下一个冲刺/季度执行（如已知，明确负责人/时间范围）。

8) 分享成果 + 建立反馈闭环 + 质量关卡

• 输入： 草稿包。
• 操作： 提出成果分享形式（文档 + 评审）。明确节奏、负责人和存储位置（洞察存放在哪里）。运行 references/CHECKLISTS.md，并使用 references/RUBRIC.md评分。添加 Risks/Open questions/Next steps。
• 输出： 最终版用户反馈分析包。
• 检查： 分析包可直接分享；明确说明局限性；已安排后续行动。

质量关卡（必需）

• 使用 references/CHECKLISTS.md 和 references/RUBRIC.md。
• 始终包含：Risks、Open questions、Next steps。

示例

示例 1（支持工单）：“分析过去 60 天与入门流程相关的工单。输出用户反馈分析包和排名前 10 的修复建议。”
预期：来源清单 + 抽样、分类体系、已添加标签的表格、附带引述的主题，以及按优先级排序的行动。

示例 2（调查 + 评价）：“综合分析关于我们最新定价调整的调查开放式回答和应用商店评价。最大的阻碍是什么？为什么？”
预期：按来源/细分群体划分的主题、严重程度信号，以及建议（包括沟通/UX 调整）。

边界示例：“阅读我们所有的反馈，并告诉我们接下来该开发什么。”
回应：询问范围/时间范围/决策，并索要一份样本数据集；否则，提供抽样计划 + 明确说明局限性的最简初步综合分析。