What coding is for

The workshop produces material: journeys, touch points, quotes, and the reasons people gave. Coding turns that material into a needs analysis you can argue from. It answers three questions, and the whole point is to keep them apart.

1. What has to change in a person for the behaviour to change?
2. Through what mechanism would that change happen?
3. What in the organisation is holding the current pattern in place?

Question one is the Theoretical Domains Framework. Question two is answered through the same framework, not a rival one: the mechanisms of action are an extension of the TDF. The list used by the Theory and Techniques Tool is the 14 TDF domains plus 12 further constructs drawn from a set of 83 theories of behaviour change, 26 mechanisms in all, which is why a TDF-coded determinant can be carried straight into the tool. Question three is CFIR, and that is the genuinely separate framework here, because it moves from the person to the organisation and the wider setting. The material from a service pathway contains all of it mixed together. The point of coding is not to run three frameworks for their own sake, but to keep a system condition from being coded as individual psychology.

Coding is where a project becomes defensible or quietly becomes an opinion. Everything downstream rests on it: the causal loop diagram is built from the coded determinants, and the leverage analysis is built from the diagram.

What is coded, and at which level

Keep the levels separate at the point of coding. A system condition coded as individual psychology is the most common error in this step, and it is the one that makes the rest of the method unreliable.

Where the mechanisms of action list comes from

The list is not a separate framework sitting beside the TDF. In the study that produced the links, the coding was guided by a set of 26 general mechanisms of action: the 14 domains from the Theoretical Domains Framework, plus the 12 additional most frequent mechanism constructs from a set of 83 theories of behaviour change (Carey et al. 2019, Annals of Behavioral Medicine 53(8):693-707, PMID 30304386). The Theory and Techniques Tool then operationalises the technique-to-mechanism links. So the practical route is one framework with an extension: code the material to the 14 domains, then use the mechanism list to name the route, then ask the tool which techniques are associated with that mechanism.

The 14 TDF domains

Code only against these names. Definitions differ subtly from the everyday meaning of the words, so take the definition from the framework itself rather than from memory.

1. Knowledge
2. Skills
3. Social/Professional Role and Identity
4. Beliefs about Capabilities
5. Optimism
6. Beliefs about Consequences
7. Reinforcement
8. Intentions
9. Goals
10. Memory, Attention and Decision Processes
11. Environmental Context and Resources
12. Social Influences
13. Emotion
14. Behavioural Regulation

Note two of them in particular. Environmental Context and Resources and Social Influences hold material that looks individual but is not, so check whether the quote is about this person or about the situation everyone is in. Emotion is where the touch point work pays off, so do not collapse it into a general finding about morale.

The coding rules

Ten rules. They are written to be applied mechanically, because the temptation at each one is to make the output look better than the material allows.

1. Every code names an actor and a behaviour. A domain label on its own is not a finding. Say who, doing what.
2. Every code has a quote and a location. If you cannot find the source, the item does not exist.
3. Give a confidence. High if it is explicit in the material, medium if it is implied with the working shown, low if it is a single weak mention.
4. Record overlaps. Where an item fits two domains, list both and say what the overlap is. Do not force it into one.
5. Keep a no-domain bucket. Items that fit nothing stay uncoded. That bucket is a legitimate output, and often the most interesting one.
6. Keep system findings at system level. If the material describes a service condition rather than a person's behaviour, say so. Do not reduce it to a person's psychology.
7. Report the empty domains. A domain with no items is a finding about the material, not a gap to fill.
8. Code twice. Two people code the same material independently, then reconcile. The prompt library exists to support this, not to replace the second coder.
9. Report the disagreements. Where the two coders do not converge, that disagreement is a finding about how hard the material is to code. Do not average it away.
10. Do not rewrite the quotes. Framework language goes in the code column. The material stays in its own words.

What a linkage tool does and does not tell you

Once determinants are coded, a linkage tool offers candidate techniques. Use one. Do not use your own opinion of which technique suits which determinant.

The Theory and Techniques Tool links behaviour change techniques to mechanisms of action, built from a literature synthesis and an expert consensus exercise, with the agreement between the two shown for each link. Read plainly, it shows that experts and the published literature associate a given technique with a given mechanism. It does not show that the technique works, and it does not show that it would work in your service, with your staff, at this step of your pathway. A cell with no link in the tool is an answer too. The correct output there is "no linkage in the tool", not a plausible substitute.

The CFIR-ERIC matching tool does the same job at the organisational level. It maps CFIR barriers to implementation strategies, and it tiers its recommendations: level one where more than half the expert panel endorsed the strategy for that barrier, level two where 20 to 50 per cent did. Two practical points follow. Never present a level two strategy as though it were level one. And remember that the tool encodes expert consensus about which strategies address which barriers, not trial evidence that a strategy produces change. A scoping review of studies using the tool found that the great majority used it to formulate strategies and fewer than one in ten evaluated whether they worked. That is the pattern to plan against, not a property of your project.

Where a recommended strategy is not feasible in your service, write that down and say why. An infeasible recommendation reported as a plan is worse than no recommendation at all.

Where coding goes wrong

Four failure modes are predictable enough to check for by name.

• Drift. The same quote, coded by two competent people, lands in different domains, because the domain boundaries are aggregated and the words are broad. This is why the second coder and the disagreement report exist.
• Category instead of cause. A domain is a bin that holds many constructs from many theories. It is not a mechanism. Treating a domain as though it were the thing that causes behaviour produces a list that cannot be tested.
• Long lists with no ranking. A needs analysis reporting barriers in eight domains has not said which one matters most. Ranking is the leverage step's job.
• Coding to the answer you already want. If a technique or a service change is already planned, the material tends to get coded towards it. Have the codes reviewed by someone with no stake in the intervention.

The check before anything is used

Run one check across every output of the coding step, before the diagram or the logic model is built on it. For each claim: quote the material it rests on, and mark it as stated, implied or unsupported. Move the unsupported claims out. Check every framework term against the framework's own list, and report any term that is not there. Then say plainly what the output asserts without evidence, and what the material contains that the output left out.

That check is unglamorous and it is the one that keeps the rest of the method honest. If a team only does one thing on this page, do that.