Why the hardest part of the task is often the document.
An operator reaches the bottom of a page, turns it, and is presented with a map of equipment. Their task is to confirm that every item listed in the step they have just read appears on that map. The list was embedded in a paragraph, so it has no discrete items to work through. The map has no numbering that corresponds to the list. They now have to hold a set of names in their head, search a diagram for each one, and turn back and forth to check they have not lost their place.
Nobody designed that. It emerged from a page break.
The question
This piece started with a question in a training room. Someone asked why their people find procedures such hard work, when the procedures are technically correct, fully compliant and reviewed within date. It is a good question, and answering it properly took longer than the session allowed, which is usually the sign of a question worth writing about.
The short version is this. A procedure imposes a cost on the person using it, and that cost is separate from the difficulty of the work itself. Call it procedure burden. It is designed in, it is paid on every execution by every user, and in most organisations nobody owns it.
Cognitive Load Theory makes the distinction that matters here. Intrinsic load is the difficulty inherent in the task: the variables, the precision, the consequences. Extraneous load is everything the presentation adds on top. Working memory is limited, and the two draw on the same account.
Your procedure is competing with the task for the same resource. Every unit of attention spent decoding the document is a unit not spent on the plant, the batch, the product or the hazard. A procedure that is hard to use does not merely slow the work down. It degrades the quality of attention available to do the work safely.
Where the thinking actually happens
That framing is useful, but it is only half the story, because it treats the head as the place where the work gets done. It is not. Anyone who has watched a control room, a shop floor or an ambulance crew knows the thinking is spread across the whole system: the document, the labels on the plant, the marks on the page, the colleague who says “not that one, the one behind it”.
This is what distributed cognition gets right. The cognitive system is not the operator. It is the operator plus everything they are using to think with. Information propagates across those media, and the design question is not “can they remember this?” but “where in this system does this piece of information live, and how does it reach the person who needs it, at the moment they need it?”
Which changes how you read the small stuff. A tick box is not administration, it is the system remembering on the operator’s behalf. A number on a map is not decoration, it is the diagram doing part of the work so the head does not have to. A step written as a discrete instruction is a unit of thinking the document has done in advance.
Strip those out and you have not simply made the document less pleasant. You have removed cognitive machinery from the system and pushed the work back into the component with the least capacity and the worst reliability: human working memory, on shift, under time pressure.
Ten things that create burden
Read as a list these look like ten separate defects. They are not. They stack, which is the point the page break example makes later.
- Prose instead of steps. Paragraphs force the user to extract the actions before they can do them.
A verbose description containing four things to check, buried in a sentence. The user has to pick the items out and build the list themselves, hold it while they work, and has nothing to mark off as they go. - Critical steps not identified. The user has to reconstruct the risk model from scratch, every time.
This is common even on genuinely critical tasks. Ask an operator which step on the page could hurt them, or ruin the batch, and often they cannot say. They are managing a risk nobody has told them about. - Cross-references. Every jump to another section, page or document splits attention across sources.
“Isolate in accordance with SOP-114”, where SOP-114 lives on a different system. The reference is either a five-minute detour or it is quietly skipped, and you will not find out which. - Undefined icons and colours. Symbol systems designed once and never taught become memory tasks.
I have seen documents carrying fifteen to twenty distinct icons, with up to four sitting on a single step. Some marked genuinely critical information. Most were decoration. The result is that the critical ones are lost in a sea of icons, which is arguably worse than having none at all. - Everything emphasised. When all detail carries equal weight, nothing stands out as mattering more.
Page after page of bold warnings, so the one that genuinely matters looks exactly like the forty that do not, and the user stops reading any of them. - Step organisation. Steps are ungrouped or poorly sequenced, so the user has to work out the shape of the task.
The worst I have seen is a flat list of seventy steps with no grouping whatsoever. No phases, no sub-headings, no sense of where you are, what you have finished, or how much is still to come. - Jargon and legacy terminology. Words nobody would use in speech require translation before comprehension.
And words only some people would use in speech. “Crack it open” and “wang it open” both appear in real procedures. Everyone on the shift knows what they mean, right up until the person reading it is new, and then neither phrase says how far, how fast, or with what. - Poor support for recording. Fields are cramped, misplaced or ambiguous.
The tell is handwriting in the margin. If people are scribbling down the side of the page, they needed to record something and the document gave them nowhere to put it. - Not usable at the point of work. Wrong place, wrong screen size, wrong conditions, fourteen pages before step one.
A digital procedure showing two steps at a time on a small screen, so the user scrolls continuously and has no way to keep place. Or a document that lives on a terminal at the other end of the building. - Accretion across revisions. Additions are cheap and defensible, removals are not, so procedures only ever grow.
What you end up reading is an archaeology of everything that has ever gone wrong, with every incident’s corrective action still embedded in the text and not one of them ever retired.
Why none of this shows up in your numbers
Three reasons burden stays invisible to the people who own the system.
It is paid by users, not writers. The author experiences the document once, at a desk, with time, context and the full task model already in their head. The user pays the cost every shift, under time pressure, with gloves on.
It is masked by expertise. Experienced operators have internalised the task, so their intrinsic load is low and they have spare capacity to absorb whatever extraneous load you have added. The procedure appears to work. It stops working with new starters, agency staff, night shift, unfamiliar variants and abnormal conditions, which is to say precisely the circumstances in which you most need it to carry the weight. Your procedure is load-tested by the people least equipped to carry it.
Corrective actions add and never subtract. Adding a step is cheap and defensible: it closes the finding, it demonstrates action, and nobody is ever blamed for an unnecessary caution. Removing a step is expensive and personally exposing, because you have to justify why it was safe to take out and your name is on the deletion. The same person, acting entirely rationally, will add ten times before subtracting once. Patching is also cheaper than rewriting, since inserting a step at 7.4.3 avoids the full revision, review and retraining that a redesign would trigger.
So the layers build up, and they are readable if you know what you are looking at. There is a proper technical word for the study of layers like these, which I was going to use here until I noticed I was about to drop an obscure term into an article complaining about obscure terms. Archaeology will do.
You can usually date the layers anyway. Three icon conventions, because three authors each introduced one. The same instruction in two places, now quietly diverged because only one copy was updated. Orphaned steps whose purpose nobody can reconstruct, retained because nobody dares remove them. Signature inflation, where each incident added a verification and none was ever retired. Doing that exercise with a group makes the systemic cause obvious without anyone having to argue for it.
The anatomy of one page break
Back to the operator and the map, because it repays a closer look.
At first glance this is a formatting issue, and a minor one. Page breaks are handled by a template. Nobody reviews them. In the document I was looking at, most of them genuinely were minor: a heading stranded at the foot of a page, untidy but harmless.
This one was different, and it got worse the longer I looked at it.
The break separated content the user had to compare. The list is on one page, the map is on the next. The comparison cannot be done by eye, so it has to be done in working memory. This is the split-attention effect: when related information is physically separated, the user spends effort integrating it that could have been spent understanding it.
The list was embedded in a paragraph. So there were no discrete items to work through, no place to mark, and no way to tell at a glance how many items there were or which had been done.
There was nothing to record against. No ticks, no marks, no trace. The only record of progress lives in the operator’s head, so every page turn risks losing it.
The map required visual search. With no numbering linking list items to map locations, each item means scanning the whole diagram. Ten items, ten searches.
Four drivers from the list, compounding on a single page turn. And the fix escalates just as neatly:
- Put them on the same page. Removes the split. Cheapest change, biggest single gain.
- Make the list a list. Discrete items, one per line, so the shape and size of the task are visible at a glance.
- Make it tickable. Progress is recorded on the page rather than carried in the head. The paper does the remembering.
- Number the items, and number the same locations on the map. Visual search collapses into direct lookup. The diagram now does part of the thinking.
Marginal gains, running backwards
None of those four fixes is clever. Not one requires new technology, extra training, or any change to the task itself. Individually each looks too small to be worth the bother, which is precisely why nobody bothers.
That should sound familiar, because it is the marginal gains argument, and it holds here for the same reason it holds anywhere: small improvements to a repeated process compound. What gets said far less often is that the mechanism runs just as happily in reverse. Accretion is marginal gains backwards. Nobody ever added a burden big enough to object to. Each caution, each cross-reference, each extra icon was individually defensible, and they compounded all the same.
Procedure burden is what a decade of small, reasonable, unopposed additions looks like from the operator’s side of the page. The useful part is that the same arithmetic is available going the other way. Nothing heroic is required. It needs someone with the eye to spot the mental gymnastics, and the authority to remove whatever is causing them.
Where to start
Do not start with an audit. Audits check procedures against standards, and burden is entirely compatible with a compliant document.
Start by watching someone use one. The signals are visible if you look for them: flicking back and forth between pages, using a thumb to keep place, reading ahead and then working from memory, signing retrospectively rather than as they go, asking a colleague what a symbol means, working from a personal photocopy with handwritten annotations.
That last one is the strongest signal you will ever get. Someone has redesigned your procedure at their own expense, on their own time, because the official version was not fit to work from. Read it the right way and it is a free specification for the version you should have written.
Procedure burden is not a compliance failure and it will not be resolved by another review cycle. It is a design property of the document, and of the system that produces documents. The first step is to name it. The second is to give someone the authority to take things out.
Two companion downloads accompany this piece:
- a field diagnostic for observing procedure use against the ten drivers, and
- a scoring sheet for page break review, “Not All Page Breaks Are Created Equal”.
We also have procedure training for those interested to learn more.
A note on how this was written
This article started with a question asked in one of our training sessions, and draws on our practice in procedure review and human factors. It was drafted with the assistance of Claude, an AI assistant made by Anthropic, working from the author’s material and under his direction. The ideas, examples and professional judgement are ours, and the final text has been reviewed and approved by the author
