# User Interview Synthesis Skill

Transform raw interview transcripts into a structured synthesis document that surfaces themes, pain points, and actionable insights.

## Required Inputs

Ask the user for these if not provided:
- **Interview transcripts or notes** (even rough notes work)
- **Number of participants and their profiles** (role, company size, context)
- **Research questions** (what was the study trying to answer?)
- **Date range** of research (for context)

## Process
1. Read all provided transcripts fully before drawing conclusions
2. Identify recurring themes (minimum 3 mentions to qualify as a theme)
3. Categorize findings into: Pain Points, Workflow Insights, Feature Requests, Delight Moments
4. Select 2-3 verbatim quotes per theme that best represent the pattern
5. Draft "So What" implications for each theme — what does this mean for the product?
6. **Validate** — Confirm every theme has quotes from at least 3 participants. Flag any insight resting on fewer as low-confidence.

## Output Structure

### Research Synthesis: [Study Name]
**Participants:** [n]
**Date Range:** [dates]
**Research Questions:** [list]

#### Theme 1: [Theme Name]
- Summary (2-3 sentences)
- Supporting quotes (from at least 3 participants)
- Implication for product

[Repeat for each theme]

#### Low-Confidence Signals (1-2 participants only)
[Findings worth tracking but not acting on yet — note what further research would confirm or deny]

#### Recommended Next Steps
[Specific, actionable recommendations based on findings]

## Deeper Materials

This skill ships with support files — use them when they are available:

- **`references/coding-transcripts.md`** — Coding Interview Transcripts Without Losing the Signal. Apply it while producing the output; it carries the calibration and judgment calls the method summary above compresses.
- **`templates/per-session-capture.md`** — a fill-in version of the deliverable with the quality gates inline. Offer it when the user wants to work the document themselves rather than have it generated.

## Quality Checks

- [ ] Every theme is supported by quotes from at least 3 participants
- [ ] Implications connect to specific product decisions, not just observations
- [ ] Researcher bias check: no leading language, findings don't all support one hypothesis
- [ ] Single-source signals are flagged separately, not mixed into main themes
- [ ] Research questions from the study brief are each addressed (even if the answer is "inconclusive")

## Anti-Patterns

- [ ] Do not mix single-source signals into main themes — insights cited by only one participant must be flagged separately
- [ ] Do not write implications that are observations restated rather than product decisions enabled
- [ ] Do not include themes that only support the project hypothesis — contradictory findings must be surfaced, not omitted
- [ ] Do not present findings without quotes — every theme requires verbatim evidence from at least 3 participants
- [ ] Do not leave research questions unanswered — each question from the study brief must be explicitly addressed, even if the answer is inconclusive
