Using AI to synthesize user interviews without losing the nuance

You ran eight user interviews last week. You have hours of recordings, a folder of transcripts, and a deadline on Friday. The obvious move is to paste everything into an AI tool and ask for "key insights". What comes back usually looks reasonable: five tidy themes, a few quotes, a confident summary. The problem is that it often reads like it could describe any product, and the one surprising thing a user said in minute 37 is gone.

AI is useful for interview synthesis, but only if you treat it as a fast research assistant, not as the researcher. In this article we walk through a workflow that keeps the speed and protects the nuance: how to prepare transcripts, which tasks to hand to the model, which to keep for yourself, and how to check the output before it shapes your design decisions.

Why AI summaries flatten your research

Language models are built to produce the most likely continuation of text. When you ask for a summary, they lean toward what is common across the transcripts and toward phrasing that sounds like a typical research report. That has three side effects you should expect:

• Outliers disappear. One participant who uses your product in a completely different way gets averaged out, even though that person might point to your next segment.
• Intensity is lost. "It's a bit annoying" and "I almost cancelled because of this" can end up in the same bullet.
• Themes get invented. If you ask for five themes, you will get five, whether the data supports five or two.

None of this means you should avoid AI. It means the way you ask matters more than which tool you use.

Prepare transcripts before you prompt

Most bad synthesis starts with messy input. Spend twenty minutes on preparation and the output improves more than any prompt trick will give you.

1. Use one file per participant. Name it with a short ID and two or three facts: role, company size, how long they have used the product. For example, P4 – freelance designer – solo – 8 months.
2. Keep speaker labels. The model needs to know which lines are the interviewer and which are the user. Interviewer questions that lead the answer should stay visible so you can discount those answers later.
3. Remove personal data. Strip names, emails, client names and anything you would not want stored by a third party.
4. Add your research questions at the top. Three to five questions you actually needed answered. This gives the model a frame and gives you a checklist.

Ask for evidence, not conclusions

The single most useful change is to stop asking "what are the insights?" and start asking the model to extract and organise evidence. Conclusions are your job. Extraction is where AI saves you hours.

A prompt that works well for a single transcript looks like this:

For each research question below, list every passage where the participant talks about it. Quote the passage exactly, add the timestamp, and add one line describing what the participant did or felt. Do not summarise across passages. If a passage does not fit any question, put it in a list called "Unexpected".

The "Unexpected" list is where the nuance lives. Read it in full for every participant. In our experience it is the part of the output that most often changes a design direction.

Synthesise across participants in a second pass

Once each transcript has its own evidence sheet, you can move to cross-participant patterns. Do this as a separate step, with the evidence sheets as input rather than the raw transcripts. It keeps the model working with quotes you have already checked.

Useful questions for this pass:

• Which behaviours appear in at least three participants, and which participants are they?
• Where do participants contradict each other on the same topic?
• Which problems did participants describe with a workaround they built themselves?
• What did only one participant mention that is worth following up?

Asking for participant IDs next to every pattern is important. "Users find onboarding confusing" is vague. "P2, P5 and P7 skipped the setup checklist and later asked where their settings were" is something you can design against.

Check the output before you trust it

Models misquote, merge two people into one, and occasionally invent a quote that sounds plausible. Build a short verification habit into the process:

1. Spot-check quotes. Pick five quotes at random and find them in the original transcript. If one is wrong, check all of them.
2. Count the evidence. For each pattern, make sure the number of participants matches the IDs listed.
3. Look for what is missing. Re-read your own notes from the interviews. If something you remember as important is absent, ask the model directly where that topic appears.
4. Re-run with a different framing. Ask the same question a second way, for example "what made participants hesitate?" instead of "what problems did participants have?". Patterns that show up both times are more reliable.

Keep the judgement calls human

Some parts of synthesis should stay with you, even if the model offers to do them:

• Prioritising. Deciding which problem matters most depends on business goals, technical cost and strategy the model does not know.
• Reading tone. Transcripts lose hesitation, sarcasm and the pause before an honest answer. If you were in the room, your memory of those moments is data.
• Naming insights. The words you choose for an insight shape how your team thinks about it. Write them yourself, based on the evidence.

A simple rule: the model can tell you what was said and by whom. You decide what it means and what to do about it.

Turn synthesis into design decisions

Research only pays off when it changes what you build. Finish the process by writing a short decision log, one line per insight, in this format:

We saw (evidence with participant IDs), so we will (design change), and we will know it worked when (signal you can measure).

You can ask AI to draft this log from your verified patterns, then edit it. Founders in particular find this format useful because it connects interviews directly to the roadmap and makes it easy to explain why a feature changed.

Conclusion

AI can cut interview synthesis from days to hours, but speed is only valuable if the findings are still true to what users said. Prepare clean transcripts, ask for quoted evidence instead of conclusions, synthesise in two passes, verify before you trust, and keep prioritisation and interpretation for yourself. Do that, and the surprising comment from minute 37 makes it into your design instead of disappearing into a tidy summary.