Your NPS survey closed with 400 detractors, and each one typed a reason. Reading them gives you a feel for the problem, but not a finding you can take into a meeting. Thematic analysis turns that pile of text into a short list of themes, each with a count, a few real quotes and a clear next step. This guide covers the six phases, the difference between codes and themes, and a worked survey example with the arithmetic shown.
Key takeaways
- Thematic analysis finds, names and reports patterns of meaning in qualitative data, such as open-ended survey answers, interviews, reviews and support tickets.
- A code is a short label for one idea in one answer. A theme groups related codes into a pattern that answers your research question.
- The widely used six-phase approach is: get familiar with the data, generate initial codes, search for themes, review them, define and name them, then report.
- For surveys, report each theme as the share of respondents who mention it. One answer can carry several codes, so the percentages can add to more than 100%.
- Check reliability with a second coder on a sample, and back every theme with a count, quotes and a cut by segment.
What is thematic analysis?
Thematic analysis is one of the most common methods of qualitative data analysis. You read text, label the ideas in it, and group those labels into themes that say something about your question. It does not depend on a particular theory, so it works on almost any text a research team collects.
For market research and insights teams, the usual sources are:
- Open-ended survey answers. “Why did you give that score?” or “What one thing should we change?”
- Interviews and focus groups. Long transcripts where people explain their choices in their own words.
- Reviews and social posts. Unprompted comments about a brand or product.
- Support tickets and chat logs. Problems customers raise without being asked.
Scores tell you what happened. Open ends tell you why. If you are still deciding whether to ask open-ended questions at all, the trade-offs are covered in the benefits and challenges of open-ended survey questions. When reviews, tickets and survey comments are combined, the same method sits at the center of voice of customer analysis.
What is the difference between codes and themes?
A code is a short label attached to a piece of text. It captures one idea, close to the respondent’s own words. A theme is a broader pattern that groups several related codes and says what they mean together.
Take one answer: “I waited 40 minutes on hold and my problem still isn’t fixed.” It gets two codes, “slow to respond” and “problem not fixed”. Both belong to one theme, which you might name “Support is slow and does not resolve issues”.
| Code | Theme | |
|---|---|---|
| What it is | A label for one idea in one answer | A pattern that groups related codes |
| Level | Close to the words | Interpretive |
| Example | ”Recent price increase" | "Price has outrun perceived value” |
| How many | Dozens in a large study | Usually a handful per question |
| Question it answers | What did this person say? | What does this mean for us? |
Should you code inductively or deductively?
Inductive coding builds codes from the data, bottom up. You read the answers and let the labels come from what people say. Deductive coding starts from a codebook you already have, based on earlier research, a driver model or the business questions.
Most survey work is a mix. On the first wave of a new study, code inductively so you do not miss what you did not expect. On later waves, start from the existing codebook so results stay comparable, and add codes only when answers do not fit. The mechanics of building and applying codes, including how to write a codebook, are covered in our guide to qualitative coding.
What are the six phases of thematic analysis?
The widely used six-phase approach gives you a clear set of thematic analysis steps. In practice the phases loop: you will often go back to recode once a theme takes shape.
1. Familiarize yourself with the data
Read the answers before you label anything. With 400 answers, read them all. With 10,000, read a random sample of a few hundred and skim the rest. Note first impressions, and flag quirks such as blanks, “n/a” and answers in other languages.
2. Generate initial codes
Work through the answers one at a time and tag each idea. One answer can get several codes. Keep codes specific, and record each one in a codebook with a name, a one-line definition, what it includes and excludes, and an example answer.
3. Search for themes
Group codes that point to the same underlying issue. A spreadsheet with codes in one column and candidate themes in the next works well. Some codes will not fit anywhere yet, so park them in Other for now.
4. Review themes
Check two things. First, does each theme hang together, so that every answer coded to it fits? Second, do the themes together reflect the whole dataset?
Merge themes that overlap, split ones that hold two ideas, and look hard at Other. If it is large, a theme is missing.
5. Define and name themes
Write one or two sentences for each theme: what is in it, what is out, and why it matters. Name it as a finding, not a topic. “Price has outrun perceived value” tells a reader far more than “Price”.
6. Report
Rank themes by size or by business impact. For each one, give the count, two or three quotes and any segment differences, then say what to do next.
What does a thematic analysis example look like?
Here is an illustrative example, not a real study. A software subscription company asked customers how likely they were to recommend it on a 0 to 10 scale. Those who scored 0 to 6 were asked, “Why did you give that score?” There were 400 answers.
An analyst read all 400, built ten codes, and grouped them into four themes plus Other. Sixteen people gave no clear reason (“just because”, “n/a”), so they get their own row and stay in the base. Each respondent counts once in a theme, even if they mention several of its codes.
| Theme | Codes (respondents per code) | Respondents in theme | % of 400 |
|---|---|---|---|
| Price has outrun perceived value | Price too high (100), recent price increase (56), not worth the money (40) | 152 | 38% |
| Support is slow and does not resolve issues | Slow to respond (72), problem not fixed (60), unhelpful staff (20) | 120 | 30% |
| Outages and buggy updates erode trust | Outages (64), bugs after updates (40) | 88 | 22% |
| Getting started is too hard | Hard to set up (32), confusing to use (28) | 56 | 14% |
| Other | Various | 24 | 6% |
| No clear reason | None | 16 | 4% |
| Total mentions | 456 | 114% |
Here is the arithmetic behind the table:
- Theme share. Divide the people in the theme by everyone who answered. For price, 152 / 400 = 0.38, or 38%.
- Do not add up the codes. The three price codes sum to 100 + 56 + 40 = 196. The theme count is 152, because 196 − 152 = 44 of those code mentions are double counts from people who named more than one price code. Adding the codes would report 49% and overstate the theme.
- Expect more than 100%. The theme rows sum to 152 + 120 + 88 + 56 + 24 + 16 = 456 mentions across 400 people, or 456 / 400 = 1.14 themes per respondent. That is normal with multi-coding. Say so in a note under any chart.
The reading: price is the biggest single reason for a low score, but support is close behind. Reliability and onboarding are smaller and still worth an owner. The totals, though, hide who has which problem, which is where the segment cut comes in.
How do you check that your coding is reliable?
Coding is a judgment, so check your thematic analysis before you report numbers. Ask a second coder to code a random sample on their own, using the same codebook and without seeing the first coder’s work. Then compare the themes each coder gave each answer.
In the example, a colleague coded 100 of the 400 answers, a 25% sample. The two coders gave the same themes to 88 of them, so agreement is 88 / 100 = 88%.
The useful part is the other 12. Several were answers like “I pay a lot for something that keeps breaking”, which one coder filed under price and the other under reliability. The fix was a codebook rule: code both when both ideas are present.
Percent agreement is easy to explain, but it does not allow for agreement by chance. A chance-corrected measure such as Cohen’s kappa is worth adding when one theme is very common or very rare. Whichever you use, set the bar before you check, and recode if you fall short.
How should you report thematic analysis results?
Each theme needs three things in the report:
- A count, with the base stated. “152 of 400 detractors (38%) mentioned price”, not “many customers”. Say whether the base is everyone asked or only those who gave a reason.
- Quotes. Two or three verbatims per theme, chosen because they are typical, not because they are the most colorful.
- A cut by segment. Run the themes as a crosstab against the profile questions you already have.
Here is the example split by customer tenure.
| Theme | Customers under 1 year (n = 200) | Customers 1 year or more (n = 200) | Total (n = 400) |
|---|---|---|---|
| Price and value | 60 (30%) | 92 (46%) | 152 (38%) |
| Support | 58 (29%) | 62 (31%) | 120 (30%) |
| Reliability | 42 (21%) | 46 (23%) | 88 (22%) |
| Getting started | 42 (21%) | 14 (7%) | 56 (14%) |
Two different problems appear. Getting started is mostly a new-customer issue, at 21% against 7%. Price is mostly a long-tenure issue, at 46% against 30%.
With 200 in each group, a two-proportion z test gives z of about 4.0 for getting started and 3.3 for price, both well above the 1.96 needed at the 95% level. The 2-point gaps on support and reliability are within noise.
That points to two actions with two owners: fix onboarding for new customers, and show long-standing customers what they get for the price. Keep the codebook and the themed results somewhere the next team can find them. A research repository does that job, and connecting findings across studies and waves helps teams reuse what they know instead of starting over.
How is thematic analysis different for surveys and interviews?
The phases of thematic analysis are the same for both. What changes is the volume, the unit you code and what you report.
| Survey open ends | Interviews and focus groups | |
|---|---|---|
| Volume | Hundreds to thousands of short answers | A few to a few dozen long transcripts |
| Unit you code | The whole answer, often one to three ideas | Passages within a long conversation |
| Main output | Theme sizes as counts and %, cut by segment | Rich descriptions, quotes and how ideas connect |
| Codebook | Kept stable across waves for trends | Evolves during the study |
| Main risk | Shallow themes that restate the question | Over-reading a few vivid stories |
With interviews, avoid percentages. “Seven of twelve” is honest, while “58%” suggests a precision a dozen people cannot give. With surveys, the numbers are the point, so the codebook and the base matter more. For the survey case step by step, including cleaning blanks and setting up the code frame, see how to analyze open-ended survey responses.
Where does AI help with thematic analysis, and where does it need checks?
AI is good at the slow parts. It can suggest candidate codes from a first read, apply an agreed codebook across thousands of answers, handle several languages, and pull example quotes for each theme. That makes it practical to code every answer in a large tracker, not just a sample.
It needs checks in four places:
- Generic themes. Left alone, AI tends to produce topic labels such as “Pricing” and “Customer service” that restate the question.
- Merged issues. It may fold “slow to respond” and “problem not fixed” together, though they need different fixes.
- Context. Sarcasm, product names and in-house jargon can be misread.
- Counts and quotes. Verify that theme counts match the coded data and that every quote is a real verbatim.
Treat the AI as the first coder and yourself as the second. Run the same agreement check on a sample that you would run on a human colleague. We cover the workflow in detail in AI thematic analysis, and the wider picture, including crosstabs and summaries, in AI survey analysis. Once themes are coded, you can ask questions of your own research in plain language, with the source shown.
What are the common mistakes in thematic analysis?
These are the mistakes we see most often when a team codes open ends for the first time.
- Themes that are just question topics. “Price”, “Support” and “Product” restate the survey sections. Name what people are saying about each one.
- No codebook. Without written definitions, codes drift as you go, a second coder cannot match you, and next wave cannot be compared with this one.
- Reporting without counts or quotes. A theme with no size cannot be prioritized, and a theme with no quotes cannot be believed.
- Adding codes to get theme totals. People who mention two codes in one theme get counted twice. Count respondents per theme.
- Letting Other grow. If Other is one of your biggest rows, the analysis is not finished.
What should you do next?
Pick the open-ended question from your most recent survey. Read 50 answers, draft eight to twelve codes with one-line definitions, then code the rest and group the codes into themes named as findings. Ask a colleague to code a sample of 50 on their own and compare. If your open ends come from customer experience trackers, mTab gives CX teams a continuous view of satisfaction drivers across trackers, verbatims, reviews and support themes, so the themes you build become part of an ongoing picture rather than a one-off report.