Skip to content
PlagiatScanner.de
Research methods · template · MET-15

Create a qualitative coding guide

In brief: Define every code through its object, inclusion, exclusion, unit of analysis and relationship to neighbouring codes. Add a typical example, a similar-looking counterexample and a rule for boundary cases. Pilot the guide on varied material, record ambiguity and version every change. Whether codes are inductive, deductive or combined, and whether agreement is quantified, depends on the justified research design rather than a universal requirement.

Code–definition–example–counterexample frameworkSources reviewed 4 September 2026

Make analytical decisions visible

A code label alone is ambiguous. Trust, problem or support may refer to a topic, judgement, action or consequence. A guide states which observable property warrants assignment and how that property serves the research question.

Its purpose is consistent interpretation, not mechanical uniformity. Novel meaning and contradictory material must remain analysable. A useful definition bounds a code without pretending ambiguity can be eliminated.

The template can support different qualitative traditions. It imposes neither a number of codes nor statistical agreement. Such choices require methodological justification.

Authority asset: code–definition–example–counterexample framework

Completed fictional example: reasoned procedural criticism
CodeReasoned procedural criticism
DefinitionNegative judgement of a specific process with a stated reason or observed consequence.
IncludeProcess named; negative evaluation; reason or consequence present.
ExcludeGeneral dissatisfaction with no process reference.
Example“Feedback arrived after revision, so it could no longer be applied.”
Counterexample“Overall, I was dissatisfied with the course.”
Boundary ruleCode an implicit consequence only when context clearly identifies the process.
UnitMeaning unit; up to two adjacent sentences for resolution.

The material is fictional. The example and code exist only to demonstrate the framework.

Define the unit and context window

Decide whether a sentence, paragraph, speaker turn, image segment, document or event receives a code. A unit that is too small loses relationships; one that is too large blends phenomena. Specify how far coders may read for context and what exact passage is stored as coded.

Set rules for multiple coding, nested codes and repetition. Multiple codes may be appropriate for distinct analytical dimensions. Repetition may be counted once per meaning unit or once per event; the selected treatment needs a reason.

Non-verbal features, pauses and layout enter only where material quality and transcription rules support them. Missing information must not be interpreted automatically as absence of the phenomenon.

Sharpen definitions with counterexamples

An example shows a clear hit. A counterexample should look deliberately similar while lacking one necessary feature. Coders then learn the boundary as well as the centre.

Boundary rules handle recurring conflicts: explicit versus implicit, personal experience versus hearsay, intention versus effect, and general topic versus concrete action. Link neighbouring codes and state when both can apply.

Avoid definitions that repeat only the label. “Criticism: when criticism occurs” cannot guide a decision. Name semantic or observable criteria without treating a fixed keyword list as equivalent to meaning.

Pilot with deliberately varied material

Select clear items, difficult edges, different speakers or document types and material without the expected phenomenon. Coders first work independently and record not only disagreement but its source: definition, segmentation, context or tool operation.

Discuss cases against the written rule, not a desired outcome. Where the guide cannot resolve a decision, revise it and reassess affected pilot material. Consensus should not erase the original difference from the audit trail.

An agreement coefficient may serve some designs, but it does not prove interpretive validity. In reflexive approaches, structured analytical dialogue may be more appropriate. Report the process actually chosen and its purpose.

Version changes and application

Each version records date, responsible researchers, affected codes, reason and consequence for material already coded. Renaming, merging, splitting and adding a boundary rule are distinct actions. State which passages require reassessment.

Lock an analysis version for the main run or explicitly document an iterative approach. Silent changes cause similar passages to be treated under different rules. Export both guide and codebook in a readable format.

The methods parameter check reports application. The criteria log records material selection. Browse the research methods hub; the single foundation route is how verifiable checking works.

Test the finished guide on unseen cases

Before the main analysis, give coders several unseen items. For every assignment, they identify code, unit and decisive feature. If the decision depends on oral knowledge absent from the guide, add the missing principle and record the revision.

Inspect whether worked examples contain sensitive details. Anonymise only as far as meaning permits, and restrict access under the project plan. An example archive is research documentation, not automatically public material.

In the report, describe code development, piloting, revisions and use as concisely as possible but concretely enough to inspect. A full guide may sit in a permitted appendix or repository. Identify which version accompanies the reported analysis.

Finally sample codes that are conceptually close and cases assigned more than once. Check that the distinction or co-occurrence follows the written rule. Record uncertainty rather than forcing every passage into a category.

Official and scholarly foundations

  1. Saldaña: The Coding Manual for Qualitative Researchers – coding practice and analytical development.
  2. COREQ – reporting qualitative interview and focus-group research.
  3. German Research Foundation: Good Research Practice Code – documentation and traceability.

Sources reviewed 4 September 2026. Methodological decisions require project-specific justification.