All articles

Insights

How to turn a policy document into training people actually use

A six-step method for converting dense policy documents into training that changes behaviour, built on plain language and memory science.

Every L&D team knows the brief. A forty-page policy lands with a note from Legal or Risk: "Everyone needs training on this by end of quarter." The deadline is real, the policy is dense, and the path of least resistance glows invitingly: paste the policy into the authoring tool, add a Next button, attach a quiz.

The result technically exists. People technically complete it. Nothing changes, which everyone technically knew at the start.

There is a better way, and it isn't more expensive. It's a different order of operations, with one principle at the centre: the writing comes first, and the writing is the work.

Why "policy, but on screens" fails

A policy document and a piece of training have opposite jobs. The policy exists to be complete and defensible: every case covered, every term defined, organised by the logic of the subject. Training exists to be used: organised by the logic of someone's Tuesday, answering the only three questions learners bring: what do I do, when, and how do I know I've done it right?

When you ship the policy as the training, you ask every employee to individually perform the translation the organisation didn't. Some will. Most won't. There's a famous physics anecdote about this kind of translation being the true test of understanding: when a colleague asked Richard Feynman to explain a difficult result at a first-year level, he came back days later and admitted, "I couldn't do it. I couldn't reduce it to the freshman level. That means we don't really understand it." If your policy can't be explained at the level of the people it governs, the gap is in the explaining, and the explaining is exactly what training is for.

And the payoff for doing the translation properly is documented in one of plain language's most famous cases: when FedEx rewrote its ground operations manuals in plain language, employees found the correct answer 27 percentage points more often, in less time, saving an estimated US$400,000 in the first year. Nothing about the rules changed. Everything about the writing did.

The six-step conversion

Step 1: Mine the policy for decisions, not topics. Read the policy once, ignoring its structure, with a single question: what moments does this create in a real person's week? A privacy policy isn't twelve sections. It's perhaps seven moments: someone asks for data, you notice a breach, you're about to email a spreadsheet, and so on. List the moments. That list, not the policy's table of contents, is your curriculum. Most forty-page policies yield a surprisingly short list, which is the first piece of good news.

Step 2: Rewrite each decision in plain language. For each moment, write the operative guidance as if telling a capable new colleague across a desk: what to do, in what order, with what exceptions actually worth knowing. Short sentences, active voice, the action up front. This step is pure writing craft and it's where the FedEx-sized value lives. It's also the step most projects skip, because it's the one that looks least like progress in a tool.

Step 3: Wrap the decisions in scenarios. Adults learn judgement from cases, not clauses. Turn each decision into a scenario with the texture of reality: time pressure, an awkward power dynamic, options that all cost something. Let learners choose, then show the consequence before the explanation. The aim isn't to trick them. It's to let them rehearse the moment safely, so the real moment feels like the second time.

Step 4: Chunk it small and space it out. Resist the single monolithic module. Memory research is unambiguous here: the forgetting curve erodes most unreinforced learning within days, while a meta-analysis of over 14,000 participants found spaced practice beat massed practice 47.3% to 36.7% with identical study time. Five short pieces across two months will outperform one long module by design, not luck. Each piece should fit inside a coffee.

Step 5: Test with retrieval, not recognition. Quiz questions should make people retrieve and apply, because testing itself strengthens long-term retention more than re-studying does. "A contractor asks for the site access codes over the phone. What's your first move?" exercises the exact muscle the policy needs exercised. True-or-false questions about the policy's definitions exercise the muscle of sighing.

Step 6: Keep the policy one tap away. Training doesn't replace the policy. It teaches people when to reach for it. End every scenario with the pointer: where the full document lives, which section covers this, who to ask when reality outruns the examples. The policy becomes what it always should have been: a reference, consulted by people who now know what they're looking for.

The quiet step zero: fix the policy too

Here's the bonus most organisations stumble into. Step 2's plain language rewrite regularly reveals that the policy itself is unclear: terms that conflict, steps with no owner, exceptions nobody can operationalise. Feed that discovery back. The best training projects we've done have quietly improved the source document as a side effect, and the version of this work where the policy itself gets the plain language treatment multiplies everything downstream: comprehension, compliance and considerably fewer queries to its unfortunate owner.

The summary you can put in the project brief

Don't build the policy. Build the seven moments it creates, written like a human, rehearsed as scenarios, spaced across the calendar, tested by retrieval, linked back to the source. The deadline pressure is real, but so is this: a module nobody uses meets no deadline that matters.

It's the approach behind our digital learning work, and the writing skills underneath it are teachable to your own team. The binder-to-behaviour gap is bridgeable. The bridge is made of writing.