Table of Contents
Most people don’t fail at Braun and Clarke thematic analysis because they’re careless. They fail because they treat it like a sorting exercise: highlight quotes, assign labels, bundle similar labels, done. That produces tidy code piles and weak analysis. Reflexive thematic analysis is not a mechanical path from transcript to truth; it’s an interpretive method where your judgment is the instrument.
I’ve supervised enough dissertation students and UX researchers to spot the pattern early. The ones who struggle usually have hundreds of coded excerpts and no argument. The ones who do strong work understand something Braun and Clarke made explicit in 2006: themes are actively developed, not passively discovered.
The biggest mistake is assuming the method lives or dies in Phase 2 coding. It doesn’t. Coding matters, but reflexive TA is not “code everything, count frequency, then report what came up most.” That logic belongs to a very different qualitative tradition.
Braun and Clarke 2006 became the most-cited qualitative methodology paper partly because it gave researchers a flexible, usable framework without pretending analysis is objective extraction. That was a breakthrough. It gave psychologists, health researchers, dissertation students, and later UX teams a way to do rigorous qualitative analysis without forcing data into grounded theory or thin content analysis.
The paper also got popular for a less flattering reason: people cite it while ignoring its philosophy. They say “Braun and Clarke thematic analysis” when what they actually do is codebook TA with inter-rater reliability, predefined categories, and a search for consensus. That can be a valid approach in some projects, but it is not the same thing as reflexive thematic analysis.
I once reviewed a master’s dissertation on mental health app adoption with 18 interviews and a 42-page appendix of codes. The student had three coders, Cohen’s kappa scores, and 11 “themes” that were basically topic buckets like “privacy,” “cost,” and “features.” The problem wasn’t effort. The problem was that the analysis never answered how participants made sense of trust, vulnerability, and self-monitoring. It described content; it didn’t interpret meaning.
Reflexive thematic analysis treats the researcher’s subjectivity as a resource, not a bias to eliminate. You engage with data, make analytic choices, and reflect on how your standpoint shapes what becomes visible. That is the defining philosophical difference from codebook TA.
In codebook TA, researchers often aim for coding consistency across team members, use more structured code definitions early, and may work with a fixed analytic framework. In reflexive TA, codes can evolve substantially, themes are generated through interpretation rather than clustering alone, and disagreement between analysts is not a reliability problem to eliminate but evidence that meaning is not self-evident.
If you’re writing a dissertation, this matters because your examiner will often ask whether your method and your epistemology match. If you say you used Braun and Clarke thematic analysis but then emphasize inter-coder agreement, fixed coding rules, and saturation as category completeness, you’ve mixed paradigms. That’s one of the fastest ways to make a methods chapter look confused.
Here’s the clean distinction I give students:
Neither is automatically better. But if you are invoking Braun and Clarke’s reflexive model, own the interpretive stance. Don’t borrow the name and then run a quasi-positivist coding audit.
If you’re still deciding whether thematic analysis is even the right method, compare it with other approaches before you commit. Usercall has a useful breakdown of grounded theory vs thematic analysis, and I recommend students read that before locking their methodology chapter.
Braun and Clarke describe six phases, but calling them “steps” can mislead people. You do not march through them once. You move back and forth, revise your codes, collapse themes, split them, and rewrite your analysis as your interpretation sharpens.
That said, dissertation students need something concrete. So here is how I teach the 6 steps of thematic analysis in a way you can actually use under deadline pressure without flattening the method into a checklist.
Familiarization is not admin work. It is your first round of analysis. If you only read transcripts for accuracy or summarize each interview in broad terms, you miss the point.
Read each transcript in full at least once, ideally twice. On the first pass, mark anything that feels emotionally charged, contradictory, repeated, or surprising. On the second pass, write margin notes about patterns in meaning, not just topics. Ask: What assumptions are participants making? What problem are they trying to solve? What tension sits underneath what they say?
For dissertations, I tell students to create a familiarization memo after every 3–5 interviews. One page is enough. Capture early hunches, recurring language, and your own reactions. Those memos become gold later when you need to justify how your themes developed.
In a B2B SaaS onboarding study I ran with a five-person product team, we had only 12 interviews and a brutal two-week synthesis window before roadmap planning. The junior researcher wanted to jump straight into coding. I forced the team to spend half a day writing familiarization memos first. That’s where we noticed users weren’t merely “confused by setup.” They felt abandoned at the exact moment they were expected to prove value internally. That reframed the entire analysis.
Coding in reflexive thematic analysis is about identifying features of the data that matter to your research question. Good initial codes are useful handles, not final answers. They can be semantic, more explicit in the data, or latent, capturing underlying assumptions or meanings.
At this stage, code generously. If an excerpt can plausibly speak to multiple meanings, code it multiple ways. Don’t force yourself to pick the “right” label too early. Early coding should expand interpretive options, not narrow them.
For dissertation work, a practical rule is to code in chunks of meaning rather than sentence-by-sentence atomization. Over-fragmented coding destroys context. Under-coded transcripts leave you with vague categories that don’t travel into strong themes.
If you need a stronger coding workflow, Usercall can help on the operational side. It runs AI-moderated interviews, handles transcription, and produces research-grade initial qualitative analysis so you aren’t buried in admin before the real interpretive work starts. I like it most when a team needs to collect dozens of interviews quickly but still wants deep researcher control over prompts and probes.
If you want a deeper coding primer, Usercall’s guide on how to create a codebook for qualitative research is useful, especially if you need to understand where codebooks fit and where reflexive TA deliberately stays looser.
Themes are not summaries of what participants mentioned. A real theme explains a patterned way of making sense of something important in relation to your research question. Topic buckets like “pricing concerns” or “navigation issues” are often only the starting point.
In Phase 3, look across your codes and ask what broader story they might be telling together. Which codes seem to share a central organizing concept? Which seem related only because they concern the same feature or event? If you can’t state the unifying meaning in one sentence, you probably don’t have a theme yet.
In Phase 4, review potential themes against both the coded extracts and the full dataset. This is where weak themes die, and that’s healthy. You are checking whether the theme is coherent internally, distinctive from other themes, and genuinely supported by the data rather than by your wishful thinking.
I often tell students to test each candidate theme with three questions:
One PhD student I supervised was studying remote therapy platforms with 22 interviews. She had a candidate theme called “technical issues,” built from excerpts about lag, audio problems, and login friction. After review, we killed it as a theme and repositioned those excerpts across two stronger themes: “therapy feels fragile when the medium breaks” and “users blame themselves before they blame the platform.” That move transformed a bland findings chapter into an interpretive one.
A vague theme name is usually evidence of vague thinking. If your themes are called “Challenges,” “Benefits,” or “User Perceptions,” you have not finished analyzing.
In Phase 5, write a short analytic paragraph for each theme before you write the full results section. State what the theme is, what it captures, what is interesting about it, and how it relates to the overall story of your dataset. Then name it in a way that conveys that argument.
Strong theme names usually do one of three things: they identify a tension, articulate a process, or reveal an underlying logic. “From setup to self-doubt” is stronger than “onboarding challenges.” “Delegated trust breaks at the handoff” is stronger than “customer support issues.” The name should do analytic work.
This is also where reflexivity needs to be explicit. Why did you see this pattern as salient? What assumptions from your disciplinary background, product context, or social position shaped your reading? Reflexivity does not mean endless confession. It means making your analytic lens visible enough that readers can understand how interpretation happened.
The write-up is not a dump of quotes under subheadings. It is where you show that your themes are analytically robust, grounded in data, and connected to your research question and literature.
Each theme section should do three jobs. First, introduce the central claim of the theme. Second, present carefully chosen extracts that illustrate both the pattern and its nuance. Third, interpret those extracts rather than leaving quotes to speak for themselves.
For a dissertation, that usually means 2–4 themes, not 9 or 10. If you have too many themes, you probably have categories rather than themes. Depth beats breadth every time.
When students ask how many quotes to include, my answer is simple: enough to demonstrate the pattern, the variation inside it, and your interpretive reasoning. Usually that’s 2–4 strong excerpts per theme, sometimes more if participants are meaningfully divergent. Don’t pad. A wall of quotation is often a substitute for analysis.
Let’s make this concrete with a realistic UX research scenario. Imagine you are studying why users abandon a budgeting app during the first week. You conduct 15 semi-structured interviews with new users who signed up, connected at least one bank account, and then became inactive within 7 days.
Your research question is not “what features do people like?” It is: how do new users experience the first-week setup and what meanings shape early abandonment?
Notice what happened. We did not create a theme called “notifications” or “categories.” We asked what patterned meaning linked multiple excerpts. The answer was not about a feature. It was about users experiencing the product as evaluative and shaming at the moment it was meant to create confidence.
A second theme in the same dataset might emerge from excerpts like: “I didn’t know what to do first,” “there were too many options,” and “I assumed if I set it up wrong, the insights would be useless.” Those could support a theme such as “Early choice overload makes competence feel unattainable.”
This is the jump many students miss. Codes describe pieces; themes explain patterns of shared meaning. If your “themes” still read like feature lists, go back.
When you need participants at the exact moment of friction, not three weeks later when memory has gone soft, Usercall is particularly good. You can trigger user intercepts around key product analytics moments, like onboarding drop-off or activation failure, and capture the “why” behind the metric while the experience is still fresh. That’s a massive advantage for thematic analysis in product environments.
The errors I see most often are not about formatting or software. They’re about misunderstanding what the method is trying to do.
Saturation deserves special attention because students get bad advice here. In reflexive thematic analysis, the goal is not to exhaust every possible code in the universe. The goal is to develop a rich, credible, and useful interpretation of patterned meaning in a bounded dataset. I have seen excellent dissertation chapters built from 12 interviews and weak ones built from 45.
If you are early in study design and still choosing how to collect your data, read Usercall’s guide to qualitative data collection methods. Better analysis starts with better input, and too many thematic analysis problems are actually recruitment and interview design problems in disguise.
Thematic analysis with AI is useful only if AI accelerates the clerical work without pretending to replace interpretation. That’s my blunt view after testing a lot of tools. Most fail because they promise automatic themes, which tempts researchers into accepting plausible summaries instead of doing analysis.
The right use of AI in reflexive thematic analysis is narrower and more valuable. Use it to collect more interviews faster, transcribe accurately, surface candidate codes, group relevant excerpts, and retrieve contradictory cases. Then do the real work yourself: deciding what matters, constructing themes, and writing the analytic story.
This is where Usercall stands out. It runs AI-moderated interviews with deep researcher controls, so you can scale interviews without reducing them to rigid surveys. In practice, that means you can define the interview structure, shape probing behavior, and collect consistent yet still conversational data across dozens or hundreds of participants.
For dissertation students, the gain is speed without total loss of depth. For UX teams, the gain is even bigger: you can intercept users at key behavioral moments, gather fresh narrative data, and get research-grade qualitative analysis at a scale that would normally require an agency or a large internal team. That’s exactly the kind of setup where Braun and Clarke thematic analysis becomes more feasible, not less, because you have richer data and less operational drag.
I’d still caution against one thing: don’t let AI-generated code suggestions harden into a false codebook too early. Treat them as prompts, not verdicts. Keep reflexive memos, revise your coding as your interpretation changes, and make your positionality visible. AI can speed the pipeline, but it cannot be reflexive for you.
If you specifically need tooling for academic workflows, Usercall also has a practical guide to the best thematic analysis tool for dissertations in 2026. I’d point students there if they want help comparing software without drifting into feature-shopping for its own sake.
The bottom line is simple. Braun and Clarke thematic analysis remains the dominant entry point to qualitative analysis because it is flexible, teachable, and intellectually honest about interpretation. But it only works well when you stop chasing procedural certainty and start doing analytic thinking. The 6 steps of thematic analysis are useful scaffolding. Reflexive judgment is what turns them into good research.
Related: How to Create a Codebook for Qualitative Research (and Turn Codes Into Themes) · Grounded Theory vs Thematic Analysis: Which Should You Use and When? · Qualitative Data Collection Methods: How to Choose the Right Approach for Your Research · Best Thematic Analysis Tool for Dissertations in 2026
Usercall helps you run AI-moderated user interviews that generate qualitative insight at scale without flattening the conversation. If you want faster transcription, smarter initial coding, and product-triggered interview intercepts that capture the “why” behind user behavior, Usercall is the research workflow I’d put in front of both dissertation students and lean UX teams.
