Coding in NVivo: Nodes, Cases, and Coding Stripes

Most NVivo tutorials walk through menus. This one is about the data structure underneath the menus: nodes and cases are two different kinds of container that NVivo happens to display the same way, and mixing them up is the single most common reason a project has to be re-coded halfway through. Coding stripes are the other half of the picture — the visual layer that lets you (or a second coder) actually check what got coded, instead of trusting that it did.

Nodes and cases are different structures, not two names for the same thing

In NVivo, coding means linking a segment of source material — a paragraph of a transcript, a stretch of a recording, a region of an image — to a container that represents something about that segment. Both nodes and cases are that kind of container, and technically a case is a node under the hood. The distinction that matters is what each one is organizing around:

• A node organizes by content. It represents a theme, concept, or category — “barriers to data sharing,” “trust in the interviewer,” “resistance to change.” You code a passage to a node because of what it’s about, and the same passage can carry several node codes at once if it touches several themes.
• A case organizes by source. It represents a unit of analysis — a participant, a site, an organization, a document — and it typically holds everything from or about that unit: a whole interview transcript, a set of field notes, several related documents. You attach a case to a passage (or a whole source) because of who or where it came from, not what it says.

The practical payoff of that split is case classifications: a case can carry an attribute sheet (career stage, discipline, site, condition, role — whatever your design calls for), the same way a spreadsheet row carries columns. Nodes can’t do that on their own. Once your participants exist as cases with classifications attached, you can cross a thematic node against an attribute — does “resistance to change” code differently for early-career versus senior staff, or across two study sites — without manually re-sorting anything. That comparison is the entire reason to set up cases deliberately rather than as an afterthought.

When to use a node vs. a case

Ask what the container is standing in for. If the honest answer is a topic or theme, it’s a node. If the honest answer is a person, place, or document, it’s a case. A few patterns that hold up across most qualitative designs:

• One case per participant (or per site, if the study is organized by site rather than by person). This is the default for interview-based and most mixed-methods designs. Attach the whole transcript to the case, then code passages within it to thematic nodes as usual.
• Don’t create a node per participant. This is the most common misuse — it looks harmless early on, but it throws away the attribute-comparison capability that cases exist for, and it clutters the node hierarchy with entries that aren’t themes at all.
• Don’t create a case per theme. The inverse mistake, usually from researchers coming from a flatter coding tool without the node/case split — it collapses the thematic structure into something that can’t be queried the way a real node hierarchy can (child nodes, hierarchical rollups, coding-density comparisons across sub-themes).
• Documents that aren’t tied to a single person — a policy, a meeting minute set, a public dataset — can still be cases if your design treats each document as a unit of comparison (e.g., comparing policy documents by jurisdiction). If there’s no unit of comparison, it’s just a source, and it doesn’t need to be a case at all.

Decide the case-classification scheme (which attributes you’ll track, and their possible values) as early as possible. Retrofitting attributes onto dozens of already-created cases later is tedious and easy to do inconsistently across a team; setting it up as a short classification sheet before coding starts costs almost nothing.

Coding stripes: what they show, and what they don’t

Coding stripes are the coloured bars that run down the margin of a source when you open it — one stripe per node that’s been applied, aligned to the exact passage it covers. They’re a read-only view of coding that already exists, not a coding action themselves: toggling which stripes are visible changes what you can see, never what’s actually coded.

What they’re for, in practice:

• Coverage checking. Scroll a transcript with stripes on and you can see at a glance whether a section has been coded at all, or sits blank — a fast way to catch a passage that got skipped, especially in a long source coded across multiple sittings.
• Density and overlap. Passages with many stacked stripes are where several themes converge — often the richest material, and worth a second look regardless of what the codebook says should be there.
• A first-pass reliability check. Before running a formal coding comparison between two coders, opening the same source with each coder’s stripes visible side by side (or toggled) is a fast eyeball pass: wildly different stripe patterns on the same material are worth discussing before you spend time on a statistic, and tight agreement in the stripes is a reasonable signal that the formal comparison will come back clean too.

Stripes are a source-first view — you’re looking at one document and seeing which themes touch it. That’s the opposite direction from asking “show me everything coded to this one node,” which pulls coded excerpts together across every source instead. Both views matter for spot-checking: stripes catch coverage and consistency problems within a document; the node-level view catches whether a code has drifted in meaning across a project as different passages accumulate under it.

From stripes to a reliability number

Coding stripes tell you where to look; they don’t produce a statistic. When a project needs a documented reliability figure — increasingly expected in methods sections and by reviewers — the mechanism is a coding comparison between two coders who worked the same content independently, which returns a per-node agreement coefficient (Cohen’s kappa is the standard output for this kind of two-coder categorical comparison). Two things matter for that number to mean anything: the coders have to code independently before comparing (stripes visible to only one coder at a time during that pass, not shared), and the comparison has to run on a genuinely shared subset of material, not the full set coded by whoever happened to touch it last.

Choosing and interpreting the coefficient itself — kappa’s known paradox where high raw agreement can still produce a low or negative kappa, when to use a weighted or multi-rater variant, what counts as an adequate score — is its own topic; see Inter-Rater Reliability: Choosing the Right Coefficient for the full decision path rather than repeating it here.

A coding workflow that survives a second coder

Most of the pain in team coding comes from decisions made — or not made — before coding starts, not from the software itself:

1. Set up cases and classifications before coding begins. Get participants (or sites, or documents) into the project as cases with their attributes attached first. Coding against a stable case structure is far less error-prone than coding first and sorting sources into cases afterward.
2. Write operational definitions for each node, not just labels. “Resistance to change” needs an inclusion rule a second coder can apply the same way you would, not just a name in the hierarchy. This is the actual codebook; the node tree in NVivo is just where it lives.
3. Code a shared subset independently first. Have each coder work the same handful of sources without seeing the other’s stripes, then run the comparison. Fixing systematic disagreement on a small subset is cheap; finding it after the full dataset is coded is not.
4. Use stripes as a running audit, not a one-time check. Spot-check coverage and density periodically through the project rather than only at the end — a node that’s drifted in how it’s being applied is easier to correct in week two than after the last transcript is coded.
5. Revise the node definitions, not just the disagreements, when kappa comes back low. A low score on a specific node is usually telling you the operational definition was ambiguous, not that one coder was careless. Refine the definition, recode the shared subset, and re-run the comparison before treating the number as final.

For a worked example of turning raw transcript text into a coded structure — independent of which software you use — see Coding Qualitative Interview Data: A Worked-Example Guide. For where NVivo fits among the broader qualitative-analysis-software landscape, including AI-assisted coding suggestions in current versions, see NVivo: Qualitative Data Analysis Software for Research and AI in qualitative coding.

Frequently asked questions

What’s the actual difference between a node and a case in NVivo?

A node organizes by theme or concept — what a passage is about. A case organizes by source unit — a participant, site, or document. A case is technically a special kind of node, but the distinction that matters for your project structure is what you’re grouping around: content, or unit of analysis.

Is a case a type of node, or something separate?

A case is a node with an attached classification (attribute sheet). Everything a node can do, a case can do; a case additionally carries structured attributes that let you cross thematic coding against demographic or categorical variables.

Do coding stripes change what’s coded, or just what’s visible?

Only what’s visible. Turning stripes on or off, or filtering which nodes’ stripes show, is a display setting — it never adds, removes, or alters coding. The stripes reflect coding that already exists in the project.

How do I check inter-coder reliability in NVivo?

Have two coders code the same content independently, then run a coding comparison between their work. It returns a per-node agreement coefficient (Cohen’s kappa for a standard two-coder categorical comparison). See Inter-Rater Reliability: Choosing the Right Coefficient for how to interpret the result.

Should every participant automatically be a case?

In most interview- or participant-based designs, yes — one case per participant is the standard default, since it’s what makes attribute-based comparison possible later. It’s less automatic for designs organized around documents rather than people; the test is whether the unit is something you’ll want to compare across, not just store.