Back to Details

analyzing-user-feedback

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Analyzing User Feedback

用户反馈分析

Scope

适用范围

Covers
  • Aggregating and normalizing feedback from multiple channels (support, sales, research, reviews, surveys, usage signals)
  • Turning raw feedback into themes with evidence and actionable recommendations
  • Identifying friction / reasons users won’t use the product (not just validation)
  • Producing a repeatable feedback loop (cadence, owners, and handoffs)
When to use
  • “Synthesize our user feedback into themes and actions.”
  • “Analyze support tickets / feature requests for the top issues.”
  • “Create a voice-of-customer report for <area> in the last <time window>.”
  • “Summarize churn reasons / cancellation feedback.”
  • “Cluster survey open-ends into insights and recommendations.”
When NOT to use
  • You need to collect new feedback first (use 
    conducting-user-interviews
    / 
    designing-surveys
    )
  • You need backlog prioritization as the primary output (use 
    prioritizing-roadmap
    )
  • You need a PRD/spec for a chosen solution (use 
    writing-prds
    / 
    writing-specs-designs
    )
  • You only need to respond to individual tickets (support workflow, not synthesis)
涵盖内容
  • 汇总并标准化来自多渠道的反馈（支持、销售、调研、评论、问卷、使用数据信号）
  • 将原始反馈转化为带佐证的主题和可落地的建议
  • 识别用户不愿使用产品的痛点/原因（而非仅验证已有假设）
  • 建立可重复的反馈闭环（周期、负责人及交接流程）
适用场景
  • “将我们的用户反馈汇总为主题和行动项。”
  • “分析支持工单/功能请求，找出核心问题。”
  • “针对<业务领域>过去<时间范围>的情况，生成客户声音报告。”
  • “总结用户流失原因/取消服务的反馈。”
  • “将开放式调研回复聚类为洞见和建议。”
不适用场景
  • 你需要先收集新的反馈（请使用
    conducting-user-interviews
    / 
    designing-surveys
    ）
  • 你需要将待办事项优先级作为主要输出（请使用
    prioritizing-roadmap
    ）
  • 你需要为选定的解决方案撰写PRD/规格文档（请使用
    writing-prds
    / 
    writing-specs-designs
    ）
  • 你仅需回复单个工单（属于支持工作流，而非汇总分析）

Inputs

输入要求

Minimum required
  • Product area / workflow to analyze (or “all product”)
  • Time window + volume expectations (e.g., “last 90 days”, “~2k tickets”)
  • Feedback sources available (tickets, interviews, sales notes, reviews, surveys, community, logs)
  • The decision this analysis should inform (roadmap theme, launch readiness, onboarding fixes, messaging, quality)
  • Any segmentation that matters (ICP, persona, plan tier, lifecycle stage)
  • Constraints: privacy/PII rules, internal-only vs shareable, deadline/time box
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md.
  • If data access is limited, proceed using a small representative sample and label confidence/limitations.
  • Do not request secrets. If feedback contains PII, ask for redacted excerpts or aggregated fields only.
最低要求输入
  • 待分析的产品领域/工作流（或“全产品”）
  • 时间范围及反馈量预期（例如：“过去90天”、“约2000张工单”）
  • 可用的反馈来源（工单、访谈记录、销售笔记、评论、问卷、社区内容、日志）
  • 本次分析需支撑的决策（路线图主题、发布准备情况、新手引导优化、消息推送、产品质量）
  • 任何重要的细分维度（核心目标客户、用户画像、套餐层级、生命周期阶段）
  • 约束条件：隐私/PII规则、内部专属 vs 可共享、截止时间/时间限制
信息缺失处理策略
  • 可从references/INTAKE.md中选取最多5个问题进行询问。
  • 如果数据访问受限，可使用小样本代表性数据推进分析，并标注可信度/局限性。
  • 不得索要机密信息。若反馈包含PII，请求提供脱敏片段或仅提供汇总字段。

Outputs (deliverables)

输出成果（交付物）

Produce a User Feedback Analysis Pack in Markdown (in-chat; or as files if requested):
  1. Context snapshot (scope, decision, time window, segments, constraints)
  2. Source inventory + sampling plan (what’s included/excluded; why)
  3. Taxonomy + codebook (tags, definitions, and coding rules)
  4. Normalized feedback table (tagged items; links/IDs if available; no PII)
  5. Themes & evidence report (top themes, representative quotes, frequency/severity, confidence)
  6. Recommendations (actions, owners/time horizon if known, expected impact, open research questions)
  7. Feedback loop plan (cadence, stakeholders, how engineering participates, how insights are stored)
  8. Risks / Open questions / Next steps (always included)
Templates: references/TEMPLATES.md
生成Markdown格式的用户反馈分析包（可在对话中直接发送；若有需求也可作为文件发送）：
  1. 上下文快照（范围、决策、时间范围、细分维度、约束条件）
  2. 来源清单及抽样方案（包含/排除的内容及原因）
  3. 分类体系及编码手册（标签、定义及编码规则）
  4. 标准化反馈表格（已标记的反馈项；若有则附带链接/ID；无PII内容）
  5. 主题及佐证报告（核心主题、代表性引用、频率/影响程度、可信度）
  6. 建议（行动项、已知的负责人/时间周期、预期影响、待调研问题）
  7. 反馈闭环计划（周期、相关利益方、工程师参与方式、洞见存储方式）
  8. 风险、待解决问题及后续步骤（必须包含）
模板参考：references/TEMPLATES.md

Workflow (8 steps)

工作流程（8个步骤）

1) Intake + decision framing

1) 需求收集与决策框架搭建

  • Inputs: User context; references/INTAKE.md.
  • Actions: Confirm the decision, scope, time window, audience, and constraints. Define what “good” looks like.
  • Outputs: Context snapshot.
  • Checks: A stakeholder can answer: “What decision will this analysis change?”
  • 输入： 用户提供的上下文；references/INTAKE.md。
  • 行动： 确认决策方向、范围、时间范围、受众及约束条件。定义“合格成果”的标准。
  • 输出： 上下文快照。
  • 检查项： 相关利益方可明确回答：“本次分析会影响哪项决策？”

2) Inventory sources + define the sampling plan

2) 梳理来源并制定抽样方案

  • Inputs: List of sources + access constraints.
  • Actions: Create a source inventory, decide inclusions/exclusions, and pick a sample strategy (random, stratified, top-volume buckets).
  • Outputs: Source inventory + sampling plan.
  • Checks: Sampling plan covers the highest-volume and highest-risk segments (or explicitly explains why not).
  • 输入： 反馈来源列表及访问约束。
  • 行动： 生成来源清单，确定包含/排除的内容，并选择抽样策略（随机抽样、分层抽样、高容量分组抽样）。
  • 输出： 来源清单及抽样方案。
  • 检查项： 抽样方案覆盖了高容量及高风险的细分群体（若未覆盖需明确说明原因）。

3) First-pass read-through (open coding)

3) 初次通读与开放式编码

  • Inputs: Sampled feedback items.
  • Actions: Read/annotate items manually to surface what’s “wrong” and why users struggle or churn. Write raw notes before building categories.
  • Outputs: Initial codes/notes + candidate themes list.
  • Checks: Notes capture rejection reasons and friction, not just feature ideas.
  • 输入： 抽样后的反馈项。
  • 行动： 手动阅读/标注反馈项，找出用户的痛点及流失原因。在建立分类前先记录原始笔记。
  • 输出： 初始编码/笔记及候选主题列表。
  • 检查项： 笔记记录了用户拒绝使用的原因和痛点，而非仅功能想法。

4) Build the taxonomy + codebook

4) 构建分类体系及编码手册

  • Inputs: Initial codes; product context.
  • Actions: Define a tagging schema (topic, lifecycle stage, severity, user segment, root cause, sentiment). Write clear tag definitions and rules.
  • Outputs: Taxonomy + codebook.
  • Checks: Two people could tag the same item similarly using the codebook.
  • 输入： 初始编码；产品上下文。
  • 行动： 定义标签体系（主题、生命周期阶段、影响程度、用户细分、根本原因、情感倾向）。撰写清晰的标签定义及编码规则。
  • 输出： 分类体系及编码手册。
  • 检查项： 不同人员使用该编码手册可对同一反馈项做出相似的标记。

5) Normalize and tag the feedback table

5) 标准化并标记反馈表格

  • Inputs: Raw items; taxonomy/codebook.
  • Actions: Create a normalized table, tag each item, and capture evidence fields (source, date, segment, verbatim excerpt, link/ID).
  • Outputs: Normalized feedback table (tagged).
  • Checks: No PII; every row has at least 1 primary theme tag + a severity/impact signal.
  • 输入： 原始反馈项；分类体系/编码手册。
  • 行动： 生成标准化表格，标记每个反馈项，并记录佐证字段（来源、日期、细分群体、原文摘录、链接/ID）。
  • 输出： 已标记的标准化反馈表格。
  • 检查项： 无PII内容；每一行至少包含1个核心主题标签及1个影响程度信号。

6) Synthesize themes + quantify carefully

6) 汇总主题并谨慎量化

  • Inputs: Tagged table.
  • Actions: Summarize top themes, quantify frequency by segment/source, identify severity and “why it happens”, and call out unknowns/bias.
  • Outputs: Themes & evidence report with confidence levels.
  • Checks: Each theme includes representative evidence (quotes/examples) and is not purely speculative.
  • 输入： 已标记的表格。
  • 行动： 总结核心主题，按细分群体/来源量化频率，识别影响程度及“问题产生原因”，并指出未知项/偏差。
  • 输出： 带可信度等级的主题及佐证报告。
  • 检查项： 每个主题都包含代表性佐证（引用/示例），而非纯推测。

7) Translate into actions + learning plan

7) 转化为行动项及学习计划

  • Inputs: Themes report; constraints.
  • Actions: Convert themes into actions (bugs, UX fixes, comms, product bets) and open questions (what to research next). Tie each action to evidence and expected impact.
  • Outputs: Recommendations + learning plan.
  • Checks: Recommendations are concrete enough to execute next sprint/quarter (clear owner/time horizon if known).
  • 输入： 主题报告；约束条件。
  • 行动： 将主题转化为行动项（ bug修复、UX优化、沟通策略、产品尝试）及待调研问题。将每个行动项与佐证及预期影响关联。
  • 输出： 建议及学习计划。
  • 检查项： 建议足够具体，可用于下一个迭代/季度的执行（若已知则明确负责人/时间周期）。

8) Share out + establish the feedback loop + quality gate

8) 分享成果 + 建立反馈闭环 + 质量校验

  • Inputs: Draft pack.
  • Actions: Propose the share-out format (doc + review). Define cadence, owners, and storage (where insights live). Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks/Open questions/Next steps.
  • Outputs: Final User Feedback Analysis Pack.
  • Checks: Pack is shareable as-is; limitations are explicit; follow-up actions are scheduled.
  • 输入： 分析包草稿。
  • 行动： 建议分享格式（文档+评审）。定义周期、负责人及存储方式（洞见的存放位置）。使用references/CHECKLISTS.md进行检查，并通过references/RUBRIC.md进行评分。添加风险、待解决问题及后续步骤。
  • 输出： 最终版用户反馈分析包。
  • 检查项： 分析包可直接共享；局限性已明确说明；后续行动项已安排。

Quality gate (required)

质量校验（必填）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md进行校验。
  • 必须包含：风险、待解决问题、后续步骤。

Examples

示例

Example 1 (support tickets): “Analyze the last 60 days of onboarding-related tickets. Output a User Feedback Analysis Pack and top 10 recommended fixes.”
Expected: source inventory + sampling, taxonomy, tagged table, themes with quotes, and ranked actions.
Example 2 (survey + reviews): “Synthesize survey open-ends and app store reviews for our new pricing change. What are the biggest friction points and why?”
Expected: themes split by source/segment, severity signals, and recommendations (incl. messaging/UX changes).
Boundary example: “Read all our feedback and tell us what to build next.”
Response: ask for scope/time window/decision + a sample dataset; otherwise produce a sampling plan + a minimal first-pass synthesis with explicit limitations.
示例1（支持工单）： “分析过去60天内与新手引导相关的工单。输出用户反馈分析包及排名前10的修复建议。”
预期输出：来源清单及抽样方案、分类体系、已标记表格、带引用的主题报告，以及排序后的行动项。
示例2（调研+评论）： “汇总关于新定价调整的开放式调研回复及应用商店评论。找出最大的痛点及原因。”
预期输出：按来源/细分群体划分的主题、影响程度信号，以及建议（包含沟通策略/UX优化）。
边界示例： “阅读所有反馈并告诉我们接下来要开发什么。”
回复：询问范围/时间范围/决策方向及样本数据集；若无法获取则生成抽样方案及带明确局限性的初步汇总分析。