Thematic analysis looks simple from the outside: read your interviews, find the themes, write them up. In practice, most weak qualitative papers fail in the same few places. Their "themes" are just summaries of what people said, they report that themes "emerged", or they mix methods that don't belong together.
The most widely followed version is Virginia Braun and Victoria Clarke's. Their 2006 paper, "Using thematic analysis in psychology", is one of the most cited academic papers of this century: a 2025 analysis reported by Nature placed it third. They have refined the method since, calling it reflexive thematic analysis to stress the researcher's active role. This guide follows their current guidance and works through each phase with an example.
First, which thematic analysis?
"Thematic analysis" is not one method. Braun and Clarke distinguish three broad families, and much confusion in published work comes from mixing them. Decide which you're using before you start.
| Reflexive TA | Codebook TA | Coding reliability TA | |
|---|---|---|---|
| Examples | Braun and Clarke | Template analysis, framework analysis | Boyatzis; Guest and colleagues |
| Coding | Open and evolving, done by the researcher | Structured codebook, often developed early | Fixed codebook applied by several coders |
| Themes are… | Outputs, built from codes | Often inputs, set up before or early in coding | Inputs, which coding looks for evidence of |
| Inter-rater reliability | Not used | Not usually | Central (e.g. Cohen's kappa) |
| Researcher subjectivity | A resource | Acknowledged | Something to control |
The rest of this guide covers reflexive TA. If your supervisor or journal expects agreement scores, you're being asked for coding reliability TA, which is a different method with different assumptions. Say which one you used, and don't mix them.
Four terms you need
- Code: a short label for one idea in a specific segment of data, relevant to your question. Codes are the building blocks.
- Theme: a pattern of shared meaning across the dataset, organised around a central organising concept, the one core idea that ties it together.
- Subtheme: one notable facet of a theme that shares its central concept. Use sparingly.
- Domain summary: a summary of everything participants said about a topic. It has a shared topic but no shared meaning. It is not a theme in reflexive TA.
Can you state its central organising concept in one sentence? Theme names like "Experiences of X" or "Benefits of Y" are warning signs: they name an area of the data without saying anything about it.
The six phases, with a worked example
To make the phases concrete, we'll follow a small, invented study. Research question: How do first-year doctoral students experience written feedback from their supervisors? The data are twelve semi-structured interviews.
| Phase | 2006 label | Current reflexive TA label |
|---|---|---|
| 1 | Familiarizing yourself with your data | Familiarisation |
| 2 | Generating initial codes | Coding |
| 3 | Searching for themes | Generating initial themes |
| 4 | Reviewing themes | Developing and reviewing themes |
| 5 | Defining and naming themes | Refining, defining and naming themes |
| 6 | Producing the report | Writing up |
The change from "searching for" to "generating" themes matters: themes aren't hidden in the data waiting to be found. You build them. The phases also aren't strictly sequential; expect to loop back.
Phase 1: Familiarisation
Read every transcript, more than once, and listen to the recordings if you have them. Make brief notes on what strikes you, both in each interview and across the set. Don't code yet.
In our example, early notes might read: "Several mention avoiding feedback for days. Strong emotion around one-word comments. Meetings seem to repair things. Lots of comparison with friends' supervisors."
Phase 2: Coding
Work systematically through the whole dataset, giving each data item equal attention. Label anything relevant to your question. Codes can be semantic, close to what was said, or latent, capturing an underlying idea. Expect your codes to change as you go.
| Extract (invented) | Code |
|---|---|
| "I opened the comments and just closed the laptop for two days." | Avoiding feedback after receiving it |
| "She wrote 'unclear' next to half my paragraphs. Unclear how?" | Feedback without direction |
| "I assumed every comment meant I was failing." | Reading critique as a verdict on ability |
| "Once she explained it in a meeting it made sense." | Talking it through restores meaning |
| "My friend in another lab gets track changes and a call. I get a PDF." | Comparing supervision with peers |
| "I didn't want to ask what she meant in case it looked stupid." | Not asking, to protect how I'm seen |
Notice that "Reading critique as a verdict on ability" and "Not asking, to protect how I'm seen" are latent codes. They interpret what's said, rather than restating it.
Phase 3: Generating initial themes
Collate your codes and look for clusters that share a meaning, not just a topic. Draw a thematic map if it helps. At this stage everything is provisional. In the example, three candidate themes form:
- Codes about avoiding feedback, reading it as a verdict, and not asking questions cluster around self-protection.
- Codes about vague comments and meetings that restore meaning cluster around what makes feedback usable.
- Codes about comparing with peers cluster around judging supervision against others.
Phase 4: Developing and reviewing themes
Check each candidate theme against its coded extracts, then against the whole dataset. Does it hold together? Is it distinct from the others? Is there enough data to support it? Expect to merge, split or discard.
In the example, "judging supervision against others" turns out to be thin: a few vivid comments from three participants. Its codes are folded into the other themes, where they add to the analysis of what students expect. The remaining two themes are reshaped and checked again.
Phase 5: Refining, defining and naming themes
Write a short definition of each theme stating its central organising concept, then give it a name that says something. Compare a domain-summary name with a theme name:
| Domain summary name | Theme name | Central organising concept |
|---|---|---|
| Students' reactions to feedback | "In case it looked stupid": feedback as a threat to belonging | Students read critique as a judgment of whether they belong in a PhD, and protect themselves by avoiding it and not asking |
| Types of feedback | Comments that need a conversation | Written feedback becomes usable only when its meaning is negotiated in person |
Phase 6: Writing up
Writing is part of the analysis, not a report of it. For each theme, build an analytic narrative: say what the pattern is, show it with well-chosen extracts, and say what it means in relation to your question and the literature. Aim for a balance between analysis and quotation. A results section that's mostly quotes with a sentence between each is description, not analysis.
Descriptive: "Many participants said they found feedback upsetting and avoided reading it."
Analytic: "Avoidance was less about the content of comments than what they seemed to say about the student. Delaying, and not asking for clarification, protected a fragile sense of belonging, but also left comments unresolved, so the next round of feedback felt just as threatening."
For more on presenting findings, see our guides to the results section and writing a strong discussion.
Sample size and number of themes
Braun and Clarke give rough guidance on interview numbers, which depend on the scope of the project:
- 6–10Interviews for a small project, such as an undergraduate dissertation
- 10–20Interviews for a medium project, such as a master's dissertation
- 30+Interviews for a large project, such as a PhD
- 2–6Themes for an article, a dissertation or one analytic thesis chapter
They consider five interviews too few for thematic analysis, however detailed, because the method looks for patterns across data. They also note that some journals expect larger samples than these.
Mistakes reviewers flag most
- Paraphrase instead of analysis. Reporting what participants said without saying what it means.
- Themes that mirror the interview questions. If each theme matches one question you asked, you've summarized answers, not analysed patterns.
- "Themes emerged". In reflexive TA, you generated the themes. Say so.
- Too many quotes, or too few. Claims need evidence, and extracts need interpretation.
- Overlapping themes. Each theme should be distinct, and together they should tell a coherent story.
- Counting. "14 of 20 participants said…" suggests the others disagreed, when they may simply not have mentioned it. Braun and Clarke advise against frequencies in reflexive TA.
- Mixing approaches. Claiming reflexive TA and then reporting inter-rater reliability.
Software and AI
Qualitative data analysis software such as NVivo, ATLAS.ti or the free, open-source Taguette helps you store codes, collect extracts and see your codes across transcripts. It doesn't do the analysis. Many researchers manage well with a spreadsheet or a word processor.
AI tools are increasingly offered for qualitative analysis. They can help with transcription, and with finding every passage that touches an idea once you've identified it. But in reflexive TA the interpretation is the method. An AI's list of "themes" is usually a set of domain summaries, the very thing the method warns against. Two practical points as well:
- Ethics and consent come first. Uploading interview data to an external tool may not be covered by your ethics approval or participants' consent. Check before you do it, and de-identify the data.
- Disclose what you used. If AI played any part in coding or analysis, describe it in your methods. Our guide to what journals expect you to disclose covers the rules.
Where LitraMind fits is the writing. Once your analysis is done, you can draft your findings and discussion in one place, use Chat with Files to find passages in approved, de-identified transcripts with page references, and use AI Edit to tighten the write-up while keeping your interpretation intact.
Checklist
- You've said which kind of thematic analysis you used, and you've stayed consistent with it
- Every data item got equal attention in coding
- Each theme has a central organising concept you can state in one sentence
- Theme names say something, not just "Experiences of…"
- Themes don't simply mirror your interview questions
- Extracts illustrate the analysis, and the analysis interprets the extracts
- You describe yourself as generating themes, not finding them
- Any AI or software use is covered by your ethics approval and described in your methods
