How to synthesize user interviews from your notes

How to synthesize user interviews, step by step

Synthesis turns a set of interview notes into a short list of findings you can act on. The method that holds up for most product teams has five steps:

1. 1Write one note per interview, as soon as you can after the call.
2. 2Pull out observations: one thing a person said or did per line, tagged with who said it.
3. 3Tag each observation with a short code describing what it's about.
4. 4Group the codes into themes, usually on an affinity map.
5. 5Write each finding with its evidence: how many people, which ones, and their own words.

The thread running through all five is traceability. Every finding should lead back to specific people and specific lines in your notes. That's what keeps a confident summary from drifting away from what users actually said.

Start with one note per interview

Write each interview up in its own note, the same day. The UK government's service manual advises doing analysis as soon as you can after each round of research, while it is still fresh in people's minds (GOV.UK Service Manual). Give each participant a short ID, such as P1 to P8, and use it everywhere.

In each note, keep what they said separate from what you think it means. Put direct quotes in quotation marks. Put your interpretations under their own heading. Mixing the two is how a hunch turns into a "finding" without anyone noticing.

Pull out observations, one per line

Go through each interview note and pull out every observation worth keeping into a single list or board. GOV.UK's guidance is to use a single note for each observation and write exactly what was seen or heard, such as verbatim quotes or observed behaviour, not what you think it means.

Add the participant ID to every observation. It costs two characters and it's the most useful habit in this whole process. Without it, you can't count people later, only sticky notes.

• P3: "I keep a paper list next to the screen because the system logs me out."
• P3: rebooked two patients by phone during the call.
• P5: "Friday afternoons are the worst, everyone wants Monday."

Tag what people said

Next, give each observation a short tag describing what it's about: "workarounds", "session timeouts", "rebooking", "peak times". This is what qualitative researchers call coding. In Braun and Clarke's widely used method for thematic analysis, generating initial codes comes right after getting familiar with the data, and before searching for themes, reviewing them, and defining and naming them (Braun & Clarke, 2006).

Keep tags close to the data at first. "Uses paper list" is better than "low trust in system", which is already an interpretation. You can group and rename later.

Group tags into themes with an affinity map

Affinity diagramming refers to organizing related observations, ideas, concepts or findings into distinct clusters, in the words of Nielsen Norman Group's guide (Krause & Pernice, 2024). On a whiteboard or a digital board, move the observations around until clusters appear, then give each cluster a label that represents all the notes in it.

GOV.UK adds two useful moves: discard irrelevant or isolated notes, and break large groups into smaller themes. A cluster called "scheduling problems" with forty notes in it isn't a theme yet. It's a topic.

Count people, not mentions

A theme that one talkative participant raised eight times is not the same as a theme four different people raised once each. When you count, count participants. Write findings as "4 of 8 practice managers", not "many users".

Be honest about what small numbers can tell you. In one study of sixty in-depth interviews, researchers found that saturation, the point where no new themes appear, occurred within the first twelve interviews, with basic elements of the main themes present as early as six (Guest, Bunce & Johnson, 2006). That study's participants were a fairly similar group: women in two West African countries. If your users vary a lot, by role, company size or market, eight calls can't speak for all of them.

• Say who the finding applies to: "practice managers at small clinics", not "our users".
• Note counter-evidence: who didn't have this problem, and why.
• Mark confidence: seen in most interviews, in a few, or in one memorable one.

Write findings that keep their source

A finding you can act on has four parts. Here is an invented example from eight interviews with clinic practice managers:

• Finding: Practice managers keep paper backups of the day's appointments because the system logs them out during busy periods.
• Evidence: 4 of 8 (P1, P3, P5, P7). P3: "I keep a paper list next to the screen because the system logs me out."
• Counter-evidence: P2 and P6, both at clinics with a dedicated receptionist, didn't mention timeouts.
• Confidence: medium. Consistent across small clinics; untested at larger ones.

When someone asks "who said that?" in a review, you can answer in seconds, and they can read the quote themselves.

Common synthesis mistakes

• Synthesizing from memory instead of notes. The calls you remember most clearly are the most vivid, not the most typical.
• Losing the participant ID somewhere between interview and finding.
• Treating your interpretation as an observation.
• Writing "users want" when one user asked.
• Waiting until all interviews are done. Short synthesis after every two or three calls sharpens the next ones.

Finding the quote behind a finding

The slowest part of synthesis is going back to check: which call was that, and what exactly did they say? If you keep interview notes in Lumyo, you can choose which notes a chat reads, such as all eight interviews, and ask a question across them. Each answer cites the notes it used, and tapping a source opens the exact line, so you can confirm the quote before it goes in a deck. For how to take notes that make this easier, see how to find what was said in a meeting or customer call.