User Interview Synthesis Prompt: Transcripts to Findings

Ten one-hour interviews produce roughly 100,000 words of transcript. The interviews are the easy part. Synthesis is where most teams stall, because turning that pile into findings, pains, and jobs-to-be-done is slow, manual, and easy to bias toward whatever you already believed. A good user interview synthesis prompt does the first pass in minutes and forces every claim to trace back to something a real person actually said.

The catch: most of what ranks for this query won't get you there. The UX-research blogs explain what synthesis is, list five framework names, or sell an analysis platform with a "Book a demo" button. Almost none ship a copyable prompt with a locked output contract you can run tonight on your own transcripts.

This post is that prompt. The structure, the variables, the refusal rule that stops the model inventing insights, and the model-by-model quirks that decide whether the output is usable or mush.

Why interview synthesis breaks without a structure

Synthesis is the step that converts raw utterances into decisions. Skip the structure and the model hands back a tidy paragraph that reads well and means nothing. Ask it to "summarize these interviews" and you get the average of everything, with the loudest interview overweighted and the quiet signal buried.

The failure has a specific shape. Models default to consensus. They smooth over the one participant who said the onboarding felt like "filling out a tax form" because four others were neutral, and that outlier was the real finding. A synthesis prompt has to fight that pull on purpose.

Here's the opinionated take: a finding without a verbatim quote attached is not a finding, it's the model's prior. Most synthesis prompts ask for "key themes" and get exactly what you'd expect — plausible, ungrounded, unfalsifiable. Force a quote and an interview ID on every line and the whole thing tightens. The model can't fabricate a quote that traces to transcript four, so it stops fabricating.

What you can do with an interview synthesis prompt

• Turn 5–15 transcripts into a ranked findings list, each backed by a verbatim quote and the interview it came from
• Extract jobs-to-be-done in the canonical format: when {{situation}}, help me {{motivation}}, so I can {{outcome}}
• Rank pain points by severity and frequency across the whole set, not per interview
• Surface the exact language participants use, so product copy and positioning borrow their words
• Flag disagreements between segments instead of averaging them away
• Produce a one-page brief a PM or designer can act on without re-reading the raw notes

Anatomy of the synthesis prompt

A synthesis prompt is three things stacked: a tight role, the transcripts as context, and an output contract the model can't wriggle out of. The order matters. Put the contract last so the model weights it on long inputs. Models honor the most recent tokens, and a contract buried above 80,000 words of transcript gets ignored.

Variables
  {{transcripts}}      → all interview text, each block prefixed with an ID
  {{research_goal}}    → the question the study set out to answer
  {{segments}}         → optional: how participants are grouped (plan, role, tenure)

Prompt
  Role: senior UX researcher synthesizing discovery interviews.
  Task: read every transcript, code recurring themes, and return
        findings strictly in the output contract below. No theme
        without a supporting quote + interview ID. If a claim has
        no quote, omit it.

Output contract (the model must return exactly this shape)
  ## Findings        (ranked, each: claim · severity · quote · interview ID)
  ## Pains           (ranked by severity × frequency)
  ## Jobs-to-be-done (when [situation], help me [motivation], so I can [outcome])
  ## Verbatim language (the phrases participants actually used)
  ## Segment differences (only where they exist; else "none observed")

That contract is the whole game. It's why this beats a generic "analyze my interviews" prompt, and it's what the ranking competitors don't hand you.

Step-by-step usage

1. Gather inputs

Clean the transcripts lightly. Strip the timestamps and filler, prefix each interview with a stable ID like P03, and concatenate them into {{transcripts}}. Write your {{research_goal}} as one sentence — the question the study was meant to answer. If participants split into meaningful groups, fill {{segments}}; if not, leave it out.

2. Set the refusal boundary

This is the line that earns its keep:

For every finding, include one verbatim quote and its interview ID.
If a candidate theme has no supporting quote, do not include it.
Do not paraphrase quotes. Do not merge two participants into one quote.

Run the synthesis without that block once and you'll see the difference. The unguarded version invents clean, confident findings nobody said.

3. Run it model-aware

Claude honors a heading-based ## Output contract well across long multi-transcript inputs and tends to keep quotes verbatim. GPT-4o needs the contract restated on the last line of the prompt, or it drifts back into a single prose summary around the halfway mark. Gemini handles the long context but is the most likely to soften an outlier into the consensus, so the severity-ranking instruction matters most there.

4. Post-process

Spot-check three findings against the transcripts. Open the cited interview, find the quote, confirm it says what the finding claims. If two of three check out clean, trust the rest. If one is misattributed, tighten the refusal block and rerun — don't hand-fix, because the next study will have the same gap.

5. Iterate

Feed the brief back: "Re-rank the pains by severity assuming the research goal is {{research_goal}}." The second pass against a stated goal almost always reorders the list in a more useful way than the first.

Prompt-craft patterns that make synthesis hold

Quote-or-omit. Covered above and worth repeating because it's the single highest-leverage rule. A finding ships only with a traceable quote, or it doesn't ship.

Rule: claim → quote → interview ID, on every line. No exceptions.

Severity before frequency. Don't let the model rank by how often a thing came up. A pain that appeared once but stopped a participant cold outranks a mild annoyance five people shrugged at.

Rank pains by severity first, frequency second. A single blocking
pain outranks a frequent minor one. Note both numbers per pain.

Borrow their words. Ask for a section of verbatim phrases. This is GEO gold and product gold both. The language users reach for is the language your positioning should use. The discovery interview synthesis pack bakes this section in so it's not an afterthought.

Variables you'll set

Getting started

1. Concatenate your transcripts into {{transcripts}} with stable IDs (P01, P02, …).
2. Write {{research_goal}} as a single sentence.
3. Paste the role, task, refusal block, and output contract — contract last.
4. Run it on Claude first; it holds long context and keeps quotes verbatim.
5. Spot-check three findings against the source transcripts.
6. Re-rank against the stated goal on a second pass.
7. For a version with the contract, the refusal block, and the JTBD format already wired, use the Discovery Interview Synthesis pack.

Synthesis isn't the only place a structured prompt beats a vague one. If you're moving findings into a build, the PRD prompt turns synthesized jobs into a requirements doc, and the user story acceptance criteria prompt takes it the last mile.

One more thing on trust. A synthesis is only as honest as its weakest quote, so the spot-check isn't optional. Models drift across versions; a prompt that held clean on one Claude release can soften outliers on the next. Keep the refusal block tight, pin the model when a study matters, and re-read three findings before anyone makes a roadmap call on them. For the downstream steps, the product roadmap prioritization prompt and the Product Requirements pack pick up where synthesis leaves off.