五用户法

在同一细分访谈 5 用户——够发现模式，少到保持快。

为什么

五用户法（自 Nielsen 研究）是甜点：同细分 5 次访谈可靠浮现 80-90% 可用性问题和复现痛点，而 20 次仅以 4 倍成本加边际信号。关键是"同细分"——5 单人 OSS 维护者浮现模式；5 随机开发者（学生、企业架构师、爱好者、创业 CTO、自由职业者）浮现噪声因问题不同。方法快（一周 5 访谈）、便宜（无调查工具、无大样本）、高信号（你得故事非评级）。它是想法阶段核心验证工具因为它产定量方法不能的定性信号：不只"这是问题吗"而是"为什么是问题及如何表现"。

何时使用

在访谈脚本后、MVP 之前。1 周 5 访谈。每个新细分重复。

如何做

1. 精确定义细分
   - "100+ star 每周发布的单人 OSS 维护者"——非"开发者"
   - 细分须窄到 5 人共享问题

2. 从细分招 5 用户
   - 哪：他们聚集的社区（r/opensource、GitHub 讨论、Discord）
   - 怎么：发帖求 30 分钟访谈，提供 $20 礼品卡
   - 雪球：问每个受访者 1-2 更多推荐

3. 用脚本做 5 访谈
   - 全 5 同脚本（可比性）
   - 各 30-45 分钟
   - 录音并记故事笔记

4. 每次访谈后记意外
   - 他们提了你没预期的痛吗？
   - 他们没提你预期的痛吗？（这也是信号）
   - 如果第 3-4 次访谈没新东西则早停（饱和）

5. 跨 5 综合
   - 列每个提到的痛；数 5 中几人提到
   - 3+/5 提到的痛是模式（高信心）
   - 1/5 提到的痛是轶事（记但不优先）
   - 写 3-5 句：浮现什么模式、什么意外

6. 决策下一步
   - 如果模式确认你假设 → 进预型
   - 如果模式矛盾你假设 → 修订或毙
   - 如果无模式（5 个全不同）→ 细分太宽；窄化重访

示例

细分：100+ star 每周发布的单人 OSS 维护者。

访谈（5，一周内）：
  1. React 库维护者，2k star——"我每周六审 PR，花 4 小时"
  2. CLI 工具维护者，800 star——"我让 PR 放数周因审查累"
  3. VS Code 扩展维护者，500 star——"我周末审，我伴侣烦"
  4. Python 库维护者，3k star——"我每周日早审 PR，3 小时"
  5. Rust crate 维护者，1.2k star——"我把审查批进周末块，5 小时"

模式（3+/5 提到）：
  - 全 5 周末审（模式：审查发生在个人时间）
  - 4/5 提时间成本（每次 2-5 小时）
  - 3/5 提疲惫/拖延

轶事（1 提到）：
  - "我伴侣烦"（1/5——真但不普遍）
  - "我让 PR 放数周"（1/5——不同工作流）

意外：
  - 预期："审查技术难"→ 未提；痛是时间和疲惫，非难
  - 预期："贡献者提交坏 PR"→ 2/5 提，非主痛

综合：痛是审查消耗周末时间（5/5）并致疲惫（3/5），非技术难。这重构方案：非"审得更好的 AI"而是"审得更快还周末的 AI"。

决策：以重构问题进预型。

常见问题

⚠访谈 5 个不同细分的人——学生、CTO、爱好者问题不同；你得噪声非模式。
⚠继续到 10 或 20 次访谈——5 后你听同模式；停并行动，别继续访谈拖延建。
⚠把 1/5 提当模式——一人的痛是轶事；模式要 3/5，否则你为一人建。
⚠不饱和停——如果第 4 次没新，停；第 5 次不太可能加信号且你拖延行动。

最佳实践

✓细分窄到 5 人共享问题——"100+ star 单人 OSS 维护者"非"开发者"；先测细分再测问题。
✓全 5 用同脚本——可比性是重点；不同脚本给你 5 轶事非 5 数据点。
✓记未提的——如果你预期一痛而 0/5 提，那是痛不真或不急的强信号。
✓饱和停（通常第 4-5 次）——一旦听同模式，行动；更多访谈拖延靠建学习。