To code qualitative data, read your transcripts closely, attach short labels (codes) to meaningful passages, group related codes into categories, and then develop themes that answer your research question. Keep a codebook and notes so every claim can be traced back to the participant's words.
Coding is the step students most often rush and then cannot explain at the defence. UniDraft helps organise your confirmed method, coded extracts, checked sources and supervisor instructions into an editable Word project document. Start your project document, then do the coding yourself and be ready to show how each finding was reached.
What does "coding" mean in qualitative research?
Coding means labelling parts of your data so you can find, compare and interpret them. A code is a handle on a passage. It is not the finding itself. The finding comes from what the grouped passages, read together, tell you about your question.
Terms are not used identically everywhere, which is why supervisors sometimes seem to disagree. Erlingsson and Brysiewicz, in a methodological paper on qualitative content analysis, describe a path from meaning units (chunks of text carrying one idea) to condensed meaning units, then codes, categories and themes. They describe codes as short labels, categories as groups of related codes that capture what is visible in the text, and themes as higher-level ideas about underlying meaning. Braun and Clarke, writing about reflexive thematic analysis, also treat codes as narrower than themes, but they build themes in a different way and do not use a fixed codebook. Pick the definitions of the approach you cite, and use them consistently.
This post is about the practical mechanics of coding. For the wider method, see the guide to thematic analysis; for coding documents against explicit rules, see content analysis.
To decide whether a qualitative design fits at all, read the qualitative methods overview first.
Codes, categories and themes: how are they different?
| Level | What it is | Typical wording | Question it helps answer |
|---|---|---|---|
| Code | A short label on one passage | "Waiting for power", "Borrowing a generator" | What is this passage about? |
| Category | A group of related codes | "Coping strategies" | What kinds of things are in the data? |
| Theme | An organising idea that explains a pattern | "Students plan their work around supply they cannot control" | What does this pattern mean for my question? |
A common mistake is to stop at categories and call them themes. A topic heading such as "Challenges" or "Coping" tells the reader what the data is about. A theme makes a point about it. Erlingsson and Brysiewicz also note that overlapping categories usually mean the jump from codes to categories was too big; forming narrower sub-categories first can help.
Open coding or structured coding: which should you use?
Sources on thematic coding describe a range. Coding can be inductive (labels come from the data), deductive (labels come from a framework or theory you chose before reading), or a mix. Braun and Clarke's FAQ page treats these as flexible rather than rigid, but says you should describe honestly what you did: if you started from a framework, say your analysis was deductive.
| Approach | When it suits | Watch out for |
|---|---|---|
| Open (inductive) coding | Exploring experiences when little is known, or when your supervisor wants themes built from the data | Dozens of near-duplicate codes; losing track of your research question |
| Structured (deductive) coding | Testing or applying a framework from your literature review | Forcing data into boxes; ignoring passages that do not fit |
| Hybrid | Starting with a few framework codes and adding new ones as the data demands | Not recording which codes were planned and which emerged |
Your choice should follow from your research questions and your framework. If you are unsure how the framework connects to your study, the guide to conceptual and theoretical frameworks helps. Agree the approach with your supervisor before you start, because it changes what your methodology chapter must say.
What is a codebook, and do you need one?
A codebook is a document listing each code with a name, a definition and, usually, when to use it, when not to, and an example. It helps you apply the same label to the same kind of passage on day one and day ten.
Whether you need one depends on your approach. Structured and framework-driven coding generally use a codebook early. Braun and Clarke's reflexive thematic analysis deliberately avoids a fixed codebook, because it treats coding as evolving interpretation; they note that agreement scores between coders show coders were trained to code alike, not that the coding is more accurate. So do not add a codebook, a second coder or an agreement statistic just because another project had one, and do not borrow a "required" agreement percentage from somewhere. Choose the quality checks that fit your approach and discuss them with your supervisor.
Even in an open approach, a simple running list of your codes with a one-line meaning is useful. Think of it as a working glossary rather than a rulebook. A minimal entry looks like this:
| Field | Example (fictional) |
|---|---|
| Code name | Planning around supply |
| Definition | Participant describes scheduling work around when power or data is available |
| Include when | The adjustment is described as a deliberate choice |
| Exclude when | The participant only complains about the problem without changing behaviour |
| Example extract | P03: "I do the typing at night when light is stable." |
| Version note | Split from "Coping" in version 2 |
Should you code by hand, in a spreadsheet or in software?
All three can work. What matters is that you can retrieve every passage under a code and trace it back to the transcript.
By hand (printed or in Word). Highlight, annotate in the margin or use Word comments for codes. It is cheap and keeps you close to the text. It becomes slow to regroup once you have many transcripts. Braun and Clarke's site mentions a Word macro (by Babbage and Terry) that exports Word comments and their text to Excel for theme development, which can make a Word-based workflow easier to organise.
In a spreadsheet. One row per coded extract, with columns for participant code, location in the transcript, the extract, the code and a note. Filtering the sheet by code gives you everything under that label. It is a sensible, free route for a small study.
In software. Qualitative data analysis packages let you import transcripts, select passages and attach codes, then retrieve and group them. From the vendors' own pages I opened: NVivo (from Lumivero) is a paid product with individual and student options that depend on the plan, and ATLAS.ti supports organising and analysing interviews, focus groups, surveys and media, and lets you arrange codes in a hierarchy. Taguette is a free, open-source tool where you import documents, highlight passages and attach tags, and it can export a codebook and tagged quotes; it can run on your own computer. Both NVivo and ATLAS.ti now advertise AI-assisted coding. Be careful there: uploading participant transcripts to any online or AI feature may breach your consent and ethics arrangements, and automated suggestions still need your judgement. Check what your ethics approval allows before you use it, and see the guide to research ethics and consent.
Software does not analyse your data. Braun and Clarke's FAQ says NVivo is compatible with reflexive thematic analysis if you use it to list and cluster codes, not as a fixed scheme, and warns against treating early code layers as the final analysis. If your department provides a licence or training, use it. If not, a spreadsheet is a respectable choice; say in your methodology what you used and why.
How do you code, step by step?
- Prepare the transcripts. Check them against the recording, use participant codes instead of names and keep line or paragraph numbers. The interview guide post covers planning the handover from recording to analysis.
- Read everything first. Note your first impressions in a memo before you label anything. Keep your research question visible.
- Code a small set closely. Go through one or two transcripts line by line. Short labels, close to the participant's words. Code anything relevant, not only what you expected.
- Review and tidy codes. Merge duplicates, split codes that mix two ideas, rename vague labels. Record each change.
- Code the rest, revisiting earlier transcripts. Because your codes change, earlier transcripts may need recoding. This is normal.
- Group codes into categories. Look for shared meaning, not shared vocabulary.
- Build themes. Ask what each group explains about your question. Test each theme against passages that do not fit.
- Write up with extracts. Present each theme with an explanation and suitable anonymised quotations.
How do you keep an audit trail?
An audit trail is the set of records that lets someone else (your supervisor, an examiner) follow how you got from transcripts to themes. Erlingsson and Brysiewicz advise noting your reasons for key coding choices, going back to the original text when a label seems wrong, and using tables to track progression from raw data to categories and themes. They also suggest comparing your reading with a colleague's to surface alternative interpretations; that is a reflection tool, not necessarily a formal agreement test.
You do not need all of these in elaborate form. A tidy folder, dated file versions and a short memo whenever you change something are enough for most undergraduate projects. Your confirmed notes also make the methodology chapter much easier to write; see the guide to writing the methodology.
A fictional worked example
Everything below is invented for teaching. There are no real participants, recordings or findings. Imagine a study of how final-year students keep project work going despite unreliable electricity and mobile data. Three fictional transcript lines:
- P01: "I charge the laptop at the library and write there until it closes. After that I only do offline stuff, like reading printed papers."
- P02: "When the network is bad I just wait. Sometimes I lose a whole day. My supervisor does not know that is why I'm late."
- P03: "I buy data at night when it's cheaper, so I download everything then and work from the files the next day."
First pass, open codes:
| Extract | Code |
|---|---|
| "charge the laptop at the library" | Using a shared charging place |
| "only do offline stuff" | Switching to offline tasks |
| "I just wait" | Waiting for supply |
| "lose a whole day" | Lost time |
| "supervisor does not know" | Reasons not shared with supervisor |
| "buy data at night when it's cheaper" | Timing data purchase |
| "download everything then" | Downloading in advance |
Second pass, categories:
| Category | Codes in it |
|---|---|
| Adjusting where and when to work | Using a shared charging place; Timing data purchase |
| Shifting the kind of task | Switching to offline tasks; Downloading in advance |
| Absorbing the loss | Waiting for supply; Lost time |
| Communication | Reasons not shared with supervisor |
Candidate theme (to be tested): "Students plan around the supply problem privately instead of reporting it." It links the adjusting categories with the fact that the delay is not shared with the supervisor. Notice it is a claim, and three lines cannot establish it. With real data you would search all transcripts for students who did tell their supervisors, and for contradictions. If you find them, the theme needs rewording or a second theme. Also notice "Lost time" could sit in two categories; decide, record why, and keep the decision consistent.
This is a teaching illustration, not an answer key, and nothing here should be copied into a real findings chapter. A different research question could justify different labels.
Common mistakes when coding qualitative data
- Treating a list of quotations as analysis. Quotations support an interpretation; they are not the interpretation.
- Calling topic headings themes. "Challenges" is a topic. Ask what the group of passages explains.
- Coding what you hoped to find. Code everything relevant, then check your expectations against the data.
- Unrecorded changes. If you merge or rename codes without a note, you cannot explain your process at the defence.
- Counting as proof. Saying "7 of 10 participants" can describe your sample, but it does not make a theme important or representative of all students.
- Mixing incompatible claims. Do not claim a reflexive approach while using a fixed codebook and agreement score, or the reverse. Name the approach accurately.
- Putting identifiable details into extracts. A job title, place and event can identify someone even without a name.
- Letting software or AI suggestions stand in for reading. Auto-generated codes still need you to check them against the passages.
Questions your supervisor or panel may ask
- How did you decide what counted as a code?
- Did your codes change during analysis, and how did you record that?
- Which passages did not fit your themes, and what did you do with them?
- Were your codes decided before or after reading the data?
- Why is this a theme and not just a category?
- What did you use to organise the coding, and why?
Rehearse short, honest answers backed by your records. The same preparation helps with common defence questions.
Where the coding fits in your project
Once the coding is stable, write the findings as an argument: introduce the theme, explain it, show a suitable anonymised extract and interpret it. The results chapter guide covers placement and presentation. If you are also combining numbers with interview material, see mixed-methods research.
When your coding, notes and extracts are confirmed, prepare your project document with UniDraft. It organises what you supply, in line with your supervisor's instructions, into an editable Word file; the interpretation and the defence of it remain yours. For how your department wants the chapter laid out, follow your supervisor and check the format guides.
Sources
- Erlingsson and Brysiewicz: A hands-on guide to doing content analysis, African Journal of Emergency Medicine, for meaning units, codes, categories, themes and record-keeping advice.
- Braun and Clarke: Thematic analysis FAQs, for codes versus themes, codebooks, inductive and deductive coding, and software comments.
- Taguette, for its description as a free, open-source tagging tool.
- NVivo by Lumivero and ATLAS.ti, for the vendors' own descriptions of their products.