Methodology · Chapter 2.0

Thematic analysis

Braun & Clarke's six phases as they're actually practised: with the codebook drift, the reviewer-2 anxiety, and the decisions you defend on the way to a finding.

12 min read · Updated May 2026

In this chapter

What thematic analysis is (and isn’t)
Braun & Clarke's six phases
Codes versus themes
Building a defensible codebook
Reflexive TA vs codebook TA
Intercoder agreement (when it matters)
Further reading

What thematic analysis is (and isn’t)

Thematic analysis (TA) is a method for identifying, organising, and interpreting patterns of meaning across qualitative data. Braun and Clarke’s 2006 article in Qualitative Research in Psychology is the canonical reference; it has been cited well over 200,000 times, which is a clue to both its usefulness and the trouble that comes with that usefulness.

The trouble is this: TA is often picked up as a default method rather than chosen, and presented in methods sections as “we did thematic analysis” without the theoretical orientation that makes the analysis defensible. Braun and Clarke have spent the years since 2006 trying to fix that. Their 2021 conceptual paper distinguishes reflexive TA, codebook TA, and coding reliability TA — three different methods that share a name and are not interchangeable (Braun & Clarke, 2021).

Before the six phases, the choice that matters most is which TA you’re doing. The phases are similar across variants; the epistemology is not. If a reviewer asks why your codebook didn’t go to two coders, the answer — “because this is reflexive TA, where the researcher’s interpretation is the analytic instrument” — is a defensible answer. “We forgot” is not.

Braun & Clarke’s six phases

The phases are not linear. They are recursive. You will go back to phase 2 after starting phase 4, and that’s the work, not a failure of process. Treat the numbered list as a description of what activity dominates at each point.

1. Familiarisation

Read the transcripts. Read them again. Write a one-page summary of each one before any coding. The familiarisation phase is the only phase where it is acceptable to know nothing and write nothing analytical — you are loading the corpus into your head. Skipping it makes coding faster and the analysis weaker, because every code becomes a guess about a transcript you don’t fully remember.

2. Generating initial codes

Apply short labels to data extracts that strike you as analytically meaningful. Codes at this stage are descriptive (“mother as primary carer”) or in vivo (“I had to be someone else”). Don’t worry about consistency yet — that’s phase 5’s job. Worry about coverage. If you finish a transcript and have only used three codes, you are probably not coding finely enough.

3. Searching for themes

Group codes into candidate themes — clusters of codes that say something coherent about the data. This is where TA shifts from descriptive to interpretive. A theme is not a topic (“family relationships”); it is an argument the data is making (“family relationships are reframed after a caregiving role ends”). If your theme would survive being rewritten as a research-question heading, it’s probably a topic, not a theme.

4. Reviewing themes

Test each candidate theme against (a) the coded extracts it’s built from, and (b) the full dataset. Themes that don’t hold up at (b) get demoted, merged, or split. You will discover at this phase that some of your early codes were really sub-codes of a more interesting pattern, and a theme you assumed was central turns out to be a sub-theme of something else.

5. Defining and naming themes

Write a two-to-three-sentence definition of each theme. If you can’t, the theme isn’t one theme. Pick names that do analytic work — “the interrupted self” tells a reader what they’re about to read; “identity issues” tells them nothing they didn’t already assume.

6. Producing the report

Write up. The mistake at this phase is treating the report as a separate, post-analytic activity. It isn’t. Writing surfaces ambiguity, exposes themes that don’t hold together, and forces decisions you postponed. Expect to return to phases 4 and 5 mid-write-up. The final theme structure often stabilises the week the methods section gets drafted.

“Thematic analysis should be seen as a foundational method for qualitative analysis. It is the first qualitative method of analysis that researchers should learn, as it provides core skills that will be useful for conducting many other forms of qualitative analysis.”
— Braun & Clarke, 2006

Codes versus themes

The most-confused distinction in TA: a code is a label applied to a data extract; a theme is an analytic claim about a pattern that runs through codes. Codes are the unit of segmentation. Themes are the unit of interpretation. A study can have 80 codes and 4 themes, and that is a typical, not a suspicious, ratio.

The Braun and Clarke update on this in 2021 was sharper than it sounds: themes are not “found” in the data; they are generated by the analyst from coded extracts. The shift in language matters for two reasons. First, it removes the false promise that two analysts coding the same dataset will arrive at the same themes — they should not, if interpretation is doing real work. Second, it forces the methods section to take responsibility: it’s not that the themes emerged, it’s that you wrote them.

The practical implication: in QualCanvas, codes are stored objects; themes live in the canvas as the spatial groupings you draw between codes. The codebook is not the analysis. The codebook is the working inventory that the analysis is built from.

Building a defensible codebook

A codebook is the durable record of every code applied to the dataset, with its definition and inclusion/exclusion criteria. It is a methodological artefact, not a deliverable. A defensible codebook has three properties.

First, code definitions are specific enough to apply. “Caregiving” is a topic, not a code definition. A code definition that works is: “Direct reference to providing care for another person, including unpaid family care, paid care work, and the negotiation of care responsibilities. Excludes generic discussion of care systems without a specific care relationship.” That definition lets you, six weeks from now, decide whether a passage about an aunt’s end-of-life arrangements gets the code.

Second, the codebook records change over time. Codes get merged. Codes get split. Codes get retired. A codebook that looks the same at the end of analysis as at the start is a codebook that wasn’t doing analytical work. Keep a short version history alongside the definitions — what changed and why. Reviewer 2 will sometimes ask for this, and even if they don’t, having it disciplines your own analysis.

Third, the codebook is exported with the paper. Most journals now accept a codebook as supplementary material. Treat that as the bar. A codebook with definitions, frequencies, and exemplar extracts is the qualitative equivalent of releasing your dataset — not perfectly transparent, but transparent enough that a reader can interrogate your interpretive moves.

QualCanvas exports the codebook to CSV with definitions, applied-span counts, and per-code exemplar extracts. The export goes into the supplementary materials folder. The version history is in the canvas history; you don’t need to maintain it by hand.

Reflexive TA vs codebook TA

Reflexive TA (Braun & Clarke, 2019, 2021) treats the analyst’s subjectivity as the analytic resource, not the analytic problem. There is, deliberately, no second coder. Themes are developed by one researcher (or a small team operating as one interpretive voice) and the validity of the analysis rests on the depth of engagement and the transparency of the interpretive reasoning.

Codebook TA (Boyatzis, 1998; Guest, MacQueen & Namey, 2012; King, 2004) builds the codebook collaboratively, applies it consistently across the dataset, and often reports intercoder agreement. The analytic stance is closer to a small-scale qualitative content analysis; the goal is replicable coding of a defined construct space.

The two approaches answer different research questions. If your question is “how do recent graduates narrate the transition from caregiving back to academic work?” that’s a reflexive-TA question; the analytic instrument is the analyst’s reading of the narrative. If your question is “what proportion of NHS staff reports specific categories of moral distress?” that’s a codebook-TA question, possibly with intercoder reliability reporting.

Pick the variant before you start coding and name it in the methods section. The single most common methods-paper mistake in TA is doing codebook-style coding (multiple coders, agreement statistics) and calling it reflexive TA, or doing reflexive coding (single researcher, deep interpretation) and apologising for the lack of a second coder. Pick, defend the choice, move on.

Intercoder agreement (when it matters)

A standing argument in qualitative methods: should you report intercoder reliability for TA? The honest answer depends on which TA you’re doing. Chapter 5 of this guide goes into the statistics; the summary here is methodological.

For reflexive TA, intercoder reliability is not just unnecessary; it is conceptually incoherent. The analytic instrument is the analyst’s interpretive engagement. Demanding two analysts produce the same themes is demanding the instrument behave like a different instrument. McDonald, Schoenebeck and Forte (2019) make a useful argument that defaulting to κ across all qualitative research imposes a positivist standard on interpretive work that doesn’t fit.

For codebook TA, intercoder reliability is defensible and sometimes expected — particularly in health-services research, in survey-derived qualitative data, and where the codebook is intended to be applied by future analysts. Cohen’s κ above .70 is the conventional minimum; Krippendorff’s α is more flexible across coder counts and missing data.

The chapter-5 take: pick the agreement statistic that matches the question, report it transparently, and don’t use a κ above .70 as a substitute for showing that your codes are doing analytical work. A high κ on trivially-defined codes is not rigour; it’s just two people agreeing on the obvious.