How to synthesize user interviews with AI (without losing the evidence)

Short answer: to synthesize user interviews with AI, first clean and label your transcripts, then have the model code each interview separately, extract verbatim quotes with their source, cluster the codes into themes across interviews, and turn themes into insights with explicit severity and frequency. The non-negotiable rule: no insight without a quote, and no pattern without more than one source. AI makes synthesis fast. That rule makes it trustworthy.

Most teams that try AI synthesis hit the same wall. The summary reads well, the themes sound plausible, and then someone in the roadmap review asks "who actually said that?" and nobody can answer. This guide is about avoiding that moment.

What "synthesis" actually means

Research synthesis is the process of turning raw qualitative data, such as interview transcripts, call recordings, support tickets, and survey comments, into a small set of evidence-backed insights that change a product decision.

It is not summarization. A summary compresses one conversation. Synthesis compares many conversations and tells you what is true across them, how strongly, and why it matters.

Classic synthesis has three layers, and AI can help with all of them:

If you've done affinity mapping with sticky notes, or thematic analysis in the style of Braun and Clarke, this is the same process. AI just does the sticky notes.

Why AI synthesis goes wrong

Large language models are very good at producing text that sounds like a research readout. That is the problem. Four failure modes show up again and again:

1. Invented or "smoothed" quotes. The model paraphrases a user and presents it as a quote, or blends two speakers into one sentence.
2. False consensus. One vivid interview becomes "users want X". A theme mentioned once gets the same weight as one mentioned in every call.
3. Interviewer leakage. Your own questions and hypotheses get reported back as user needs, because the model can't always tell who said what.
4. Lost provenance. Even when the insight is right, nobody can trace it back to the conversation it came from, so it can't survive a skeptical stakeholder.

None of these are fixed by a cleverer prompt alone. They're fixed by a process that forces the model to keep evidence attached to every claim.

Step-by-step: synthesizing interviews with AI

1. Prepare and label your transcripts

   Get a clean transcript for every interview, with speaker labels. Meeting tools export .vtt or .srt caption files; keep the speaker names. Add a short header to each file: participant role, company size, segment, and the date. Remove small talk if you like, but never edit what participants said.

2. Code each interview on its own first

   Have the model process one transcript at a time and output codes, each with the verbatim quote it came from and the speaker. Processing interviews separately prevents one loud conversation from coloring how the model reads the others. Exclude interviewer lines from what counts as evidence.

3. Cluster codes into themes across interviews

   Now give the model the coded output from all interviews and ask it to group codes into themes. For each theme, require the list of supporting quotes and which interviews they came from. This is where frequency becomes visible: a theme backed by six participants is different from one backed by one.

4. Turn themes into insights

   For each strong theme, write the insight: what is happening, why, and what it implies. Rate severity (how painful), frequency (how many sources), and type (pain point, opportunity, behavior, feature request). An insight that doesn't suggest a decision is still a theme.

5. Verify before you share

   Pick a sample of quotes and search the original transcripts for the exact text. Check that every high-severity insight is backed by more than one participant. Look for themes that only appear in questions you asked, which signals interviewer leakage.

A prompt structure that keeps evidence attached

You don't need a magic prompt, but you do need a strict output contract. Something like this works with any capable model:

You are coding one customer interview transcript.

Rules:
- Only use what the participant said. Ignore interviewer
  lines as evidence.
- Every code must include an exact verbatim quote, copied
  character for character.
- If you cannot find a quote that supports a code, do not
  output the code.

Output a list of:
- code: short label (3-6 words)
- quote: exact text from the transcript
- speaker: participant name or ID
- context: one sentence on what prompted it

Then, for the cross-interview step:

Group these coded excerpts from N interviews into themes.

For each theme output:
- theme: one-sentence statement
- supporting_quotes: list of quote + interview ID
- interview_count: number of distinct interviews supporting it
- counter_evidence: any quotes that contradict the theme

Do not create a theme supported by only one interview; list those
separately as "single-source signals".

The counter_evidence field matters more than it looks. Asking the model to look for disconfirming quotes is the cheapest defense against false consensus.

How to tell if your synthesis is any good

Before a synthesis drives a roadmap decision, score it against five checks. These are the same dimensions we use in Praxiom's Research Quality Score, and you can apply them by hand:

If a synthesis fails two or more of these, it isn't ready to drive a decision. Go back to step 2 rather than polishing the wording.

When a general AI assistant is enough, and when it isn't

Pasting transcripts into a general assistant like Claude or ChatGPT is a perfectly good way to start. It works well when:

• you have a small, one-off batch of interviews,
• one person owns the research end to end,
• you'll verify quotes yourself before sharing.

It starts to break when research becomes continuous. Every chat starts from zero, findings from March don't connect to findings from September, and the link between an insight and its source lives only in your head. That's when a dedicated synthesis tool earns its place. The real value isn't speed. It's that evidence stays attached and accumulates across studies.

How Praxiom does this

Praxiom was built around the rule at the top of this post. When you upload interviews, including PDFs, docs, recordings, or .vtt/.srt meeting transcripts, the agent extracts insights in which every insight carries supporting quotes tagged to the source they came from, along with a severity rating, a frequency count, and a type. Each synthesis then gets a Research Quality Score across the five dimensions above, so weak synthesis is flagged before it reaches a PRD. Insights persist in the workspace, so the next study builds on the last one instead of starting over.

From there, insights feed evidence-backed prioritization and, eventually, specs an AI coding agent can build from.

Synthesis checklist

Use this before any synthesis leaves your hands:

• Every transcript has speaker labels and a participant header
• Interviews were coded individually before being combined
• Every insight has at least one verbatim, verifiable quote
• Strong claims are supported by more than one participant
• Single-source signals are labeled as hypotheses, not findings
• Counter-evidence was looked for and recorded
• Severity and frequency are rated, not implied
• Each insight points to a decision, not just a description