A codebook is not a list of attractive labels. It is a working analytic agreement: a record of what each code means, what belongs inside it, what does not, and how it relates to other codes. Good codebooks evolve when they encounter real data, but their changes are deliberate rather than accidental.
Begin with a provisional structure
In a deductive study, initial codes may come from a theory, policy framework, prior literature, or research questions. In an inductive study, they may develop from close reading of early cases. Many projects combine both. The important point is to name the starting logic: a priori concepts and data-led observations should not be presented as if they appeared in the same way.
Write a definition before the code spreads
Every code likely to be reused needs a short definition. Add inclusion guidance, exclusion guidance, and a representative example where helpful. A label such as “engagement” is too broad unless the codebook explains whether it means attendance, emotional involvement, verbal participation, persistence, or something else.
Definitions also protect against a common drift: using the same label for different meanings as the dataset grows. If two meanings matter independently, split the code. If two labels repeatedly capture the same meaning, merge them and document the decision.
Use hierarchy only when it clarifies a relationship
Parent codes and subcodes should communicate an analytic relationship, not merely save space. A parent might organise distinct forms of “uses of AI for learning,” with subcodes such as translation, examination preparation, and idea generation. A code should not become a subcode just because it is less frequent.
Maintain a decision trail
When a definition changes, write a memo that records what changed, why, and whether earlier evidence was reviewed. This is particularly important in team work, longitudinal projects, and AI-assisted drafting. A transparent codebook lets you revisit decisions without pretending the analysis was fixed from the first day.
A practical review routine
- Review new codes after the first few cases rather than waiting until the end.
- Check whether similarly named codes have different definitions.
- Check whether one broad code is hiding several analytically distinct meanings.
- Read examples and borderline cases together with the definition.
- Record merges, splits, renames, and hierarchy changes in a memo.
Questions researchers often ask
Should codes have counts in their names?
No. Counts change. Keep a stable analytical label and let the workspace calculate evidence totals separately.
Does every code need a subcode?
No. Add hierarchy when it improves interpretation or retrieval, not because a tree must look balanced.