# User Research Synthesis Skill

This skill helps analyze user research data and transform it into actionable insights following a structured methodology.

## Required Inputs

Ask the user for these if not provided:
- **Research data** (transcripts, notes, survey results, or summary bullets)
- **Research method** (interviews, surveys, usability tests, etc.)
- **Number of participants** and their profiles (role, context)
- **Research questions** the study aimed to answer

## Reads from / Writes to the Brain

If a [`professional-brain`](../professional-brain/SKILL.md) (`brain/`) exists, use it before asking:

- **Read first:** open `hypotheses/` (which assumptions this research can validate or invalidate) and `context.md` (who the users are).
- **Write after:** update each touched hypothesis's status, add durable insights to `knowledge/users.md`, and keep the raw notes in `source/`. Tag interview-derived claims `[interview]` — never launder them into `[data]`.

## Synthesis Framework

### 1. Data Collection Overview
- **Research Type**: Interviews, surveys, usability tests, etc.
- **Participant Profile**: Demographics, segments, sample size
- **Research Questions**: What we sought to learn
- **Methodology**: How data was collected

### 2. Key Themes Identification

Organize findings into themes using this structure:

**Theme Name**
- **Description**: What this theme represents
- **Prevalence**: How many participants mentioned this (e.g., "8 out of 12 participants")
- **Supporting Quotes**: 2-3 representative quotes
- **Implication**: What this means for our product

Aim for 4-8 major themes per research effort.

### 3. Pain Points Analysis

For each identified pain point:
- **Pain Point**: Clear description
- **Severity**: High/Medium/Low (based on impact and frequency)
- **Current Workaround**: How users deal with it today
- **Evidence**: Specific examples from research

### 4. Feature Requests

Categorize requests:
- **Must-Have**: Critical needs blocking user success
- **High Value**: Would significantly improve experience
- **Nice-to-Have**: Incremental improvements

For each request:
- **Request**: What users asked for
- **Frequency**: How often it came up
- **User Quote**: Representative example
- **Underlying Need**: Why they want this (dig deeper than surface request)

### 5. User Workflow Insights

Document actual workflows observed:
- **Current State**: How users accomplish tasks today
- **Pain Points**: Where they struggle
- **Ideal State**: What they wish they could do
- **Opportunities**: Where we can add value

### 6. Segmentation Insights

If research reveals distinct user segments:
- **Segment Name**: Descriptive label
- **Characteristics**: What defines this segment
- **Unique Needs**: How their needs differ
- **Size/Importance**: Relative weight for prioritization

### 7. Competitive Insights

If users mentioned competitors or alternatives:
- **Competitor/Alternative**: What they use
- **Why They Use It**: What it does well
- **Gaps**: What it doesn't do
- **Switching Barriers**: Why they don't switch fully

### 8. Recommendations

Prioritized recommendations based on insights:

**High Priority**
- Recommendation with supporting evidence
- Expected impact

**Medium Priority**
- Recommendation with supporting evidence
- Expected impact

**Low Priority / Future Consideration**
- Recommendation with supporting evidence
- Expected impact

### 9. Open Questions

Research gaps identified:
- What we still need to understand
- Suggested follow-up research
- Uncertainties requiring validation

## Analysis Guidelines

**When synthesizing interviews:**
- Look for patterns across multiple participants
- Note both what users say AND what they do
- Pay attention to emotional reactions
- Identify jobs-to-be-done, not just feature requests

**When analyzing quotes:**
- Use verbatim quotes in "quotation marks"
- Attribute quotes: [Participant ID, Role, Context]
- Select quotes that illustrate patterns, not outliers
- Include both positive and negative feedback

**When identifying themes:**
- Use descriptive names, not generic labels
- Provide evidence for each theme
- Quantify when possible ("7 out of 10 users...")
- Connect themes to business objectives

## Quality Checks

- [ ] Themes identify patterns across multiple participants, not individual responses
- [ ] Insights connect to specific product decisions, not just observations
- [ ] Each claim includes supporting evidence (quotes, counts, or examples)
- [ ] Observations and interpretations are clearly separated
- [ ] Findings are prioritised by impact, not just listed

## Anti-Patterns

- [ ] Do not list every individual comment — synthesis must identify patterns across participants
- [ ] Do not make interpretive leaps without supporting evidence from the data
- [ ] Do not focus on feature requests before understanding the underlying problem — always identify the job-to-be-done first
- [ ] Do not ignore contradictory data — conflicting findings must be surfaced and noted
- [ ] Do not present results without quantifying prevalence — state how many participants held each view

## Example Theme

```
**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
```

## Template Output Structure

When synthesizing research, use this structure:

```markdown
# 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)
```
