Braun and Clarke's six-phase approach to thematic analysis is probably the most cited qualitative method in the English-speaking world. It is also the most misapplied. The usual failure is not sloppiness — it is treating the six phases as a checklist to be completed rather than a recursive process to be moved through in both directions.
This article walks the six phases, marks the places where analyses typically go wrong, and is honest about which parts of the work a machine can genuinely help with.
First: which thematic analysis are you doing?
Braun and Clarke have been clear that their approach is reflexive thematic analysis, and they have pushed back on versions that treat coding as a mechanical, reliability-driven exercise. Themes are understood as patterns of shared meaning that the researcher actively develops — not objects lying in the data waiting to be discovered.
This matters for tooling. If your framing is reflexive TA, the interesting question is never "did the software find the right themes?" It is "did the software help me see the material thoroughly enough to develop them myself?" Those are very different tests, and the second one is the honest one.
Phase 1 — Familiarising yourself with the data
Read everything. Then read it again, making notes. If you transcribed the interviews yourself, you have already started; if someone else did, budget real time here.
Where this goes wrong: skipping straight to coding because the deadline is close. Every later phase is weaker for it, and it shows in the write-up as themes that sit oddly against the data.
Can a tool help? Not really, and be suspicious of anything claiming otherwise. This phase is about you building a mental model. A summary you did not produce yourself does not do that.
Phase 2 — Generating initial codes
Work systematically through the entire dataset, giving each interesting segment a label. Codes at this stage are meant to be numerous, messy and overlapping. Twenty codes across a full dataset is usually a sign you have jumped ahead to themes.
Where this goes wrong: coding only what is relevant to the research question. You lose the material that would have complicated your account — which is exactly the material that makes an analysis convincing.
Can a tool help? Yes, and this is the phase where it helps most. Systematically working through every segment and proposing labels with verbatim examples is mechanical, exhausting and highly automatable. The critical requirement is that every proposed code comes with the exact quote that produced it, so you can check it rather than trust it.
Phase 3 — Searching for themes
Sort codes into candidate themes. A theme is not a topic summary; it captures something meaningful about the data in relation to your question, organised around a central concept.
Where this goes wrong: the "bucket" theme. If a theme is called Communication and its summary is "participants discussed communication in various ways", that is a topic, not a theme. A real theme has a point of view — Communication breaks down at shift handover.
Can a tool help? Partly. It can propose groupings and show you which codes co-occur. But the judgement about what is meaningful is yours, and it is the actual intellectual work of the method.
Phase 4 — Reviewing themes
Two levels. First, does each theme cohere across its own extracts? Second, does the set of themes work against the full dataset? Themes get merged, split and discarded here — and going back to Phase 2 is normal, not a sign of failure.
Where this goes wrong: keeping a theme because you like it. If it rests on two extracts from the same participant, it is a case, not a theme, and it should be reported as such.
Phase 5 — Defining and naming themes
Write a short definition of each theme: what it captures and what it does not. If you cannot describe a theme in a couple of sentences without listing sub-points, it is probably two themes.
A useful test: could a colleague apply your definitions to a fresh transcript and reach broadly similar conclusions? Under reflexive TA this is not a reliability metric to be reported — Braun and Clarke are explicit that it is not — but it remains a good check on whether your definitions are actually clear.
Phase 6 — Producing the report
Extracts must be embedded in an analytic narrative, not stacked in lists. The quote illustrates the claim; it does not replace it.
Where this goes wrong: the results section that is eighty percent block quotes. If a reader can delete your sentences and lose nothing, you have transcribed rather than analysed.
What Themera actually does here
Being precise about the boundary is more useful than a pitch. Themera covers Phase 2 and the mechanical part of Phase 4: it works through every unit, proposes a codebook with definitions and verbatim anchor examples, applies that codebook consistently across the whole dataset, and shows coverage — including which units received no code at all, which is often the most informative output.
You then edit the codebook and re-run it. Phases 1, 3, 5 and 6 remain yours, and a tool that claimed otherwise would be selling you a problem, not a solution.
In short
The six phases are recursive, not sequential, and the mechanical portion — systematic coding of everything, consistently — is both the most time-consuming part and the part least dependent on your judgement. That is the part worth automating. The rest is the method.
See a worked example analysis with codebook, verbatim extracts and coverage, no account needed — or try it on your own data, three analyses free.