Thematic analysis is a qualitative method for identifying patterns (themes) across interview, survey, or observational data – no prior theoretical framework required.

TL;DR: Thematic Analysis

• Braun & Clarke’s six-phase process is the most widely cited approach: familiarise, code, search, review, define, and write up.
• Use it when you need to understand ‘why’ or ‘how’, not just ‘how many’ – it pairs especially well with user interviews and usability sessions.
• AI tools can now handle first-pass coding in minutes, but a human researcher still needs to interpret, challenge, and refine the themes that emerge.
• You need roughly 6–10 interviews to reach thematic saturation for a focused research question – more if your user population is highly varied.

Why Thematic Analysis Matters in User Research

You’ve just finished a round of user interviews. There are hours of transcripts, a handful of voice notes, and a nagging feeling that something important is buried in there – you just can’t see the shape of it yet.

That’s exactly the problem thematic analysis was built to solve.

Most research methods tell you what happened. Thematic analysis tells you what it meant. It’s how product teams go from “users said X” to “users are struggling with X because of Y, and that points to a bigger problem with Z.” That interpretive step – turning raw quotes into actual product direction – is where most DIY research falls apart.

Thematic analysis is now one of the most widely used methods for analyzing qualitative data across academic and applied research contexts. And its popularity isn’t just academic: for product teams, UX researchers, and founders running qualitative thematic analysis on interview data, it’s often the difference between insights that change decisions and a folder of transcripts nobody reads.

This guide covers everything from first principles to AI-assisted workflows – including a free downloadable coding template. Whether you’re planning your first synthesis sprint or trying to get qualitative research done without a dedicated research team, there’s a practical path through the process here.

What Is Thematic Analysis?

Thematic analysis is a qualitative research method for identifying, analyzing, and reporting patterns (called themes) across a dataset. It doesn’t start with a hypothesis you’re trying to prove – it starts with data you’re trying to understand.

The method was formalized by Virginia Braun and Victoria Clarke in their 2006 paper [Using Thematic Analysis in Psychology] which has since become one of the most cited papers in qualitative research methodology. Their approach, often called reflexive thematic analysis, treats the researcher’s interpretive role as a feature rather than a bug: you’re not just labeling data, you’re actively constructing meaning from it.

A few things worth clarifying upfront:

• Themes aren’t just topics. A theme captures a pattern of shared meaning across multiple data points, not just a subject that came up repeatedly. ‘Pricing’ is a topic. ‘Users feel embarrassed asking about pricing’ is a theme.
• Thematic analysis is not the same as content analysis. Content analysis counts and categorizes. Thematic analysis interprets. (More on this distinction later.)
• It’s not tied to a single theoretical framework. That’s one of its biggest strengths – you can apply it to interview transcripts, open survey responses, focus group recordings, observation notes, even social media data.

Thematic Coding: The Building Block of Thematic Analysis

Thematic analysis and thematic coding are closely related but not the same. For clarity, thematic coding is the process that makes thematic analysis possible – it’s the act of labeling sections of your data with short codes that capture what each piece is about.

What is a thematic code?

A code is a short label you assign to a segment of data – a quote, a sentence, an observation – that summarizes what it represents. Codes start descriptive (‘participant mentions scheduling delays’) and become interpretive (‘time as a perceived barrier’).

Types of codes:

• Open codes: first-pass labels applied directly from the data, close to the words used
• Axial codes: second-pass labels that group open codes by relationship or pattern
• Selective codes: higher-order labels that capture the central themes across all your data

From codes to themes:

Codes become themes when you review your coded data and find patterns – groups of codes that co-occur, repeat across participants, or seem to explain the same underlying issue.

A theme is the interpretation; coding is the raw material that gets you there.

⚠️ Quick note for developers who landed here by accident: If you searched for ‘themes’ in the context of VS Code, you’re looking for something completely different. VS Code themes are colour schemes for the code editor interface – they control syntax highlighting, background colours, and UI appearance. They have nothing to do with qualitative research. The right place to browse VS Code themes is the VS Code Marketplace. This guide is about thematic analysis as a research method.

When and Why to Use Thematic Analysis in Product & UX Research

Thematic analysis earns its place when you’re trying to understand experience, process, or meaning – not when you need to count or measure.

In product and UX contexts, that usually means:

• You’ve run user interviews and need to synthesize findings across 8–15 participants
• You’re processing open-ended survey responses at scale
• You’ve completed usability sessions and want to identify recurring friction patterns
• You’re doing discovery research before a new feature or product area
• You need to present qualitative insights to stakeholders in a structured, defensible format

When Should You Use Thematic Analysis?

Thematic analysis gets recommended for almost everything. That’s partly because it genuinely is flexible – but it’s also because a lot of research guides are written by people who have a favourite method and want you to use it.

So let’s be honest about both sides.

The real strengths:

It doesn’t demand a theoretical commitment upfront. Grounded theory requires you to buy into a whole methodology before you collect a single data point. Thematic analysis doesn’t care – you can run it from a constructivist position or a realist one, on interview data or open survey responses, and the process holds. That’s genuinely unusual in qualitative work.

No specialist software required, either. A spreadsheet and a clear research question are enough for most projects under ten interviews. NVivo helps when you’re managing large datasets across multiple coders, but treating it as a prerequisite is how small teams talk themselves out of doing any analysis at all.

When Should You NOT Use Thematic Analysis?

Thematic analysis is flexible enough to apply in many contexts. That flexibility is also what makes it easy to misapply.

When Thematic Analysis Works Well

• You have 6–30 interview transcripts or open-ended survey responses and need to identify patterns across them
• Your research question is exploratory (“what are users’ experiences of X?”) rather than confirmatory (“does X cause Y?”)
• You need a method that works without a fixed theoretical framework
• Your audience needs readable, structured insights rather than statistical output

When Thematic Analysis Falls Short

• Frequency-based questions – if a stakeholder asks “how often do users mention X?”, content analysis or simple tagging is more efficient and appropriate
• Causal claims – thematic analysis surfaces patterns but cannot establish causation. Do not present it as if it can.
• Very small datasets – fewer than 4–5 interviews typically produces anecdotes, not patterns
• Hypothesis testing – if you have a theory to test against data, a deductive coding framework or discourse analysis is more rigorous
• Time-constrained synthesis – manual thematic analysis takes days. AI-assisted analysis tools can produce a first-pass synthesis in minutes, but the interpretive quality still depends on the quality of your research questions

Thematic Analysis vs. Content Analysis: Which One Do You Need?

This is one of the most common questions in qualitative research – and most articles gloss over the practical difference.

	Thematic Analysis	Content Analysis
Primary goal	Interpret meaning and patterns	Categorize and count occurrences
Output	Themes with interpretive narrative	Frequencies, categories, codes
Best for	Understanding ‘why’ and ‘how’	Measuring ‘what’ and ‘how much’
Data types	Interviews, observations, open responses	Any text – including quantitative surveys
Researcher role	Actively interpretive	Aim for systematic objectivity
Typical team context	Discovery, generative research	Evaluative, benchmark research

The short version: if a stakeholder asks ‘what do users think about onboarding?’ – use thematic analysis. If they ask ‘how often did users mention confusion during onboarding?’ – content analysis or simple tagging will serve you better.

Thematic Analysis vs. Grounded Theory

Grounded theory also generates theory from qualitative data, but it’s a full research methodology – not just an analysis method. It requires theoretical sampling, constant comparison, and iterative data collection until theoretical saturation. That’s a significant commitment.

Thematic analysis is more practical for most applied research contexts. You can run it on an existing dataset without restructuring your entire study design.

Method	Best for	Not suited for
Thematic analysis	Understanding meaning, experience, and process across interview or open-response data – especially when you need findings a non-researcher can act on	Hypothesis testing, small datasets with little variation, projects where consistency across multiple coders is critical
Content analysis	Systematically categorizing and counting what’s present in text – support tickets, survey responses, social media data at scale	Explaining why patterns exist or what they mean to the people producing them
Grounded theory	Building a new theoretical model from scratch when no existing framework adequately explains what you’re seeing in the data	Systematically categorizing and counting what’s present in text – support tickets, survey responses, social media data at scale

The Six (or Seven) Phases of Thematic Analysis

Braun and Clarke’s six-phase framework is the closest thing qualitative research has to a standard operating procedure. The phases aren’t strictly linear – you’ll often loop back – but they give you a structure to work within.

Phase 1: Familiarisation

Read and re-read your data before you touch a highlighter or open a spreadsheet. Listen back to recordings if you have them. Write down anything that strikes you – observations, gut reactions, early hunches.

This phase is often rushed, especially when teams are under deadline pressure. That’s a mistake. The interpretive quality of your final themes is built on how well you know your data at this stage.

Practical tip: Write a one-paragraph ‘data portrait’ after reading each transcript – your overall impression in plain language. These notes become valuable anchors when you’re deep in coding later.

Phase 2: Generating Initial Codes

Coding is the act of labeling meaningful segments of data. At this stage, be generous – code everything that might be relevant. You can always collapse or discard codes later, but you can’t recover something you missed.

Codes sit at two levels:

• Semantic codes describe what’s explicitly said: ‘users mention price as a barrier’
• Latent codes interpret what’s implied beneath the surface: ‘users feel judged for not being able to afford premium tier’

Most rich analysis works at both levels. The latent codes are usually where the most actionable insights live.

Phase 3: Searching for Themes

Start grouping related codes into candidate themes. This is where affinity mapping comes in for many UX researchers – you’re essentially clustering codes by shared meaning, not just shared topic.

A useful test at this stage: can you write a sentence that captures what this theme is about – not what it contains, but what it means? If you can’t, it’s probably not a theme yet.

Phase 4: Reviewing Themes

Go back to the data. Do your candidate themes hold up? Are there data points that don’t fit cleanly? Are two themes actually the same thing? Is one theme really three?

This review happens at two levels: within the coded extracts (do the codes actually belong together?), and across the full dataset (does this theme make sense given everything you collected?).

Phase 5: Defining and Naming Themes

Each theme needs a name and a short definition that captures its essence. The name should be specific enough to be meaningful (‘onboarding creates anxiety around competence’) rather than vague (‘onboarding issues’).

Write a short paragraph for each theme explaining what it captures and why it matters. This prose becomes the backbone of your analysis section.

Phase 6: Writing Up

The write-up is not a summary of your themes – it’s an argument. You’re making the case that your interpretation of the data is valid, supported, and meaningful. Use illustrative quotes to anchor each theme, but narrate around them rather than letting the quotes speak for themselves.

For product research contexts, this usually means translating themes into implications: ‘Given that users consistently describe X, the product should consider Y.’

The Optional Seventh Phase: Stakeholder Presentation

Academic guides stop at the write-up. Applied researchers know there’s a seventh step that often determines whether your work actually influences decisions: presenting findings to stakeholders who didn’t experience the data with you.

This means translating your analysis into formats that land – executive summaries, insight decks, ‘how might we’ statements tied to specific themes. The analytical rigor lives in the write-up; the impact lives in the presentation.

What are the Different Approaches to Thematic Analysis?

Inductive vs. Deductive Thematic Analysis

This is the single most misunderstood distinction in thematic analysis – and most articles on the topic handle it poorly.

Inductive (bottom-up): You let the data drive the themes. You don’t start with a framework or hypothesis – you start with open questions and build understanding from what emerges. This is appropriate for discovery research where you’re trying to understand something you don’t yet have a model for.

Deductive (top-down): You start with a framework, theory, or set of predetermined codes and apply them to the data. This works when you have an existing model you want to test or when you’re coding against a defined set of criteria.

Most applied research sits somewhere in between. You might start inductively and then use a product framework to organize themes for stakeholder communication – that’s fine, as long as you’re honest about the approach.

Semantic vs. Latent Analysis

Semantic analysis describes the surface meaning – what participants explicitly said. Latent analysis digs into the assumptions, conceptualizations, and underlying patterns beneath what was said.

For UX research, latent analysis is usually more valuable. A user saying ‘I always double-check my settings’ is a semantic observation. Interpreting that as ‘users don’t trust the system to remember their preferences’ is latent analysis – and that’s what generates real product direction.

Reflexive Thematic Analysis (Braun & Clarke’s Preferred Term)

Braun and Clarke have been increasingly clear in recent years that what they describe is specifically reflexive thematic analysis – not a generic catch-all approach. The reflexive element means the researcher actively reflects on how their own perspective, assumptions, and theoretical positioning shape the analysis.

For product researchers, this matters practically: your hypothesis about the product will influence what you notice in the data. Being explicit about that bias is more rigorous than pretending it doesn’t exist.

Codebook Approaches: Framework Analysis and Template Analysis

Framework analysis (common in health research) and template analysis use predefined or partially predefined code structures. These are more structured than reflexive TA and lend themselves to team-based coding where consistency across coders matters.

For UX teams doing repeated research cycles on the same product area, a codebook approach can be more efficient – you build up a code library over time rather than starting from scratch each round.

What Is Researcher Positionality in Thematic Analysis?

Researcher positionality refers to how your background, assumptions, and relationship to the research topic shape what you notice – and what you miss – during coding and interpretation. In reflexive thematic analysis, this isn’t treated as bias to be neutralized; it’s part of the analytical process, something to document and interrogate rather than paper over. Braun and Clarke’s own guidance is clear on this: the researcher’s active role in constructing meaning is what makes thematic analysis an interpretive method, not a mechanical one.

How Do You Ensure Trustworthiness in Thematic Analysis?

Qualitative research uses different language for rigor than quantitative research. The equivalent concepts are trustworthiness, credibility, dependability, and transferability – and they matter just as much.

Member Checking

Share your themes and interpretations with some of the participants who contributed to the research. Ask them whether your account of their experience rings true. This doesn’t mean changing your themes every time someone disagrees – it means taking their response seriously as additional data.

Thick Description

Document your process in enough detail that someone else could understand your analytical decisions. This includes keeping a reflexivity journal during analysis – noting why you made the coding choices you did, where you were uncertain, and where you saw your own assumptions at play.

Peer Debriefing and Multiple Coders

Having a colleague independently code a subset of your data isn’t about achieving perfect agreement – it’s about surfacing interpretive blind spots. When you compare codes and find differences, the discussion is often more valuable than either original interpretation.

Note: inter-rater reliability (using Cohen’s kappa or similar statistics) is more appropriate for content analysis than for reflexive thematic analysis, where interpretive variation is expected rather than problematic.

Negative Case Analysis

Actively look for data points that contradict your emerging themes. If your theme is ‘users feel excluded by technical jargon’ and you have three participants who said they found the terminology helpful, that tension is analytically interesting – not something to smooth over.

How Many Interviews Do You Need?

One of the most searched questions in qualitative research – and the answer most guides give is unsatisfyingly vague: ‘it depends.’

Here’s a more useful framework for applied research contexts:

• For a focused research question with a relatively homogeneous user population: 6–8 interviews typically produce thematic saturation
• For broader discovery research across multiple user types: 12–15+ interviews
• For segmented analysis (e.g., enterprise vs. SMB users): 6–8 per segment

The concept of thematic saturation – the point where new interviews stop generating new themes – is a more principled guide than any fixed number. In practice, most research teams reach saturation earlier than they expect when the research question is tightly scoped.

Researchers typically aim for thematic saturation – the point at which new interviews stop producing new themes or codes. For homogeneous samples with a tightly scoped research question, this often occurs somewhere between 6 and 8 interviews; heterogeneous samples, or studies spanning multiple distinct user types, may need 15 to 20 or more before the picture stabilizes. Tracking saturation interview-by-interview using a simple log is more reliable than deciding on a target number upfront.

Researcher Positionality: Why Your Perspective Shapes Your Themes

Braun and Clarke’s reflexive approach explicitly treats the researcher as an active participant in constructing meaning – not a neutral observer extracting facts from data.

Positionality refers to how your background, assumptions, and relationship to the research topic shape what you notice, what you code, and what themes you develop. A product manager analyzing interviews about a feature they championed is in a different position than an external researcher with no stake in the outcome. That difference affects the analysis whether acknowledged or not.

Reflexivity is the practice of naming and examining that influence: • What assumptions did I bring to this data? • Which quotes did I gravitate toward – and which did I dismiss? • Does my professional framing make me more likely to see validation than critique?

This is not about eliminating bias. It is about being transparent about the analytical lens so that someone reading your write-up can evaluate your interpretation rather than just accepting it.

For applied research in product teams, a brief reflexivity note at the start of your analysis document is usually enough: “I am the PM who championed this feature. I made a deliberate effort to weight critical responses equally.”

Can AI Tools Help With Thematic Analysis?

Yes – but the requirement for human judgment does not disappear, it shifts.

Where AI tools add real value:

• First-pass coding: Reading 20 transcripts and returning initial codes in minutes, surfacing patterns that would take hours to find manually.
• Frequency flagging: Identifying which topics appear most often, useful for deciding where to focus interpretive attention.
• Quote extraction: Pulling relevant quotes that support emerging themes without manually re-reading full transcripts.

Where human judgment is still essential:

• Deciding which codes become themes: The interpretive step that distinguishes thematic analysis from content analysis requires a researcher who understands the research context.
• Challenging the AI framing: AI tools trained on text patterns can surface themes that look coherent but miss the latent meaning beneath the words.
• Accounting for researcher positionality: What a researcher brings to the data shapes what they see; an AI cannot reflect on its own perspective the way a researcher can or should.

Tools like Articos take a different approach: rather than analyzing your transcripts, they conduct the synthetic interviews and produce structured theme reports as output – skipping the manual coding stage entirely. This is faster but best suited for concept testing and messaging validation rather than open-ended discovery research on existing transcripts.

For teams working with existing transcripts: Dovetail and ATLAS.ti offer AI-assisted tagging. For teams wanting to skip recruiting and get structured qualitative themes from scratch: Articos handles the full research cycle.

Data Saturation: How Do You Know When You Have Enough?

Data saturation is the point at which new interviews stop producing new themes. You are still getting quotes – they are just supporting patterns you have already identified rather than opening new lines of inquiry.

The concept matters because it gives you a defensible stopping point. “We stopped at six interviews” is harder to justify than “we reached thematic saturation at six interviews – additional interviews produced no new themes.”

In practice:

• For a focused research question with a homogeneous user population, saturation often occurs at 6–8 interviews
• For broader discovery research or diverse populations, expect 12–20 before patterns stabilize
• Saturation is assessed against your specific research question, not against everything users could ever say. Narrow the question first.

What Tools and Templates Support Thematic Analysis?

The mechanics of thematic analysis have changed substantially with AI tooling. Here’s an honest look at what’s available and what each approach is actually suited for – plus a template you can use immediately.

Manual Coding: Spreadsheets and Sticky Notes

There’s nothing wrong with a well-structured spreadsheet. A simple three-column layout – data extract, initial code, candidate theme – works for most projects under 10 interviews. Many experienced researchers still do their first-pass coding in a text editor before moving into any dedicated tool.

Physical sticky notes and affinity mapping stay genuinely useful for theme development in Phase 3. The tactile, spatial aspect of moving clusters around often surfaces connections that a spreadsheet doesn’t.

Dedicated Qualitative Analysis Software

Tools like NVivo, MAXQDA, and ATLAS.ti are the standard for serious qualitative work. They handle large datasets, support multiple coders, and generate audit trails. The learning curve is real, though – and license costs can be prohibitive for smaller teams.

Dovetail and EnjoyHQ offer lighter alternatives designed for product research, with better UX and easier collaboration, though with less analytical depth.

AI-Assisted Thematic Analysis: Where It Actually Helps

AI research tools have changed what’s realistic for teams without a dedicated research function. They’re genuinely useful for:

• First-pass coding – LLMs can generate an initial set of codes across a transcript in seconds. This doesn’t replace your analysis; it gives you a starting point to react to.
• Pattern spotting across large datasets – if you’re processing 40+ open-ended survey responses, AI can surface recurring language and candidate themes faster than manual reading.
• Transcript cleaning and summarization – getting transcripts into a workable state used to be hours of work. AI tools compress that to minutes.
• Generating interview guides – AI can draft semi-structured question sets aligned with your research objectives, cutting significant prep time.

Where AI falls short:

• It can’t do latent analysis well. LLMs identify what’s explicitly present in text – they struggle with the beneath-the-surface interpretation that generates the most valuable insights.
• It doesn’t know your product context. A generic AI coding pass will miss the specific meaning of behaviors that only matter in the context of your product.
• It has no reflexivity. The active self-questioning that defines rigorous thematic analysis isn’t something an LLM can replicate.

A 2025 systematic review published in PubMed found that LLMs demonstrated strong potential for rapid thematic pattern identification, closely resembling human analysis in scope – but varied significantly in interpretive depth and cultural nuance across models. AI works best as an adjunct, not a replacement, for human-led qualitative analysis.

How Articos Can Help With Thematic Analysis

For product teams and UX researchers who want to run thematic analysis faster without cutting corners on quality, the bottleneck usually isn’t the analysis itself – it’s getting enough quality data to analyse in the first place.

Traditional recruitment, scheduling, and transcription can burn 2–3 weeks before you’ve coded a single line. That timeline makes qualitative research impractical for most sprint cycles.

Articos, an AI user research platform, approaches this differently. The platform conducts AI-powered user interviews with synthetic personas built from your defined user profile – which means you can run a full round of ‘interviews’ and have structured, analysable transcripts ready in under 30 minutes. Because the output is structured research data (not raw audio or informal chat logs), the move into thematic analysis is significantly faster.

The synthetic interviews produce consistent, comparable data across participants – which makes Phase 2 (coding) and Phase 3 (searching for themes) more tractable. You’re not spending the first pass just parsing conversational noise.

Articos doesn’t replace the interpretive work of thematic analysis. It removes the recruitment bottleneck that makes qualitative research impractical for teams without dedicated research resources. For agencies, product managers, and founders who need insight before they can do analysis, that distinction matters.

Try Articos free and run your first synthetic research session in under 30 minutes.

A Worked Example: Thematic Analysis on Real Interview Data

Here’s a condensed worked example using real-pattern data from a B2B SaaS onboarding research study. (Participant identifiers are anonymized.)

Research Question

Why do new users disengage during the onboarding flow before completing account setup?

Data: Three Interview Extracts (Phase 1)

Participant A: “I got to the integrations step and just… stopped. I didn’t know which tools I was supposed to connect. It felt like they assumed I already knew what I was doing.”

Participant B: “There were too many options. I spent ten minutes on one screen just trying to figure out which one was right for me. Eventually I just closed the tab.”

Participant C: “I couldn’t tell if I was doing it right. I kept second-guessing myself. I didn’t want to set something up wrong and then have to fix it later.”

Initial Codes (Phase 2)

• Assumed prior knowledge (‘assumed I already knew’)
• Decision paralysis from too many options (‘too many options’)
• Fear of making a recoverable error (‘set something up wrong’)
• Abandonment at integration step
• Cognitive overload without guidance

Candidate Theme (Phase 3)

Theme: Onboarding creates anxiety around irreversible mistakes

All three participants show a pattern of self-doubt and avoidance driven by uncertainty about the consequences of their choices. This isn’t a ‘too many steps’ problem – it’s a confidence problem. Users aren’t abandoning because onboarding is too long; they’re abandoning because they’re afraid of getting it wrong.

Product Implication

The fix isn’t simplification – it’s reassurance. Adding ‘you can change this later’ microcopy at decision points, defaulting to sensible options with the ability to override, and showing progress through completed setup all address the underlying theme more precisely than removing steps.

Free Thematic Analysis Coding Template

This guide provides a structured coding template designed for spreadsheets (Google Sheets, Excel), linking each phase of thematic analysis (following Braun & Clarke’s widely accepted six-phase framework) to specific actions within the template. You will find a blank structure, a guided approach by phase, and diverse, detailed examples to illustrate the process.

Key Takeaways

• The six phases aren’t optional shortcuts. Familiarize, code, search, review, define, write up – skipping or collapsing phases is why most thematic analysis produces topic lists instead of actual themes. The review phase (Phase 4) is the one teams most often rush, and it’s the one that catches false themes before they end up in a stakeholder deck.
• Inductive and deductive aren’t opposites you have to choose between. Start inductively – let the data show you what’s there – then use a deductive frame to organize findings for the people who need to act on them. Most applied research works this way. Committing rigidly to one or the other usually means either ignoring what you already know or only finding what you expected to find.
• Saturation beats any fixed number. For a focused research question with a relatively similar user group, 6–8 interviews is typically where new themes stop appearing. Broader discovery work across varied user types pushes that to 12–15+. The reliable signal is two or three consecutive interviews that add nothing new – not hitting a number someone told you in a workshop.
• Reflexivity is the method, not an add-on. Your assumptions about the product will shape what you notice in the data. That’s not a problem to eliminate – it’s something to document. Keeping a reflexivity log during coding isn’t admin; it’s what separates a defensible analysis from one that a stakeholder can reasonably dismiss as the researcher finding what they wanted to find.
• Themes need to mean something, not just recur. A theme captures a pattern of shared meaning – it tells you why something matters, not just that it came up repeatedly. If you can’t write a sentence explaining what a theme means rather than what it contains, it isn’t ready.

FAQs: Thematic Analysis