How to synthesise user interviews into themes

The hard part is not usually running the interviews.

It is what happens afterwards.

You finish twelve conversations, or twenty, or thirty. You have transcripts, notes, and a few quotes you already know you want to show the team. Then you open the folder and realise the next question is much harder than the last one:

What did we actually learn?

That is synthesis. Not transcription. Not highlighting. Not making a long list of things people said. Synthesis is the work of turning many specific stories into a small set of defensible themes you can use to make a decision.

This guide is for a solo founder or tiny SaaS team that has done the interviews and now needs a practical way to finish the job. It uses a simple two-pass workflow:

1. Summarise each interview while it is still fresh.
2. Compare those summaries across interviews until the repeated patterns become clear.

You can do the whole thing in a spreadsheet. You do not need a research repository, a wall of sticky notes, or an elaborate taxonomy before you begin.

First, know what synthesis is

Nielsen Norman Group’s guide to thematic analysis distinguishes between the raw data, the codes you assign to it, and the themes you eventually define from it. That distinction matters because founders often stop too early.

If you underline every mention of onboarding, pricing, and exports, you have organised the material. You have not yet synthesised it.

A code is a useful label:

• onboarding
• pricing
• spreadsheet workaround
• trust gap

A theme is an interpretation:

• Users treat the dashboard as a staging area, then move the real work into spreadsheets.
• New admins delay setup because they are unsure which data source is authoritative.
• Customers describe price as the problem when the deeper issue is that value arrives too late.

The first set tells you what people mentioned. The second tells you what it means.

That is also why good synthesis cannot be fully mechanical. Braun and Clarke’s original paper on thematic analysis treats themes as the result of analysis, not as objects waiting to be discovered untouched. A more recent methods paper on making themes as a goal of research makes the same point bluntly: themes are made through careful judgement; they do not simply “emerge” on their own.

The practical implication is reassuring. If synthesis feels like thinking, not clerical work, you are doing the real part.

The two-pass workflow

The cleanest synthesis process for a small team is a two-pass process.

Pass one: make one useful artefact per interview

Teresa Torres’ interview snapshot is the right starting point because it keeps each conversation close to the participant’s story instead of reducing it immediately to a pile of tags. Her template captures who you spoke to, what happened in the story, what opportunities appeared, and the key quotes worth preserving.

For founder-led work, I would keep the snapshot to one page and use these fields:

Do this the same day if you can. The transcript will still exist later, but the tone, hesitation, and sequence of the story are easiest to capture while the conversation is warm.

Pass two: compare across interviews

Once you have a stack of snapshots, move from one participant at a time to the whole set.

This is where affinity mapping helps. ASQ describes an affinity diagram as a way to organise many ideas into natural relationships. In practice, for a solo founder, the easiest version is not a wall. It is a spreadsheet.

Tomer Sharon’s rainbow spreadsheet remains a useful model:

One row is one observation. One column is one participant. Mark where the observation appears. Do not worry yet about having elegant theme names. Your first job is to make the evidence visible enough that patterns can be argued with.

Step 1: pull observations out of the snapshots

Read the snapshots in one sitting if possible. Then extract one observation per row.

Good observations are specific:

• “Exports the weekly report to Google Sheets before sending it to leadership.”
• “Needs the ops lead present before connecting the first data source.”
• “Stopped using alerts after two false positives in the first week.”

Weak observations are already half-synthesised:

• “People do not trust the dashboard.”
• “Onboarding is confusing.”
• “Pricing is a problem.”

Those may become true later. At this stage, keep the evidence close to what actually happened.

This is also where founder bias starts to creep in. The observation you expected will feel instantly important. The surprising one may feel like noise. Capture both. If you only collect the evidence that supports the roadmap you already wanted, the synthesis is over before it begins.

Step 2: sort by a real question

The quality of the sort depends on the question you ask of the data.

NN/g’s article on affinity-diagramming pitfalls is especially useful here: if the focus question is vague, the clusters will be vague too. “What did users say?” produces a messy wall. “Where does value leak out of the workflow?” produces much sharper groupings.

For a B2B SaaS founder, strong synthesis questions often look like:

• Where do users leave the product to finish the real job?
• What changed just before usage dropped?
• Which parts of the workflow create avoidable uncertainty?
• What do customers do before they ask support for help?
• What do churned users say they were actually trying to accomplish?

Sort once by the broad topic if that helps you get oriented. Then sort again by the decision you need to make. The second sort is usually where the useful themes appear.

Step 3: turn clusters into candidate themes

Clusters are not themes yet.

Pricing, onboarding, and exports are folders. They are not findings.

To become a theme, a cluster needs a sentence with a claim in it:

• New admins postpone setup when they cannot tell which system is the source of truth.
• Customers describe price as the issue when the product has not become part of the weekly workflow.
• The dashboard is useful for checking data, but not trusted enough to be the final place work gets shared.

NN/g warns against “keyword matching”: grouping things because they use the same word rather than because they share meaning. That is why “onboarding issues” is a poor theme name. It hides the actual pattern you need to act on.

If you cannot write the cluster as a clear sentence, you probably have not finished the synthesis.

Step 4: stress-test the themes

Before you ship roadmap changes from the themes, try to break them.

For each candidate theme, ask:

1. What supports this? Which participants and observations belong underneath it?
2. What contradicts it? Which interviews point in another direction?
3. Who does this apply to? Is it universal, or only true for a segment?
4. What decision would change if this theme is right?

This is where a spreadsheet is better than memory. It lets you filter by segment, compare paid users with churned users, and see whether a theme is broad or merely loud.

It also protects you from the most common founder error in synthesis: mistaking the most articulate participant for the most representative pattern.

The saturation literature is useful here, but only as a guide. Guest, Bunce, and Johnson’s classic study on how many interviews are enough found that larger themes stabilised relatively early in a focused, coherent sample, but saturation is not a magic number you can apply without looking at the shape of your own data. Use repetition as a signal that a theme is strengthening; do not use one published sample-size result as a substitute for judgement.

Step 5: write the output small enough to use

The finished synthesis should be much shorter than the raw material.

For a founder-led project, the useful output is usually:

• the working spreadsheet;
• three to five theme cards;
• one short memo saying what you learned, what you will do, and what you are deliberately not doing yet.

Each theme card should include:

That structure keeps the output honest. It shows the claim, the evidence, the limits, and the next decision in one place.

What not to do

Three mistakes ruin more founder syntheses than lack of software ever will.

Do not confuse quotes with findings

A vivid quote is useful because it carries texture. It is not a theme by itself. If one customer says something memorable and nine others say something less dramatic, the quote belongs in the evidence section, not at the centre of the roadmap.

Do not force every observation into a theme

Some things are one-offs. Some are weak signals. Some are simply interesting. The job is not to make every note earn a strategic role. The job is to decide which patterns are strong enough to guide action now.

Do not skip the second sort

The first sort often mirrors the interview guide: onboarding, pricing, workflow, support. The second sort asks the product question you actually care about. If you stop after the first, you have organised the data around your questions instead of the user’s reality.

A simple synthesis checklist

Use this when the interviews are done and you want to know whether you have actually finished.

If you can tick those seven boxes, you are not just holding a pile of interviews anymore. You have a synthesis.

Where tools help, and where they do not

AI can make this work faster. It can draft snapshots, pull candidate observations, suggest clusters, and help you move from a transcript folder to a reviewable first pass much more quickly than doing everything by hand.

But the part that matters most still needs judgement:

• Is this cluster actually one pattern or three?
• Is the quote memorable because it is representative, or only because it is well said?
• Does the apparent theme survive contact with the segment data?
• Which decision should change because of this?

That is why the best synthesis systems preserve an audit trail from theme back to observation back to interview. Speed is useful. Traceability is what makes the result trustworthy.

The short version

To synthesise user interviews into themes:

1. Make one snapshot per interview.
2. Pull concrete observations into a shared sheet.
3. Sort by the decision you need to make, not just by broad topic.
4. Turn clusters into clear claims.
5. Test each claim against contradictions and segment differences.
6. Write the output small enough that the team can act on it.

The interviews tell you what happened. Synthesis tells you what it means.

If you have done the conversations, finish the work. The useful themes are not hiding in one perfect quote. They are waiting in the repeated shape across many imperfect stories.