Thematic analysis is a method for identifying, organizing, and interpreting patterns of meaning, called themes, across a body of qualitative data such as interviews, focus groups, or open-ended survey responses. It is the most widely taught approach to analyzing primary qualitative data because it is flexible, theoretically open, and learnable, yet that same flexibility is why a weak thematic analysis reads as a list of quotations rather than an argument. Doing it well means treating coding and theme development as a disciplined, auditable process, not an intuitive summary.
The most common beginner error is to mistake a topic for a theme. A topic is a subject the data touch on, for example "workload." A theme is a pattern of shared meaning organized around a central concept, for example "workload as a threat to professional identity." A theme makes a point; a topic merely names an area. Strong thematic analysis is the work of moving from the things people talked about to what those things mean together. This is also what distinguishes primary thematic analysis from a qualitative evidence synthesis, which combines findings reported across many published studies rather than coding raw transcripts you collected yourself.
The six phases of Braun and Clarke
The reference framework, from Braun and Clarke, lays out six recursive phases. They are not a strict assembly line; you move back and forth, but each phase has to be done.
- Familiarization. Read and re-read the data, and ideally transcribe it yourself, until you know it intimately. Note first impressions.
- Generating initial codes. Work systematically through the entire dataset, labeling features of the data that are interesting and relevant to your question. A code is a concise label for a segment of meaning.
- Searching for themes. Sort codes into candidate themes, collating the data extracts that belong to each. This is where codes become a structure.
- Reviewing themes. Check candidate themes against the coded extracts and against the full dataset. Themes that do not hold together are split, merged, or discarded.
- Defining and naming themes. Write a short definition for each theme that states its scope and what it contributes to the analysis. If you cannot define a theme in a sentence, it is not yet a theme.
- Producing the report. Weave the themes into an analytic narrative, using data extracts as evidence for interpretive claims, not as a substitute for them.
Inductive thematic analysis builds themes from the data with no predetermined frame, which suits exploratory questions and under-studied topics. Deductive thematic analysis codes the data against an existing theory or framework, which suits questions where prior work gives you concepts to test. Most real projects are hybrid, but you should declare your dominant orientation up front because it changes how you code and what counts as a theme. Settling the orientation alongside a sharp research question, which our research question generator can help you sharpen, prevents the drift that turns an analysis into an unfocused summary.
Semantic and latent coding
A second choice is the level at which you code. Semantic coding stays close to what participants explicitly said. Latent coding interprets the underlying ideas, assumptions, and meanings beneath the surface. Latent analysis is more theoretically ambitious and more demanding to justify, because the reader needs to see how you reached an interpretation the data did not state outright. Neither level is superior; the right choice follows your research question and epistemology, the same way a well-structured question shapes the rest of a study.
Reviewers no longer accept "themes emerged" as a method. Demonstrable rigor in thematic analysis rests on a few practices: keeping an audit trail of coding decisions, maintaining a codebook that defines each code, using reflexivity to document how your own position shaped interpretation, and, where appropriate, involving a second coder and reporting how disagreements were resolved. Software such as NVivo or Atlas.ti does not analyze the data for you, but it does make the audit trail, the codebook, and the retrieval of every extract under a code far more manageable, which is why structured qualitative work increasingly runs through a qualitative data analysis support when the dataset is large or the stakes are high.
The two are often confused. Content analysis typically counts the frequency of predefined categories and can be largely quantitative. Thematic analysis is interpretive and does not reduce meaning to counts; a theme matters because of its significance to the research question, not because it appeared most often. Choosing between them, and integrating qualitative findings with quantitative results in a mixed methods design, depends on whether your question is about how common something is or about what it means.
The biggest source of confused method sections is the assumption that thematic analysis is one method. Braun and Clarke now describe three distinct families, and which one you are doing changes what counts as good practice. Coding reliability approaches (associated with Boyatzis and with Guest) treat themes as categories that exist in the data and use a structured codebook plus multiple coders and an agreement statistic to demonstrate that the themes are reliably present. Codebook approaches (such as framework analysis and template analysis) also use a structured, often early codebook but keep a qualitative, interpretive orientation. Reflexive thematic analysis, the version their famous six phases actually belong to, treats themes as analytic outputs that the researcher actively develops, not nuggets waiting to be found. Naming your family is not academic etiquette; it tells the reviewer which standards your study should be judged against, and applying the wrong family's standards (demanding a kappa from a reflexive study, or treating a reflexive codebook as fixed) is a genuine methodological error.
Why "themes emerged" and a second coder can both be wrong
In reflexive thematic analysis two habits imported from quantitative research are not just unnecessary but conceptually mismatched. The first is the passive phrase that themes emerged from the data: Braun and Clarke argue this denies the interpretive work you did and misrepresents themes as objective facts you merely transcribed. The second is using inter-rater reliability, a second coder and a Cohen's kappa, as a validity check. If a theme is a meaning you constructed through engagement with the data and your theoretical lens, then two coders agreeing does not make it more true; it only shows two people were trained to see the same thing. A second analyst can still enrich a reflexive analysis by deepening interpretation, but as a collaborator, not as a reliability instrument. By contrast, in a coding-reliability or codebook design, intercoder agreement is exactly the right credibility anchor. The point is to match the quality practice to the approach, not to apply one checklist everywhere.
What a theme actually is, and the domain-summary trap
The earlier contrast between a topic and a theme has a more precise diagnostic. A fully realised theme is organised around a central organising concept, a single idea that gives the theme its coherence and that you could state in a sentence. The common failure is the domain summary: a "theme" that is really just a bucket for everything participants said about a question (for example a theme called "barriers to care" that simply collects every barrier mentioned). Domain summaries describe the data; themes interpret it. A quick test is whether your theme names a shared meaning or merely a question from your interview guide; if it mirrors the guide, you have summarised a domain rather than built a theme.
Sample size, saturation, and the reflexive position
Reviewers often ask how you justified your sample size or whether you reached saturation, and for reflexive thematic analysis the honest answer is more nuanced than a number. Braun and Clarke have argued that data saturation is conceptually incoherent for an approach where meaning is generated rather than discovered, because there is always more interpretation to be made. The better framing is information power (Malterud and colleagues): the more relevant information your sample holds for the specific study (a narrow aim, a dense sample, strong dialogue, a clear theory), the fewer participants you need. State your sample size in those terms, and report your theoretical positioning explicitly, whether you analysed from a realist or essentialist stance that takes accounts at face value, or a constructionist one that treats them as produced in a context, because that stance governs what your semantic or latent codes are entitled to claim. Documenting reflexivity across its personal, interpersonal, methodological, and contextual dimensions is what turns a defensible position into a transparent one.
Thematic analysis is learnable, but a defensible analysis of forty in-depth interviews is weeks of disciplined work, and supervisors and reviewers scrutinize qualitative rigor closely. If your timeline is tight or the analysis has to withstand a methods-savvy examiner, expert support on coding structure, intercoder reliability, and the analytic write-up is often the difference between a thin description and a publishable contribution.
