Thematic analysis: the six phases, and the two mistakes

What it is

Thematic analysis is a method for identifying and reporting patterns across qualitative data — interview transcripts, open-text survey answers, support tickets, diary entries. It is the default approach in applied research for a good reason: it makes no commitment to a particular theory, so it can be used on almost any dataset, and its steps are explicit enough to be checked by someone who was not there.

It is also frequently done badly, in ways that are hard to spot from the write-up. The two failure modes in the last section account for most of it.

Codes and themes are not the same thing

This distinction carries the whole method, so it is worth being precise.

A code is a label applied to one extract, capturing something relevant to the question: abandoned setup at import, expected the file to be validated first, asked a colleague instead of reading docs. Codes are descriptive, close to the data, and there are a lot of them.

A theme is a pattern of shared meaning across many extracts, organised around a central idea: setup demands knowledge the product never supplies. Themes are interpretive, and there should be few — a study with fourteen themes almost always has a list of topics rather than a set of findings.

The test: a theme makes a claim. If you cannot disagree with it, it is a topic.

The six phases

The phases are recursive, not linear. Reviewing sends you back to coding, and it should — a pass that never loops is a pass that accepted its first guess.

1. Familiarisation. Read the whole dataset before coding any of it, and write down first impressions separately from the data. The point is to know the shape of what you have; skipping it produces codes shaped by the first transcript you happened to open.
2. Generating initial codes. Work systematically through every item, labelling anything relevant to the research question. Codes at this stage are descriptive and numerous — forty or eighty of them is normal — and each one stays attached to the extract it came from.
3. Searching for themes. Sort codes into candidate themes by what they have in common at the level of meaning rather than of wording. A theme is a pattern of shared meaning organised around a central idea, not a bucket of topics that use the same noun.
4. Reviewing themes. Test each candidate twice: against its own coded extracts, and against the full dataset. A theme whose extracts do not hang together splits; two themes saying the same thing merge; a theme with thin support is discarded however much you like it.
5. Defining and naming themes. Write a short definition of each theme stating what it captures and what falls outside it. If you cannot describe a theme's scope in a sentence or two, it is still doing too many jobs.
6. Producing the report. Write up each theme with enough verbatim evidence for a reader to judge the interpretation, and make an argument rather than listing extracts. Quotes illustrate the claim; they do not replace it.

Inductive or deductive

Inductive analysis lets themes emerge from the data. It is slower, and it is the only way to find the thing you were not looking for.

Deductive analysis codes against a framework decided in advance. It is faster, comparable across studies, and structurally unable to surprise you.

Applied product research is usually a hybrid: inductive coding, steered by the decision the study has to inform. State which you did. A reader assessing a finding needs to know whether the categories came from the customers or from you.

The two mistakes

Mistake one: the topic summary wearing a theme's clothes

A section headed "Pricing" that reports some participants found the product expensive and others found it fair is not a theme. It is a bucket. It contains no claim, points at no decision, and could have been written before the study.

The repair is to ask what the extracts in the bucket have in common at the level of meaning. Often it turns out they are not one theme at all: the people calling it expensive were comparing against a free tool they already had, and the ones calling it fair were comparing against an agency invoice. That is two findings about reference points, and it is actionable in a way "Pricing" never was.

Mistake two: the discussion guide as the findings

When the themes map one-to-one onto the sections of the interview guide — onboarding, collaboration, reporting, pricing — the analysis has reported the structure of the questions rather than anything about the answers.

This one is easy to detect and uncomfortable to fix: it usually means going back to phase two and coding for what participants said rather than for which question they were answering when they said it.

Doing it with a model in the loop

Phases two and three — coding and clustering — are mechanical at scale and suit automation well. Phases four and five are judgement, and a model will keep a weak theme it should have cut, because nothing in the text tells it the theme is thin. The division of labour that works: let the model code exhaustively and propose clusters, then do the reviewing and naming yourself, with every extract still attached.

More on where that line sits in AI user research. For the compressed, deadline-friendly version of this method applied to interviews specifically, see how to analyse user interviews.