Qualitative Analysis

You turn many voices into a small number of well-evidenced themes without losing what people actually said. Every theme is traceable to coded excerpts, shows how many participants raised it, and carries quotes that represent it fairly, including the people who disagreed. The analysis is systematic enough that a colleague following your codebook would reach similar themes.

When to use

• "We did 12 customer interviews; what did we learn?"
• "Here are 800 open-text survey answers; summarise them."
• "What are customers complaining about in our reviews and tickets?"
• "Pull the themes out of these call notes."
• Making sense of feedback before a product or strategy decision.

What you need

• The data: transcripts, notes, survey exports, review or ticket exports, from a connected Google Drive, Notion, help desk or CRM, or uploaded files.
• The research objectives or the decision the analysis serves.
• Who the participants are (segment, role, tenure) as metadata, so themes can be compared across groups.
• Confirmation of consent and privacy terms for the data, and where it may be stored.

Method

1. Prepare the data. Put each participant or response in its own file or row with an ID (P01, P02, R0001). Remove or mask names, emails, phone numbers and other identifying details not needed for analysis. Keep metadata (segment, date) in a separate table keyed by ID. Store everything inside the workspace only.
2. Familiarise. Read everything once before coding (for large text sets, read a random sample of at least 100 items and skim the rest). Note first impressions separately, marked as impressions, so they do not quietly become conclusions.
3. Choose the approach:
   • inductive: codes come from the data; best for exploration
   • deductive: start from a framework or the research objectives; best for answering set questions
   • most projects use a hybrid: a few starting codes from the objectives, the rest emerging from the data
4. Code. Tag each meaningful excerpt with one or more short codes describing what it is about ("pricing confusion", "manual workaround", "trust in data"). Build a codebook as you go: code name, definition, when to use, when not to use, an example excerpt. Merge or split codes as the codebook settles. For hundreds of items, use execute_code to keep excerpts, codes and IDs in a table; for large sets, code a stratified sample by hand first, then apply the stable codebook to the rest and spot-check.
5. Check consistency. After a break, re-code a random 10 to 20% of the material without looking at your first codes and compare. Where you disagree with yourself, tighten the definitions. If a teammate is available, ask them (ask_teammate) to code the same sample with the codebook and discuss differences.
6. Build themes from codes. Group related codes into candidate themes: patterns of shared meaning that answer the research objectives, not just topic headings. "Customers distrust automated numbers until they can see the calculation" is a theme; "Reporting" is a topic. Affinity mapping helps: put excerpts or codes on a board (a document or whiteboard tool), cluster them by similarity, and name each cluster.
7. Review themes against the data. For each theme, re-read its excerpts: do they really belong together? Is there enough evidence? Does it overlap another theme? Look deliberately for negative cases: participants who said the opposite or did not fit. Keep them in the write-up.
8. Count carefully. Report prevalence as participants, not mentions: "7 of 12 participants". For small samples, never turn counts into percentages, and never imply the counts represent a wider population. For large open-text sets, percentages of respondents are fine, with the base stated.
9. Compare groups using the metadata: do themes differ between segments (new versus long-term customers, small versus large accounts)? Report differences only where the evidence is clear, and note small group sizes.
10. Pick quotes fairly. For each theme choose two or three quotes that represent the typical view, plus one that shows variation. Use participant IDs, not names. Do not edit quotes beyond removing filler words and identifying details, and mark any cut with an ellipsis.
11. Separate what people said from what they did. Stated preferences and reported behaviour are different kinds of evidence; label which a theme rests on.
12. Write the implications for the decision, clearly labelled as interpretation, and note what the data cannot tell you.

Codebook entry example

Code: manual-workaround
Definition: participant describes doing by hand, or with another tool, something they expected our product to do
Use when: a specific workaround is described (spreadsheet, copy-paste, a second app)
Do not use when: they only wish for a feature without describing what they do instead (use feature-wish)
Example: "Every Friday I export it to a spreadsheet and fix the totals myself." (P04)

Output

# What we heard: <study name>
Data: <n participants or responses, source, dates, segments>   Analyst: <you>   Date: <date>

## Summary
<4 to 6 sentences: the main themes, how widespread, and the implication for the decision.>

## Themes
### 1. <Theme stated as an insight>
Prevalence: <7 of 12 participants; strongest among ...>
What it is: <2 to 4 sentences>
Evidence: "<quote>" (P03) / "<quote>" (P09) / Counterpoint: "<quote>" (P11)
Based on: said | observed or reported behaviour

## Differences between groups
## Contradictions and open questions
## Implications (interpretation)
## Method and limitations
<Approach, codebook link, consistency check done, sample limits>

Attach the codebook and the coded excerpt table. Put the theme list with prevalence on a show_card.

Checks before you finish

• Every theme traces to coded excerpts with participant IDs.
• Prevalence is reported as participants, with the base; no percentages for small samples.
• Negative cases and contradictions are reported.
• Quotes are accurate, fairly chosen and de-identified.
• The codebook has definitions and examples.
• A consistency check was done and its result noted.
• Interpretation is labelled separately from findings.

Pitfalls

• Topics masquerading as themes. "Pricing" tells the reader nothing. Say what about pricing, and for whom.
• Loudest voice wins. One articulate participant can dominate; count participants, not quotes.
• Confirmation bias. Seeking the themes you expected. Search for disconfirming evidence on purpose.
• Cherry-picked quotes. A vivid but untypical quote misleads. Pick representative ones and show variation.
• Over-generalising. Twelve interviews explain why; they do not measure how many in the market.
• Leaking personal data. Transcripts often contain names and details; de-identify before sharing.
• Sign-off. The owner decides what to act on. Analyses involving employees, health or other sensitive data must be handled under the owner's privacy rules and shared only with people entitled to see them.

Credits: references/CREDITS.md.