
TL;DR
Reflexive thematic analysis is a qualitative analysis method in which the researcher's interpretive judgment shapes how themes are constructed from data, rather than applying a fixed codebook.
Done right, it produces a detailed analysis stakeholders trust; a key principle of the method is that well-documented, traceable judgment is what makes findings hold up to scrutiny.
Most teams skip the reflexivity part, coding transcripts into labeled clusters and calling them themes: patterns that reflect what the researcher expected to find rather than what participants said.
This guide gives insights and CMI teams a practical framework for applying reflexive thematic analysis to AI-moderated qualitative data, including where the research process breaks down without human interpretation.
Reflexive thematic analysis rewards teams that treat interpretation as a discipline, not a shortcut. The sections below explain what the method is, when to choose it over codebook approaches, the six phases that structure it, and how AI-assisted coding can speed up the process without compromising the reflexivity it depends on.
What reflexive thematic analysis actually is
Reflexive thematic analysis is a qualitative method for identifying patterns of meaning across a dataset, where themes are actively constructed by the researcher through interpretive engagement rather than discovered in the data. Since Braun and Clarke's inaugural 2006 paper, their approach has become one of the most thoroughly delineated methods of thematic analysis, and their evolving guidelines, refined across several follow-up papers, have shaped how the method is taught and applied across the social sciences. What they eventually named reflexive thematic analysis, or RTA, is a specific philosophical position, a particular epistemological stance that any team applying it should recognize as such. Reflexivity is the method's central concept: the idea that the researcher's own perspective actively shapes what counts as a theme.

RTA is a non-positivist, "Big Q" approach that treats researcher subjectivity as a resource and rejects the notion that coding can ever be fully accurate, because meaning is not fixed within data. It also distinguishes between two levels of coding:
Semantic coding, which stays close to what participants explicitly said
Latent analysis, which digs into the underlying ideas and assumptions beneath the surface content, of particular interest to teams trying to understand why participants said something, and how they said it
This is where most teams go wrong. They describe their analysis as reflexive thematic analysis but run it like a coding reliability exercise: chasing inter-rater agreement, fixing code definitions early, and treating any disagreement between analysts as a problem to resolve. In genuine RTA, codes can evolve substantially, themes are generated through interpretation rather than clustering alone, and disagreement between analysts is treated as evidence that meaning is open to interpretation. Unlike traditional thematic analysis, which often assumes a single correct coding scheme, RTA treats coding as a rigorous interpretive process rather than a search for consensus.
Codebook approaches, such as framework or applied thematic analysis, combine some structured procedures for coding reliability with some values of RTA. They are legitimate traditions within qualitative content analysis, with different epistemological commitments and different theoretical assumptions about where meaning lives. In RTA, per Braun and Clarke, the researcher plays an active, interpretive role in theme development rather than pursuing inter-coder reliability. Codes and themes emerge through close engagement with the data and ongoing critical reflection, a form of deep engagement that the existing literature consistently treats as the method's defining strength.
For enterprise research teams, this distinction between codebook rigor and interpretive rigor has a practical consequence: RTA is rigorous in a different direction from codebook approaches, toward interpretive depth and theoretical coherence rather than procedural consistency. Choosing it without understanding that distinction produces analysis that satisfies neither standard, and it can quietly undermine the methodological integrity of the wider research context the study sits within.
When to choose reflexive thematic analysis
This is a methodological choice that should follow from four specific conditions:
What the research question is actually asking
What epistemological stance the team is working from
How the analysis team is structured
What the stakeholder audience needs from the output
Dimension | Reflexive TA | Coding Reliability TA |
|---|---|---|
Research question fit | Exploratory or interpretive questions ("what" or "how") | Testing existing theory or a known framework (deductive analysis) |
Epistemological stance | Constructivist; meaning is co-constructed | Positivist; inter-coder reliability scores |
Team setup | A single experienced analyst | Multiple coders working from a shared schema |
Stakeholder needs | Richer themes; a thematic framework built from verbatim evidence | Volume and pattern data; easier to quantify but shallower |
Research question fit
Reflexive thematic analysis belongs to exploratory or interpretive questions: the kind that begin with "what" or "how" rather than "how many." If a team is asking why a new product concept is landing differently across segments, reflexive TA is the right fit; the themes emerge from close engagement with what participants actually said, rather than being specified in advance. Codebook TA suits questions where existing theory or a known framework needs testing across a new dataset, a form of deductive analysis, such as verifying whether predefined brand associations hold in a new market. Framework analysis goes further, applying a structured matrix from the outset, which suits policy-adjacent or compliance-driven research where categories are fixed before fieldwork begins.
Epistemological stance
Reflexive TA treats the researcher's perspective as part of the analytic process. Teams working within a constructivist frame, where meaning is co-constructed, will find reflexive TA coherent with how they already think about qualitative inquiry. Teams whose stakeholders expect inter-coder reliability scores are better served by coding reliability TA or qualitative content analysis, a more systematic analysis closer to a positivist model.
Team setup
Reflexive TA is designed to function well with a single experienced analyst, whose deep engagement across multiple passes builds the interpretive depth, which is a practical advantage for enterprise teams running a qualitative study with one or two researchers. Coding reliability TA requires multiple coders working from a shared schema, adding coordination overhead that smaller teams may not have the capacity for.
Stakeholder needs
When findings reach brand, product, and executive audiences who weren't in the room during analysis, reflexive TA produces richer themes: a thematic framework built from verbatim evidence moves decisions. Content analysis produces volume and pattern data that is easier to quantify but often shallower in the explanatory layer stakeholders need.
The short version: choose reflexive thematic analysis when the question is genuinely open, the team has the interpretive expertise to conduct it honestly, and the stakeholder audience needs to understand what the data means.
The 6 phases of reflexive thematic analysis
Braun and Clarke's six phases give RTA its structure, but the framework is frequently misread as a checklist. The phases are better understood as a recursive process that researchers move through, returning to earlier stages as the analysis matures.

1. Familiarization
Immerse yourself in the data through repeated reading, re-watching the recordings, and note-taking to develop a felt sense of the entire dataset before imposing any analytical frame.
2. Generating initial codes
Labeling segments of coded data that are meaningful in relation to your research questions. This is the data coding stage: your coding process is interpretive from the start, an active analytical choice rather than a mechanical pass through the transcripts. Your theoretical positioning shapes what you notice.
3. Constructing candidate themes
Also known as generating initial themes or generating themes in Braun and Clarke's later work. Grouping all the codes into broader, provisional patterns and examining how different codes relate to and build on each other. These overarching themes and potential themes stay provisional until later phases confirm them. Expect to discard and rebuild them as new codes emerge, and the analysis develops.
4. Reviewing and developing themes
Testing whether candidate themes hold up against the entire dataset, including the hierarchical relationships between a theme and its sub-themes. A theme that fits twelve codes but contradicts forty others is not a theme, and it should survive review only if multiple codes across different participants support it. This is where the most substantive analytical work happens, and where researchers most often loop back to phase two or three. Reviewing themes properly means checking every theme against the data extracts that supposedly support it, beyond just the codes that first suggested it.
5. Refining, defining, and naming themes
Articulating precisely what each theme captures. Theme refinement continues until the theme definitions reflect the interpretive claim itself, rather than describing the data content.
6. Writing the analytic narrative
The final phase. Producing an account that weaves evidence and interpretation together. In RTA, the write-up is itself part of the analytical process, where meaning gets made and tested.
The sequence is recursive by design: moving from phase four back to phase one, or from phase six back to phase three, is exactly how RTA is meant to work.
The sections that follow cover how to put each phase into practice, how to report RTA findings to stakeholders, and how AI-assisted analysis can support the research process without collapsing the reflexive distance the method depends on.
Operationalizing reflexivity: What it looks like during coding
Reflexivity in commercial research is a structured habit: noting, at the point of coding, where your prior knowledge, stakeholder pressure, or category familiarity may be shaping what you see. A key principle here is that the reflexive insights generated during coding are as valuable as the themes themselves. The templates below are built for insights and CMI teams.
One thing shifts when fieldwork runs through AI-moderated interviews: with moderator variation largely out of the picture, a reflexive memo has less to account for at the data collection stage and more at the interpretation stage.
Positionality statement
Study-level, written before coding begins.
A commercial positionality statement is one paragraph. It names the researcher's relationship to the category, any hypothesis they entered with, and the business pressure that could pull interpretation in a particular direction. Making your theoretical assumptions explicit here is what gives the rest of the coding process methodological integrity. Here is a reusable template:
I am coding this study as a researcher with [X] years in [category]. My team entered fieldwork expecting [hypothesis]. The business is under pressure to validate [strategic direction]. I will flag any code where I notice myself gravitating toward data that supports that direction, and I will document counter-evidence as a separate memo before synthesis.
Write this before you open the first transcript. It takes three minutes and gives you a reference point to return to when a theme feels too clean.
Per-session reflexive note
Written after each coding pass.
After coding each transcript or batch, write a short note using these four prompts:
What surprised me in this session, and why?
What did I almost code differently, and what made me choose this label instead?
Where did I feel resistance to a participant's framing?
What would a researcher with no category experience have noticed that I may have filtered out?
Bringing a critical perspective to your own assumptions is the point of the exercise. Two to four sentences per prompt is enough. The purpose is to create a paper trail that separates your analytical decisions from the data itself, which matters when a stakeholder later asks why you weighted a theme the way you did.
Decision memo
Written when a coding choice is contested or uncertain.
When you merge two codes, rename a theme, or exclude a data point, write a decision memo: what you did, why you did it, and what you would need to see to reverse the decision. This is the single most useful document you can produce during analysis. The reflexive insights it captures answer stakeholder questions before they are asked, and give a future researcher the context to build on your work rather than relitigate it.
Teams that build these habits into their coding workflow often find synthesis moves faster because they document interpretive work as it happens rather than reconstructing it from memory at the reporting stage.
4 common failure modes in reflexive thematic analysis
The most persistent problems in reflexive thematic analysis share one root cause: treating analysis as a mechanical process rather than an interpretive one. Recognizing these failure modes early, before a set of potential themes hardens into a final report, is what separates findings that hold up under stakeholder scrutiny from findings that collapse the moment someone asks a follow-up question. The existing literature on qualitative research flags these same patterns again and again, suggesting they are structural rather than incidental.

1. Themes that mirror the discussion guide
When themes map directly onto the questions asked, the analysis has not moved beyond the data collection structure. A theme called "perceptions of price" tells you what was discussed. Genuine themes emerge from meaning the researcher constructs through interpretation. If your theme list looks like a reordered interview guide, the interpretive work has not yet started.
2. Confirmation bias in coding
Researchers who enter analysis with a working hypothesis often code toward it, attending to excerpts that confirm it and glossing over those that complicate it. In RTA, the researcher's perspective is a resource, but only when it is made explicit and critically interrogated. Coding without a reflexivity log makes this bias invisible until a stakeholder spots the gap.
3. Treating themes as topics
This is the most common failure mode in practice. "Customer service" is a topic. "Customers lower their expectations after the first bad experience" is a theme. A theme carries an argument. Thematic analysis helps stakeholders understand meaning precisely because it produces arguments rather than topic summaries; a topic list gives stakeholders a map of what was discussed rather than an understanding of what it means.
4. Missing the negative case
Themes gain credibility when they account for participants who do not fit the pattern. Ignoring disconfirming data produces analysis that reads as tidy but lacks the texture that makes findings defensible. A single participant whose experience contradicts the emerging theme is the question the analysis still has to answer, and whether the data support the theme as strongly as claimed is exactly what that question tests.
RTA reporting for stakeholders
Stakeholders will still ask: "How do we know this theme is real, and how do we defend it if someone pushes back?" That is a reasonable question. The mistake is answering it by reaching for inter-rater reliability, a mechanism Braun and Clarke explicitly reject as incompatible with reflexive thematic analysis. Forcing RTA into a reliability frame misrepresents the method and creates paperwork that cannot do what stakeholders think it does.
The better answer is a structured theme write-up, a thematic framework that makes the interpretive reasoning visible. Use this five-part structure for each theme:
Claim
One declarative sentence stating what the theme argues. "Participants tolerate price increases when the rationale is communicated before the change" is a claim. "Price sensitivity" is a label. Claims are what stakeholders can act on, and what analysts are professionally accountable for defending.
Evidence summary
Two to three sentences on the pattern across the dataset: how prevalent it was, which participant segments showed it most strongly, and whether it held across markets or was localized. "Most participants" and "a minority of participants" carry different implications for decision-making, so the write-up should say how strongly the data support each one.
Boundary conditions
Where the theme holds differently, or does not hold at all. This is the section most write-ups omit, and the one that builds the most stakeholder credibility. If the finding breaks down for a specific segment, age group, or market, say so here.
Verbatim
One or two direct quotes, or data extracts in the language Braun and Clarke use, that anchor the theme in participant language, with the participant identifier and timestamp so any stakeholder who wants to verify can find the source in under a minute.
Clip reference
The video timestamp or session ID that points to the moment in the recording. In Conveo, this closes the audit loop: a stakeholder who doubts the finding can watch the exchange, hear the tone, and see the participant's expression.
This structure documents the interpretive reasoning rather than hiding it behind a false objectivity claim. The analyst's judgment is visible in the claim and the boundary conditions, and the analytical insights trace to real people who actually said it. That combination is what separates a finding stakeholders will act on from one they will quietly set aside.
Using AI without breaking RTA
Reflexive thematic analysis puts the researcher's interpretive judgment at the center of the process. That is where AI assistance creates tension: if the platform generates codes, summarizes themes, and surfaces patterns, who does the reflexive work? The answer determines whether the analysis is methodologically defensible, and it remains a subject of ongoing discussion among researchers who use AI-assisted coding tools in their day-to-day data analysis.
The concern surfaces in peer review, ethics boards, and stakeholder meetings alike, in one question: how do we know the AI didn't just tell us what we wanted to hear? Addressing it requires a designed workflow with a clear separation between what AI handles and what the researcher owns.
What AI handles well in this context
Transcription, translation across 50+ languages, and initial code suggestions are high-volume, low-interpretation tasks well suited to AI-assisted coding tools. They are also where human moderators introduce the most variability: probing a hesitant answer on Tuesday, then letting the same hesitation pass unprobed on Friday. An AI research assistant that holds the same approach across every session gives researchers a more uniform corpus to work with, which is a reflexive gain rather than a reflexive risk.
Researchers also gain a layer that human note-takers routinely miss at scale: a tone shift when a price point is mentioned, a visible pause before a sensitive question, a facial expression that contradicts the verbal response. In RTA, these non-verbal signals are data. Capturing them systematically across hundreds of sessions gives researchers a richer corpus for detailed analysis.
Where the researcher stays in control
AI-generated code suggestions are exactly that: suggestions. The researcher decides which codes are analytically meaningful, which reflect genuine participant experience, and which are surface-level pattern-matching that does not hold up under scrutiny. Theme construction, the interpretive heart of RTA, remains researcher-led and keeps the research focus on interpretation rather than administration. The platform surfaces clusters and sentiment; the researcher determines what they mean against the study's theoretical framework and the population being studied.
Governance and audit trails matter here. Every finding needs to trace back to a real person who said it, with verbatim quotes and video timestamps available for review. That traceability is what separates credible AI-assisted analysis from black-box outputs stakeholders rightly distrust: every synthesized theme links back to the source conversation, so a researcher can verify, challenge, or reframe it before it reaches a stakeholder deck.
The real test is whether AI-assisted research, designed with the right governance, produces findings a researcher can stand behind. In practice, it often does, because the researcher's role shifts from operational execution to interpretive judgment, which is where their expertise actually lives.
Reflexive thematic analysis in enterprise contexts
Reflexive thematic analysis has a reputation for being slow, which sounds like a liability in a quarterly research calendar with stakeholder reviews already booked. The operational reality has shifted.
The old bottleneck
The bottleneck in reflexive TA sat before interpretation could begin: the hours spent reading transcripts, applying initial codes, grouping candidate themes, checking consistency across sessions. That first-pass work consumed most synthesis time.
The AI-assisted shift
AI-assisted coding changes where the first-pass transcript work goes. When an AI research assistant captures dozens of sessions and surfaces an initial coding pass as soon as each conversation closes, the researcher arrives at interpretation rather than transcription. The themes are presented as structured material for a researcher to interrogate, challenge, and refine against their own hypotheses and the study's original design intent. Reflexivity stays fully intact; what disappears is weeks of transcript management.
For enterprise teams running multi-market programs, this matters at a different scale. A qualitative study spanning five markets with 15 participants each, whether the data comes from one-on-one interviews or focus groups, historically required weeks of synthesis before a cross-market read was possible. With AI-assisted first-pass coding running in parallel across markets, a researcher can keep the research focus on comparative interpretation within days, then spend their time on the judgment that requires real expertise: what the variation between markets means, which themes are robust enough to act on, and how to frame findings for stakeholders who were not in the room.
The rigor argument holds because the researcher's role has relocated: earlier in the process, to the questions that shape what the AI codes for, and later, to the interpretation that determines what findings mean. The compression comes from removing operational drag, while analytical depth stays exactly where it was, which keeps the underlying research process rigorous rather than a shortcut.
How Conveo supports reflexive thematic analysis at scale

Insights and CMI teams running reflexive thematic analysis at enterprise scale face a specific problem: the method demands sustained interpretive engagement, and modern research programs make that engagement hard to protect. Conveo closes this gap. The walkthrough below shows reflexive thematic analysis in Conveo, start to finish.
Always-on foundation
Rather than commissioning a study, waiting for fieldwork to close, and then beginning analysis from scratch, teams using Conveo work with transcripts, multimodal signals, and verbatim evidence that arrive continuously as sessions complete. Familiarization, the most time-intensive part of RTA, can begin while fieldwork is still running.
Research rigor
Research rigor is why Conveo's always-on model works at enterprise scale. Conveo is built by researchers, and AI-moderated interviews are designed to follow what participants actually say rather than a rigid script, so the corpus reflects genuine participant meaning-making rather than moderator-shaped responses. Every theme traces back to a real person who said it, with verbatim quotes and video timestamps available for review, and the codes and clips behind each theme are visible, so the researcher can check whether the dataset actually supports it before it survives review. That traceability is what makes reflexive decisions defensible in a stakeholder meeting, and it is the standard the wider research community increasingly expects from AI-assisted qualitative research studies.
"Even if you're doing dozens of in-depth interviews, multiple focus groups, you get those interesting nuggets and insights. But then you take them to the client and there's always a sense of: is this really a trend? It's very hard to validate, and very hard to demonstrate the difference between an important trend and a one-off anomaly."
— Fergus Navaratnam-Blair, VP Trends and Futures, NRG
Compounding benefits
The compounding benefit builds over time. Findings connect across studies in a searchable insight library, so nothing gets researched twice. The reflexive context a team builds, the assumptions challenged, the patterns that held across waves, carries forward instead of disappearing into a deck. Future studies start from an informed baseline.
Enterprise insights teams at Google, Unilever, AB InBev, Kellanova, General Mills, and JDE Peet's rely on Conveo to understand their consumers. If your team is running more research than it can analyze rigorously, and decisions are outpacing insight, see how Conveo can help.
Frequently Asked Questions
What is reflexive thematic analysis?
How does reflexive thematic analysis differ from traditional thematic analysis?
What are the six steps of reflexive thematic analysis?
When should you use reflexive thematic analysis in consumer research?
How many participants do you need for reflexive thematic analysis?
What is the role of the researcher in reflexive thematic analysis?









