Coding is the part of qualitative analysis where the anxiety lives. Ask a room of researchers how to code qualitative data and you will hear, underneath the different workflows, the same worry: the fear of flattening a rich, contradictory conversation into tidy labels that lose exactly the thing that made it worth having.
The worry is healthy, because it can happen. It is not inevitable. Coding qualitative data well is a craft with learnable habits: knowing what a code is actually for, choosing your stance before you start, keeping a codebook that holds up under pressure, and resisting the pull to abstract too early. This guide takes each in turn.
What a code actually is
A code is a short label that captures what a chunk of data means, not just what it mentions. That distinction does most of the work in good coding.
"Pricing" is a topic. "Treats price as a proxy for quality" is a code: it says something you could be wrong about, which is what makes it useful. If your codes are all topics, you have built an index, not an analysis. An index tells you where things were said; codes start telling you what is going on.
A few practical ground rules follow from that:
- Code at the level of an idea, usually a phrase to a few sentences, not whole paragraphs
- Let one excerpt carry several codes when several things are happening in it
- Code generously on the first pass and merge later; premature tidiness costs more than mess
- Write codes as small claims about meaning, not one-word subject headings
Codes are also not the finish line. They are the raw material that later gets grouped into themes, which is the territory of our step by step guide to thematic analysis. This article is about doing the coding itself well enough that the themes built on it can be trusted.
How to code qualitative data: pick your stance
Before you label a single line, decide where your codes will come from.
Deductive coding starts from a framework: your research questions, an existing model, the hypotheses the team is carrying. You define codes up front and apply them to the data. It is efficient, it keeps a big study consistent, and it answers the questions you actually came with. Its risk is force-fitting: data that does not match the frame gets squeezed into the nearest box or quietly ignored.
Inductive coding starts from the data. You read closely and label what you find, with as few preconceptions as you can manage. It is how genuinely new things get noticed. Its risk is drowning: without any structure you can end up with three hundred codes, half of them near-duplicates, and no way to see the wood.
In practice most good coding is a declared blend: a small deductive skeleton built from the research questions, with full permission to add inductive codes whenever the data does something the skeleton did not anticipate. The key word is declared. Say which stance you are taking and when, because it keeps you honest about whether you are discovering patterns or confirming them.
Build a codebook that holds up
A codebook is the difference between coding and vibes. For every code, record four things: a name, a one or two sentence definition, guidance on when to use it and when not to, and a real example excerpt from your data.
The "when not to use it" line pays for itself the moment two codes start bleeding into each other, which they always do. And the example excerpt keeps definitions anchored to the data rather than drifting toward what you wish the code meant.
Treat the codebook as a living document. Codes will merge, split, and get renamed as your understanding sharpens; keep a short log of those changes so you can retrace your steps. When the codebook stabilises, go back and recode the earliest transcripts, because you coded those with a cruder instrument than the one you have now.
If several people are coding, calibrate early: code the same transcript independently, compare, and argue. The disagreements are not friction, they are findings about how fuzzy your definitions still are. If you are coding alone, your future self is the second coder. A codebook clear enough that you-in-two-weeks applies it the same way is the standard to aim for.
Stay close to the data
The most common way nuance dies is premature abstraction: two interviews in, a promising pattern appears, and suddenly everything gets coded "trust issues". The label arrived before the evidence, and from then on it recruits data to itself.
Some habits that guard against it:
- Prefer the participant's own words early on. Coding a phrase like "I didn't want to look stupid in front of my team" as fear of looking stupid preserves something that "adoption barrier" destroys.
- Code what was said in context, not your explanation of it. Interpretation is a later, separate move, and it should be visible as a move.
- Keep excerpts attached to codes. A code you cannot trace back to specific passages and specific people is a hunch wearing a lanyard.
- Track how many participants a code spans, not how many excerpts it collects. A single enthusiastic participant can generate ten instances of a code, and that is still one person.
None of this is about refusing to abstract. Abstraction is the point, eventually. It is about earning each rung of the ladder, so that when a stakeholder pulls on a finding, the chain from claim to code to quote holds.
The nuance survives if you let it
Coding does not flatten qualitative data; rushing does. Codes are handles, not summaries, and the transcript remains the source of truth underneath them. Choose your stance openly, write definitions you could hand to a stranger, stay near the participants' language until the patterns are solid, and keep the trail from theme back to raw words unbroken. Do that and coding stops being the step where meaning leaks out, and becomes the step where you can finally see it.
People of Research is a community and newsletter for UX researchers, behavioural scientists, and everyone who turns transcripts into decisions. Join us and get the good stuff in your inbox.