How to analyse user interviews, step by step

Before you start

You need three things on the table: the decision this study has to inform, the transcripts, and a note of how each participant was recruited. The third one matters more than it looks. A study of people recruited from your power-user Slack and a study of people recruited from last month's sign-ups produce different findings about the same product, and only the recruitment note tells a future reader which one they are holding.

The seven steps

1. Fix the question before you open a transcript. Write down the decision this analysis has to inform. Analysis without a decision attached expands to fill whatever time it is given and ends in a summary nobody uses.
2. Read one interview end to end without coding it. Read a single transcript through, taking no notes and applying no labels, to build a sense of how participants talk. Coding before you have that sense produces labels shaped by your assumptions rather than by the data.
3. Tag observations, not opinions. Go through each transcript and mark what happened and what was said: actions taken, obstacles hit, workarounds used, words the participant chose. Keep interpretation out at this stage and keep every tag attached to its verbatim quote.
4. Group tags into candidate themes. Cluster tags that describe the same underlying obstacle even when the wording differs. A theme needs a name a participant would recognise, and it needs to survive you asking which quotes contradict it.
5. Count each theme against its own base. For every theme, record how many participants mentioned it and how many could have. Six of the nine participants who reached the import step is a different finding from six of twenty-four participants overall.
6. Separate observations from inferences. Split the write-up into what participants did and said, and what you concluded from it. Label every inference as one so a reader can disagree with your interpretation without discarding your evidence.
7. State what the evidence cannot support. Name the segments not represented, the questions the data cannot answer, and the claims the sample size will not carry. A report silent about its gaps will be read as having none.

The counting mistake, in detail

Step five is worth its own section, because it is the one that changes decisions and the one nearly everyone gets wrong.

Suppose you ran 24 interviews. Six participants described the export feature as confusing. The natural sentence to write is "a quarter of participants found export confusing" — 6 of 24. It is arithmetically correct and it is misleading, because only nine participants ever used export. The honest finding is that two-thirds of the people who tried it found it confusing.

A quarter sounds like a rough edge worth a ticket. Two-thirds sounds like a feature that does not work. The evidence is identical; only the denominator changed. So, for every theme, write down both numbers: how many people mentioned it, and how many were in a position to.

What makes a theme real

Three tests, in order of how often they catch something:

• Independence. Did these participants arrive at it separately, or did you introduce the idea in an earlier question and hear it echoed back? A theme visible only after you raised the topic is a response to your interview guide.
• Contradiction. Go looking for the quotes that cut against it. A theme with no counter-evidence anywhere in 24 transcripts is more likely to be a theme you stopped looking past.
• Recognisability. Could you name the theme back to a participant and have them agree that is what they meant? If it only makes sense in your team's internal vocabulary, it is a category you imposed, not a pattern you found.

Writing it up

Lead with the decision, not the method. The reader wants to know what to do; the sample and the approach belong immediately after, where they can be checked, not in a preamble nobody reaches.

For each finding, four lines:

• The observation, with its count and its denominator.
• Two or three verbatim quotes.
• Your inference, labelled as an inference.
• The opportunity it points at, phrased as a customer outcome.

Then a short section on what the study does not cover. This is not hedging — it is what stops someone citing your eight interviews as evidence about the whole customer base six months from now.

Next

The grouping stage in step four is a compressed version of a formal method; if you want the full six-phase version, read thematic analysis. For turning finished findings into roadmap decisions, read from evidence to opportunity. And for where a model can take over the mechanical passes, AI user research covers what it is and is not reliable for.