---
name: user-interview-synthesis
description: 把多份用户访谈记录或笔记综合成原子观察、带参与者人数的亲和主题、支撑引语、待完成的任务（Jobs to be Done）、与假设区分开的洞察，以及附置信度的建议。适用于有人分享客户访谈笔记、调研通话记录或探索性访谈，问用户说了什么，要主题、模式、洞察或调研报告时。
---

# 用户访谈综合分析

一份好的综合分析，要让读者看到有多少人说了某件事、他们的原话是什么，以及团队对此该有多大把握。统计的是参与者人数，不是提及次数。把用户做过的事和他们说自己会做的事分开，绝不让一场声音特别大的访谈变成一个主题。

## 适用场景

- 完成 3 场或更多用户访谈、探索性访谈或可用性测试之后。
- 团队问“我们学到了什么？”，或决策前需要一份调研报告时。
- 不适用于单场访谈：请用 call-summary-crm-notes 或 meeting-minutes。也不适用于大量的客服工单或问卷评论：请用 feedback-themes。

## 需要准备

- 访谈文字记录或笔记，每位参与者一份，带参与者标签（P1、P2 或化名）。
- 这些访谈要回答的调研问题。没有的话问一次；仍然没有，就自行推断并标注“[假设：调研问题]”。
- 可选：每位参与者的细分群体（角色、公司规模、套餐），以便按群体拆分主题。

## 步骤

1. **提取原子观察。** 一条观察 = 关于一位参与者的一个事实：他们做过、感受到、说过或用过的东西。每条都标上参与者，以及它是行为（“做了”）、观点（“说了”）还是诉求（“想要”）。过去的行为是最强的信号；诉求是最弱的。
2. **归纳成主题。** 按 NN/g 描述的亲和图方法做：先按内容分组，分完再命名，不强求固定的分组数量，一条观察同时符合两组时可以放进两组。把描述同一个深层需求或痛点的观察归到一起。每个主题用站在用户一方的陈述句命名（“店主每天用手机查看现金”），而不是一个话题（“移动端”）。
3. **统计每个主题的参与者人数。** 写成“8 人中 5 人”。这个技能的规则：一个主题至少需要 2 位参与者；只来自一位参与者的观察放在“值得关注”下。如果某个主题只来自一个细分群体，要说明。
4. **挑选引语。** 每个主题 1 到 2 句原话，注明参与者标签。引用原话；如果笔记是转述的，标注“（转述）”。
5. **写出待完成的任务（Jobs to be Done）。** 任务是一个人在特定情境下想取得的进展（克里斯坦森研究所）；数据显示出来时，涵盖功能、社交和情感三个方面。对排名靠前的主题，写成：“当 [情境] 时，我想要 [动机]，以便 [结果]。”每一条都基于观察到的行为，而不是功能诉求。
6. **区分洞察和假设。** 洞察要有 2 位或以上参与者的行为作支撑。团队在访谈前就相信、但数据没有检验过的内容，仍然是假设。相反的证据要公开列出。
7. **附上置信度给出建议。** 每条建议都关联到主题，用户指定了负责人的就写上，并按这个技能的既定标准标出置信度：高（一半或以上参与者的行为）、中（多位参与者，但多为“说了”而非“做了”）、低（参与者很少或只来自一个群体）。再写出什么样的调研能提高置信度。

## 输出格式

```markdown
# 访谈综合分析：[调研问题]

**参与者：** [n] 人（[细分群体]） · **日期：** [范围] · **访谈人：** [姓名]

## 主要发现
1. [主题陈述] — [n 人中 x 人]
2. [主题陈述] — [n 人中 x 人]
3. [主题陈述] — [n 人中 x 人]

## 主题
### [主题陈述] — [n 位参与者中 x 人]
- **证据：** [观察，标注做了/说了/想要，并附参与者标签]
- **引语：** “[引语]” — [P#]
- **细分群体：** [全部，或哪些]

## 待完成的任务
- 当 [情境] 时，我想要 [动机]，以便 [结果]。（[主题]）

## 洞察与假设
| 陈述 | 状态 | 证据 |
|---|---|---|
| [陈述] | 洞察 / 假设 / 被推翻 | [参与者和类型] |

## 建议
| 建议 | 依据 | 置信度 | 如何提高置信度 |
|---|---|---|---|
| [行动] | [主题] | 高 / 中 / 低 | [下一步调研] |

## 值得关注
- [只来自一位参与者的观察] — [P#]
```

## 示例

**输入（笔记摘要，4 场关于发票催款的访谈）：**

> P1（广告公司老板）：每周五对着电子表格催逾期发票。“我讨厌当坏人。”
> P2（自由职业者）：用手机发短信提醒，而不是发邮件。想要自动提醒。
> P3（广告公司老板）：由记账员负责催款。直到月底才知道谁逾期了。
> P4（自由职业者）：每次都复制粘贴同一封提醒邮件；“我每次都会把语气改软一点，免得听起来不礼貌。”

**输出：**

```markdown
# 访谈综合分析：小型服务企业如何催收逾期发票？

**参与者：** 4 人（2 位广告公司老板，2 位自由职业者） · **日期：** [日期] · **访谈人：** [姓名]

## 主要发现
1. 催款让人觉得尴尬 — 4 人中 2 人
2. 催款是手动、重复、成批处理的工作 — 4 人中 3 人

## 主题
### 催款让人觉得尴尬 — 4 人中 2 人
- **证据：** P1 做了：每周催款，说了：不喜欢当“坏人”。P4 做了：每次都重写语气。
- **引语：** “我讨厌当坏人。” — P1；“我每次都会把语气改软一点，免得听起来不礼貌。” — P4
- **细分群体：** 两类都有

### 催款是手动且重复的工作 — 4 人中 3 人
- **证据：** P1 做了：每周五用电子表格。P2 做了：用手机发短信。P4 做了：复制粘贴同一封邮件。
- **引语：** “我每次都会把语气改软一点” — P4
- **细分群体：** 两类都有

## 待完成的任务
- 当客户逾期付款时，我想要不用自己动笔就能用礼貌的语气发出提醒，以便收到款项又不伤害关系。（主题 1、2）

## 洞察与假设
| 陈述 | 状态 | 证据 |
|---|---|---|
| 催款是重复的手动工作 | 洞察 | P1、P2、P4（做了） |
| 用户想要自动提醒 | 假设 | 仅 P2（想要） |
| 邮件是合适的渠道 | 被推翻 | P2 用短信 |

## 建议
| 建议 | 依据 | 置信度 | 如何提高置信度 |
|---|---|---|---|
| 测试预先写好的礼貌提醒模板 | 主题 1、2 | 高 | 再做 4 场访谈；观察用户是否会修改模板 |
| 在继续开发邮件功能之前，先探索短信提醒 | 主题 2（P2 发短信） | 低 | 问 5 位自由职业者上一次用的是什么渠道 |

## 值得关注
- 直到月底才知道谁逾期了，看不到实时情况 — P3
```

## 发送前检查

- [ ] 每个主题都写明“n 位参与者中 x 人”，且至少有 2 位参与者。
- [ ] 每句引语都是原话并注明出处，或标注“（转述）”。
- [ ] 每条观察都标注了做了、说了或想要。
- [ ] 每条建议都写明了依据的主题和置信度。
- [ ] 没有任何文字记录或笔记之外的内容；没有编造的参与者或数字。
- [ ] 相反的证据都列出来了，没有丢掉。

## 常见错误

- 统计提及次数而不是人数。一位参与者说了 9 次“导出”，也只算 n 人中 1 人。
- 把功能诉求当成需求。问清楚对方提出诉求时想做成什么。
- 把主题写成话题（“定价”）。主题要说出一个可能被证伪的判断。