user-research-synthesis

用户研究综合分析技能

此技能可帮助你分析用户研究数据，并按照结构化方法将其转化为可执行的洞察。

必需输入

基于已提供的信息开展工作。如果缺少以下任何一项，仍需生成完整输出：用合理的假设填补每处空缺，标注 (假设，需确认)，并在末尾列出这些假设。只有在核心主题本身缺失（无内容可写）时，才先提出问题。

• 研究数据（访谈记录、笔记、调查结果或摘要要点）
• 研究方法（访谈、调查、可用性测试等）
• 参与者人数及其资料（角色、背景）
• 研究旨在回答的问题

从 Brain 读取 / 写入 Brain

如果存在 professional-brain（brain/），请先使用，再提出问题：

• 先读取： 打开 hypotheses/（本次研究可验证或推翻哪些假设）和 context.md（用户是谁）。
• 完成后写入： 更新每个受影响假设的状态，将持久有效的洞察添加到 knowledge/users.md，并将原始笔记保存在 source/。将基于访谈得出的结论标记为 [interview]，绝不能将其伪装成 [data]。

综合分析框架

1. 数据收集概览

• 研究类型：访谈、调查、可用性测试等
• 参与者资料：人口统计特征、用户细分、样本量
• 研究问题：我们希望了解什么
• 方法：如何收集数据

2. 识别关键主题

按以下结构整理发现：

主题名称

• 描述：此主题所代表的内容
• 普遍程度：提及此主题的参与者人数（例如，“12 位参与者中有 8 位”）
• 支持性引述：2-3 条代表性引述
• 启示：这对我们的产品意味着什么

每项研究力求归纳出 4-8 个主要主题。

3. 痛点分析

针对每个已识别的痛点：

• 痛点：清晰描述
• 严重程度：高/中/低（基于影响和频率）
• 当前变通方案：用户目前如何应对
• 证据：研究中的具体示例

4. 功能请求

对请求进行分类：

• 必需功能：阻碍用户成功的关键需求
• 高价值：能显著改善体验
• 锦上添花：渐进式改进

针对每项请求：

• 请求：用户提出了什么
• 频率：出现的频次
• 用户引述：代表性示例
• 根本需求：用户为何需要此功能（深入探究表面请求背后的原因）

5. 用户工作流洞察

记录观察到的实际工作流：

• 当前状态：用户目前如何完成任务
• 痛点：他们在哪些环节遇到困难
• 理想状态：他们希望能够如何操作
• 机会：我们可以在哪些方面创造价值

6. 用户细分洞察

如果研究揭示了不同的用户群体：

• 细分名称：描述性标签
• 特征：该群体的定义特征
• 独特需求：他们的需求有何不同
• 规模/重要性：在优先级排序中的相对权重

7. 竞争洞察

如果用户提到了竞争产品或替代方案：

• 竞争产品/替代方案：他们使用的产品或方案
• 使用原因：它有哪些优势
• 不足：它有哪些缺点
• 转换障碍：他们为何不完全切换

8. 建议

基于洞察确定优先级的建议：

高优先级

• 有证据支持的建议
• 预期影响

中优先级

• 有证据支持的建议
• 预期影响

低优先级/未来考虑

• 有证据支持的建议
• 预期影响

9. 待解答问题

已发现的研究空白：

• 我们仍需了解什么
• 建议开展的后续研究
• 需要验证的不确定因素

分析指南

综合访谈时：

• 寻找多个参与者之间的模式
• 同时记录用户说了什么和做了什么
• 关注情绪反应
• 识别待完成的工作，而不只是功能需求

分析引述时：

• 使用逐字引述，并用“引号”括起来
• 标注引述来源：[参与者 ID、角色、背景]
• 选择能说明模式的引述，而非异常案例
• 同时纳入正面和负面反馈

识别主题时：

• 使用描述性名称，而非笼统标签
• 为每个主题提供证据
• 尽可能量化（“10 位用户中有 7 位……”）
• 将主题与业务目标联系起来

深入材料

此技能附带支持文件——在可用时请使用：

• references/theme-validity.md — 主题何时才真实？综合分析有效性规则。在生成输出时应用这些规则；其中包含了方法摘要所概括的校准标准和判断要点。
• templates/synthesis-report.md — 带有内嵌质量门槛的可填写交付文档。当用户想自行完成文档，而不是让系统生成时，请提供此模板。

评分标准（0–40）

交付前为此技能生成的任何输出评分；32 分及以上即可交付。

维度	0	5	10
证据规范	论断没有依据——没有参与者人数、没有引述，或引述未注明来源	大多数主题都已量化，但部分引述缺少来源标注，或普遍程度含糊（“许多用户”）	每个主题都注明基于数据的普遍程度（“12 人中有 8 人”），并包含 2–3 条已标注来源、能说明模式的引述
综合层次	将个别评论罗列一番，包装成研究发现	找到了跨参与者的主题，但有一两个只涉及单个参与者的轶事被提升为主题	找到 4–8 个跨参与者的真实模式；将异常案例标明；捕捉到言行差异，而不只记录表达的观点
决策关联	只有观察，没有影响——只是逐项展示数据	提到了影响，但内容笼统（“改进引导流程”），没有优先级或预期影响	每个主题都指出其影响的产品决策；建议根据证据、预期影响和工作量确定优先级
如实呈现矛盾和缺口	只呈现经过修饰的理想情况——看不到矛盾和不确定性	承认数据存在冲突，但未深入探究；解读与观察混淆	揭示矛盾发现并提出解决路径；明确区分观察与解读；为待解问题指定后续跟进事项

质量检查

• 主题应识别多个参与者之间的模式，而非个别回应
• 洞察应关联到具体产品决策，而非仅仅描述观察结果
• 每项论断都应包含支持证据（引述、数量或示例）
• 明确区分观察与解读
• 按影响确定发现的优先级，而非仅仅罗列

反模式

• 不要罗列每条个别评论——综合分析必须找出跨参与者的模式
• 不要在缺乏数据证据的情况下做出推断
• 在了解根本问题之前，不要关注功能需求——始终先识别待完成的工作
• 不要忽略矛盾数据——必须揭示并注明相互冲突的发现
• 不要在未量化普遍程度的情况下呈现结果——说明有多少参与者持有每种观点

主题示例

**Theme: Information Overload During Onboarding**

**Description**: Users consistently expressed feeling overwhelmed by the amount of information presented during initial setup, leading to incomplete onboarding and delayed time-to-value.

**Prevalence**: 9 out of 12 participants mentioned this issue unprompted

**Supporting Quotes**:
- "I just wanted to get started, but it felt like I needed to read a manual first" [P3, Marketing Manager]
- "By the third screen of instructions, I started clicking 'Next' without reading" [P7, Sales Rep]
- "I wish there was a 'quick start' option for people like me who just want to try it" [P11, Product Designer]

**Implication**: Our current onboarding flow prioritizes completeness over engagement. We should consider a progressive disclosure approach where users can start using the product quickly and learn advanced features contextually.

**Recommended Action**: 
- Design a "Quick Start" path that gets users to first value in <3 minutes
- Move advanced configuration to contextual help within the app
- Test with 5-10 new users before full rollout
- Expected impact: +20-30% activation rate improvement

模板输出结构

综合研究结果时，请使用以下结构：

# User Research Synthesis: [Research Topic]

## Research Overview
- **Date**: [Date range]
- **Methodology**: [Interview/Survey/Testing]
- **Participants**: [Number] [User types]
- **Research Questions**: 
  1. [Question 1]
  2. [Question 2]
  3. [Question 3]

## Executive Summary
[2-3 sentence overview of key findings and implications]

## Key Themes

### Theme 1: [Theme Name]
[Full theme documentation as shown in example above]

### Theme 2: [Theme Name]
[Full theme documentation]

[Continue with 4-8 themes]

## Pain Points Summary

| Pain Point | Severity | Frequency | Current Workaround |
|------------|----------|-----------|-------------------|
| [Pain 1] | High | 10/12 users | [How they cope] |
| [Pain 2] | Medium | 7/12 users | [How they cope] |

## Feature Requests

### Must-Have
1. **[Request]** - Mentioned by [X] participants
   - Quote: "[Representative quote]"
   - Underlying need: [Why they want this]

### High Value
[Similar structure]

### Nice-to-Have
[Similar structure]

## Recommendations

### High Priority (0-3 months)
1. **[Recommendation]**
   - Supporting evidence: [Data from research]
   - Expected impact: [What will improve]
   - Effort estimate: [Rough sizing]

### Medium Priority (3-6 months)
[Similar structure]

### Future Consideration (6+ months)
[Similar structure]

## Open Questions
1. [Question requiring more research]
2. [Uncertainty to validate]
3. [Follow-up study needed]

## Appendix
- Interview guide used
- Full participant demographics
- Raw notes/transcripts (link)

示例触发短语

• “综合这些访谈记录。”
• “分析我们的调查结果。”
• “从这些用户反馈中找出主题。”
• “总结这项用户研究。”