TL;DR: Thematic Coding
- Thematic coding assigns short labels to qualitative data so patterns can be spotted across interviews, surveys, and open-ended responses.
- Braun & Clarke’s six-phase framework (familiarise → code → search → review → define → write) is the most widely used structure for thematic analysis.
- Inductive coding lets themes emerge from the data; deductive coding tests pre-existing theory most real projects end up mixing both.
- Software like NVivo, ATLAS.ti, and Dovetail speed up the process, but you can also start with a spreadsheet if your dataset is small.
- The biggest mistakes aren’t technical they’re definitional. Vague codes and theme drift quietly ruin otherwise solid research.
You finished your user interviews. Maybe twelve of them, maybe forty. The transcripts are sitting in a folder and you’re staring at thousands of words wondering how you’re supposed to turn this into something a stakeholder will actually read.
That’s exactly the problem thematic coding was designed to solve.
It’s not a flashy method, and it rarely gets the credit it deserves. But done properly, it’s the difference between a research report full of vague impressions and one where you can point to a pattern and say: eleven of sixteen participants mentioned this, unprompted. That’s what makes product decisions defensible.
This guide covers how thematic coding works, how it fits into the broader thematic analysis process, and what separates research that holds up from research that falls apart under questioning. We’ll also answer the practical questions most guides skip over like when to use software and how to choose between inductive and deductive approaches.
What Is Thematic Coding and Why It Matters in User Research
Thematic coding is the practice of attaching short labels codes to segments of qualitative data. A segment might be a sentence, a paragraph, or a full turn of speech. The code captures its main idea: something like “onboarding confusion” or “trust in pricing” or “feature request: export.”
By itself, a code is just a label. The value comes from aggregation. Once you’ve coded everything, you can pull every segment tagged “onboarding confusion” into one view and ask: what’s really going on here? Are users confused about the same step, or are there three different failure points? That comparison is where insight lives.
Most studies end up with somewhere between 30 and 80 active codes. According to Lumivero, a single transcript typically yields quotations from 10 to 15 codes, while 25–30 codes across a dataset generally produce 4–5 consolidated themes.
The reason it matters in user research specifically is that qualitative data from interviews, usability tests, and open-ended surveys doesn’t compress well without a system. You can’t average it. You can’t put it in a bar chart. Thematic coding gives it structure without flattening the nuance that makes qualitative work worth doing in the first place.
Thematic Coding vs. Thematic Analysis: The Distinction That Trips People Up
These two terms get used interchangeably, but they describe different things. Thematic coding is a step the act of labeling. Thematic analysis is the whole process that coding feeds into: from raw data all the way to a written report with named themes and interpreted findings.
Coding without analysis produces a categorized list. Analysis without rigorous coding produces impressionistic claims. You need both, and in the right order.
Thematic analysis is described by researchers as “one of the most widely utilized methods for analyzing qualitative data” valued precisely because it offers a structured framework while staying flexible enough to apply across disciplines, from health sciences to UX to organizational research.
The 6 Phases of Thematic Analysis Explained with Examples
Braun and Clarke’s six-phase framework is the reference point for most thematic analysis in practice. It’s not a rigid checklist – the process is iterative, and you’ll move back and forth between phases. But the structure keeps analysis honest.
Phase 1: Familiarise Yourself with the Data
Read everything. All of it. Including the parts that seem irrelevant. Make notes in the margins not codes yet, just reactions. First impressions matter because they surface things your brain flags before it learns to filter them out.
If you’re working with interview audio, listen before reading the transcript. The tone, pauses, and hesitations carry information that transcription often loses.
Phase 2: Generate Initial Codes
Now you’re labeling. Go line by line and ask: what is this segment about? Keep codes descriptive at this stage – you’re not interpreting yet, you’re capturing. A segment about a user struggling to find the settings menu gets a code like “navigation failure,” not “poor design.”
Expect to assign multiple codes to the same segment. A single quote about feeling embarrassed to ask for help in a group setting could be coded as “social pressure,” “feature adoption barrier,” and “support-seeking behavior” simultaneously.
Phase 3: Search for Themes
Group your codes into candidate themes. You’re looking for patterns that answer your research questions – not just things that appear often, but things that are meaningful. Frequency matters, but a code that appears twice and captures a critical pain point can be more significant than one that appears twenty times and describes something peripheral.
This is where a physical or digital affinity diagram helps. Move codes around until groupings feel coherent, and don’t force codes into themes where they don’t belong. Leftover codes aren’t failures – they’re data that didn’t fit the story, and sometimes that’s the most interesting part.
Phase 4: Review Themes
Take your candidate themes back to the data. Do they actually hold? A theme that looks clean in the abstract often fractures when you re-read the segments underneath it. That’s not a problem – it’s the process working.
Also check across participants. A theme built on one particularly articulate interviewee is a quote, not a finding. It needs to show up in enough of your dataset to be credible. There’s no universal threshold, but “recurring” usually means at least three to five participants, unprompted.
Phase 5: Define and Name Themes
This is where most researchers rush, and where a lot of analysis quietly breaks. A theme name should capture what’s distinctive about the pattern – not just what topic it covers. “Trust” is a topic. “Users trust pricing transparency more than feature completeness” is a theme. The difference is that the second one could support a product decision.
Write a short definition for each theme that includes: what the theme is, what it’s not, and a representative quote. This definition becomes the anchor for everything that follows.
Phase 6: Write the Report
The report isn’t a summary of your themes – it’s an argument. You’re making a case that this pattern exists, that it matters, and that you found it through a rigorous process. Back every claim with data. Show your reasoning. Include counterevidence where it exists.
A good thematic analysis report could be challenged by a skeptical reader and survive. If your themes are defensible, the writing makes them easy to challenge and rebut. If they’re not, better to find out during the drafting stage than during the stakeholder presentation.
| Practical tip: Maintain a running document of your analytical decisions throughout all six phases. What codes did you merge? Why? Which segments were borderline? This audit trail is what makes your findings reproducible and it’s what reviewers and executives will ask for when they push back. |
Thematic Coding vs Content Analysis: Which Method Fits Your Research
People mix these up constantly, and it leads to bad methodological choices. Here’s the short version: content analysis counts; thematic analysis interprets.
Content analysis is well-suited to questions like: how often do users mention price? Which features appear most in support tickets? How frequently does competitor X come up in sales calls? It’s systematic, often quantitative at heart, and produces results that are easy to report to non-researchers.
Thematic analysis is better for: why do users feel anxious about upgrading? What’s actually driving churn, beneath what users say on exit surveys? What shared mental model are enterprise buyers using to evaluate tools in this category?
The practical rule: if your research question starts with “how many” or “how often,” you probably want content analysis. If it starts with “why” or “what’s going on with,” thematic coding is the right starting point.
| Factor | Thematic Coding | Content Analysis |
| Primary question | Why / what does this mean? | How often / how many? |
| Output | Interpreted themes with meaning | Categorized counts & frequencies |
| Flexibility | High approach adapts to data | Lower codes defined upfront |
| Best for | Exploratory qualitative research | Benchmarking, trend tracking |
| Reporting | Narrative with supporting quotes | Tables, charts, percentages |
Inductive vs Deductive Thematic Coding: How to Choose
This is one of the most commonly Googled questions about thematic coding, and most answers make it sound more complicated than it is.
Inductive coding means you go into the data without a predetermined framework. Codes emerge from what participants actually said. It’s the right choice when you’re exploring territory you haven’t mapped before new product categories, underrepresented user groups, or research questions where the assumptions haven’t been tested.
Deductive coding starts with an existing framework – a theory, a previous codebook, or a set of hypotheses. You apply those codes to the data and check whether the evidence supports them. It’s more efficient and directly comparable across datasets, which makes it ideal for follow-up studies, benchmarking, or validating a model you’ve already proposed.
Most real research projects end up somewhere in between. You might start deductively with a framework from a previous round of research, then allow inductive codes to emerge for anything the framework doesn’t capture. That’s fine – methodological orthodoxy is less important than honest documentation of what you actually did.
| Quick rule: If you’re asking “does our framework explain what we’re seeing?”, go deductive. If you’re asking “what’s going on here?”, go inductive. If you’re not sure, start inductive you can always apply a framework later, but you can’t un-influence your coding once you’ve started with one. |
Can Thematic Coding Be Done Manually or Do You Need Software?
Short answer: you can do it manually. Whether you should depends on your dataset size and how much of your time matters.
A dataset of five to eight interviews – say, 30,000 to 50,000 words – is manageable with a spreadsheet and a highlighter system. Researchers have been doing this since long before dedicated software existed, and there’s something to be said for staying close to the raw text without the abstraction of a tool interface.
Above that threshold, manual coding starts to cost you in two ways: raw time, and the cognitive overhead of keeping your coding consistent across a large corpus. That’s where qualitative data analysis (QDA) software earns its place.
The advantages aren’t just speed:
- Codes can be merged, split, and renamed without re-doing everything manually
- You can apply multiple coding schemes to the same dataset
- Queries let you cross-reference codes e.g., “show me every segment coded ‘pricing concern’ from participants in enterprise roles”
- The audit trail is built in, which helps with reporting and reproducibility
Best Software Tools for Thematic Coding of Interviews
The tools below cover the range from academic-grade QDA software to purpose-built research ops platforms:
NVivo – The most established QDA tool in academic and applied research. Strong for complex multi-method studies. Steeper learning curve, but the query and visualization capabilities are unmatched for large corpora.
ATLAS.ti – Close competitor to NVivo. Many researchers prefer its interface for network diagrams showing how codes relate to each other.
Dovetail – Built for product and UX research teams. More collaborative than traditional QDA tools, with a simpler interface. Better suited to teams that need non-researchers to understand findings.
Dedoose – Cloud-based, good for mixed-methods work where you need to link qualitative codes to survey or demographic data.
Notion / Airtable + manual system Genuinely viable for smaller datasets if you have a well-structured tagging system. Free, and your team already knows how to use it.
A note on AI-assisted coding: tools are increasingly offering auto-suggestion of codes based on language patterns. These can speed up initial coding, but they don’t replace the interpretive judgment that gives thematic analysis its value. Use them to surface candidates, not to finalize themes.
How to Avoid Common Mistakes in Thematic Coding
Most mistakes in thematic coding aren’t methodological – they’re definitional. Here are the ones that appear most often in user research contexts, and what to do about them.
Treating Topics as Themes
“Pricing,” “onboarding,” and “support” are topics. They organize your data but don’t say anything about it. A theme makes a claim: “Users accept higher pricing when they understand the value delivery timeline.” That claim is falsifiable, arguable, and useful to a product team.
If your theme names could double as section headers in a survey, they’re topics. Push further.
Coding to Confirm What You Already Think
This is the qualitative equivalent of p-hacking. It happens when researchers code data that supports their hypothesis more thoroughly than data that complicates it. The antidote is active disconfirmation when you find a theme, explicitly go looking for segments that challenge it. If you can’t find any, that’s either a very strong finding or a sign you need to look harder.
Codes That Overlap Too Much
If you’re regularly assigning three or four codes to the same segment and they all seem equally accurate, your codebook has a structural problem. Either you have redundant codes that need to be merged, or you’re working at two levels of abstraction simultaneously. Good codebooks are hierarchical – broad codes at the top level, more specific ones underneath.
Skipping the Review Phase
Phase 4 of Braun and Clarke’s framework – reviewing themes against the full dataset is the one most often cut when research timelines compress. It’s also the one most likely to catch the errors that make findings look bad under scrutiny. Build it into your timeline and protect it.
Working Alone on a Large Dataset
Inter-rater reliability testing isn’t always required (particularly in reflexive thematic analysis), but having a second person spot-check 10–15% of your coding catches drift you can’t see yourself. It’s also much easier to defend findings that have been reviewed by someone other than the person who generated them.
According to a 2025 academic review published in Frontiers in Education, peer debriefing and member-checking – having colleagues review your coding decisions – significantly improves the credibility of qualitative findings, especially when datasets are large.
What If You Could Skip the Recruitment Problem Before Coding Even Starts?
Thematic coding is only as good as the data going into it. And for most teams doing user research, the harder problem isn’t the analysis it’s getting enough quality interview data in the first place.
Recruiting participants for qualitative research typically takes weeks. Scheduling, no-shows, incentive management the overhead often exceeds the analysis time. That’s the specific problem Articos was built to remove.
Instead of waiting for real participants, Articos generates synthetic user personas and runs AI-moderated interview sessions in under 30 minutes. The output is structured qualitative data the kind you’d normally spend three weeks collecting ready for analysis.
That doesn’t replace thematic coding. The analysis still needs to happen. But it does mean you can run more research cycles, test more hypotheses, and spend your actual analysis time on interpretation rather than data wrangling.
If you’re a product manager, UX researcher, or founder who needs to validate ideas fast, it’s worth seeing how the workflow compares to traditional recruitment.
Advanced Thematic Coding: Tips Most Guides Skip
Build a Living Codebook, Not a Static One
Your codebook should be a working document that updates as you code. Start with a small set of anchor codes from your research questions, then add, merge, and prune as patterns emerge. A codebook that’s finished before you start coding is usually a deductive framework in disguise.
Each entry should include: the code name, a one-sentence definition, an example segment, and a note about what the code excludes. The exclusions matter – they’re what keep adjacent codes from bleeding into each other.
Code at the Right Level of Abstraction
First-pass coding should stay close to the language participants actually used – what researchers call semantic or latent coding at the surface level. Interpretive abstraction comes later, when you’re building themes. If you jump to interpretation too early, you risk coding what you expected to find rather than what’s there.
Use Deviant Cases as a Quality Check
Before finalizing themes, actively search for segments that don’t fit. Cases that deviate from your emerging themes are valuable for two reasons: they test whether your theme is robust, and they sometimes point toward a pattern you hadn’t noticed yet. Don’t file them away – interrogate them.
The Problem With AI Auto-Coding at Scale
AI-assisted thematic coding is genuinely useful for surfacing initial code candidates across large datasets. Where it breaks down is in distinguishing between surface-level repetition and meaningful recurrence. Two participants can use the same word to mean completely different things. A human coder catches that; an NLP model often doesn’t. Use AI tools to generate hypotheses, not conclusions.
The future of qualitative research involves human-AI collaboration at every stage – but the interpretive judgment that makes themes meaningful remains a human responsibility.
Thematic Coding in User Research: Industry-Specific Applications
Most guides treat thematic coding as a generic academic method. Here’s how it applies in specific product and research contexts:
B2B SaaS Products
Enterprise software interviews often involve multiple stakeholders – the economic buyer, the end user, and the IT gatekeeper – each with different vocabularies for the same problems. Thematic coding across role types reveals where mental models align and where they diverge. That divergence is often where the real product problem lives.
If you’re running user research for B2B SaaS, the themes that matter most are rarely the ones users state explicitly – they’re the assumptions embedded in how they describe their current workflow.
Startup Feature Validation
Early-stage teams often use thematic coding on a small number of discovery interviews to validate whether a problem is real and widespread enough to build for. At this scale, manual coding with a simple spreadsheet is usually sufficient – the goal is directional clarity, not academic rigor.
For user research at startups, speed matters more than methodological perfection. A focused thematic analysis of eight interviews, done in two days, is more valuable than a comprehensive study that arrives after the sprint.
Product Management & Roadmap Prioritization
PMs use thematic coding to translate qualitative interview data into inputs for prioritization frameworks. The output isn’t just themes it’s themes mapped to user segments, pain severity, and frequency. That structure makes it much easier to argue for a feature investment based on evidence rather than advocacy.
See how user research for product management connects qualitative findings to roadmap decisions.
Agencies and Freelance Researchers
When you’re running qualitative research for multiple clients simultaneously, codebook reuse becomes a real efficiency question. A well-structured codebook from a previous engagement can be adapted rather than built from scratch, as long as you account for differences in context and user population.
Thematic coding for freelance researchers often comes down to standardizing enough to be efficient without templating so heavily that you stop seeing what’s new.
The Thematic Coding Starter Codebook (A Template for User Research)
Most thematic coding guides tell you to build your codebook from scratch. That’s good methodological advice, but it’s slow. Here’s a starting point for user research contexts a set of code categories that appear across most product interview datasets. Adapt, prune, and add codes specific to your research question.
Core Code Categories for Product Research
- Pain points: current_friction, workaround_in_use, unmet_expectation, cognitive_overload
- Decision drivers: trust_signal, social_proof, price_sensitivity, risk_perception
- Feature interaction: feature_adoption, feature_abandon, feature_discovery_failure, onboarding_gap
- Mental models: expectation_mismatch, prior_tool_comparison, jargon_confusion
- Sentiment markers: positive_surprise, frustration_expressed, resignation, delight
- Behavioural: workaround_in_use, task_abandonment, help_seeking, peer_consultation
These are starting codes, not final themes. Your job during analysis is to see which of these hold up across your specific dataset and what themes emerge from grouping them.
| Tip: Save this codebook as a reusable template in your QDA software or Notion database. After three to four research rounds, you’ll have a library of recurring codes that makes each new project faster to start and easier to compare against previous findings. |
Closing the Loop: From Thematic Coding to Product Decisions
Thematic coding is a means, not an end. The output needs to connect to something actionable a product decision, a roadmap argument, a design brief. That connection is clearest when themes are structured in terms of user impact and frequency. If you’re looking for a framework to understand how qualitative data fits into the broader user research process, the key is treating themes as inputs to decisions, not conclusions in themselves.
A theme that says “users experience pricing anxiety” tells you something is wrong. A theme that says “users experience pricing anxiety specifically at the moment they’re asked to add a card before seeing the product” tells you where to intervene.
That specificity comes from rigorous coding. Which means the method matters not because methodological purity is a virtue in itself, but because vague codes produce vague themes produce vague decisions. And product teams, frankly, have enough of those already.
If you’re doing this kind of research regularly and the bottleneck is getting enough data to code in the first place rather than the analysis itself that’s a different kind of problem, and one that tools like Articos are specifically built for.
| Skip the recruitment wait. Run your first research session in 30 minutes → Start free with Articos |
FAQs: Thematic Coding
Manually, yes especially for smaller datasets under 50,000 words. A spreadsheet with a well-maintained tag column and colour-coding by theme works fine for five to ten interviews. The tradeoff is time and consistency: the larger the corpus, the harder it becomes to keep codes stable across sessions without a tool to enforce your codebook. QDA software like NVivo or Dovetail isn’t required, but it removes a category of errors that’s easy to miss when you’re deep in the data.
It depends on what you’re optimizing for. NVivo and ATLAS.ti are the standard for academic and multi-method research. Dovetail is better suited to product and UX teams that need collaboration and simpler stakeholder reporting. Dedoose is worth considering if you’re combining qualitative and quantitative data. For lean teams on a budget, a structured Notion database with a clear tagging system covers most use cases at smaller scale.
The most common ones: confusing topics with themes (a topic organizes data; a theme makes a claim about it), coding to confirm rather than to discover, and skipping the review phase when timelines compress. The fix for most of these is building in explicit checkpoints compare your codes against the raw data at least twice, and have someone else spot-check a sample before you finalize anything.
Inductive when you’re exploring unfamiliar territory and want the data to shape the framework. Deductive when you’re testing a model or comparing against a previous study. Most user research projects benefit from starting inductively and then checking findings against any existing frameworks you get the discovery value of open coding with the comparability benefit of structured themes.
Most studies settle between 30 and 80 active codes, though this varies significantly by dataset size and research question breadth. A tight, focused study might need fewer than 20. A cross-functional research project covering product, support, and sales contexts might need more. The signal to watch for isn’t the number it’s whether your codes are doing distinct work. If two codes keep appearing on the same segments, they might need to be merged.
