A maintenance technician once stood in front of a press holding a procedure I'd written and read the same paragraph three times. He wasn't a poor reader (in fact, at the time, this gentlemen was midway through reading "the classics" just for fun). The paragraph in question asked him to carry four numbers in his head while he watched a gauge and turned a valve, and nobody can do that. The writing was accurate and grammatical but completely wrong for the person using it.
Why does clear writing actually reduce errors?
Reading a procedure draws on the same mental resources as performing the task. Someone following a document is holding the step, the equipment, and their place in the sequence all at once. Every sentence that takes effort to decode borrows capacity from the work itself, which is why the cost of a hard-to-read procedure arrives as a defect rather than as a complaint about the writing.
That's what makes documentation quality an operational issue instead of a matter of taste. The person at the machine has a fixed budget of attention, and whatever the sentence takes, the task doesn't get.
Document reviews miss it for the same reason. A reviewer reads sitting down, with both hands free, no alarm, no shift change, nobody waiting. Under those conditions almost any competent writing reads fine. The procedure I wrote for that press passed two reviews and failed the first time somebody used it while the machine was running, because that was the first time anyone had read it with their hands full.
How much can a reader hold in their head at once?
Less than most documents assume. George Miller's 1956 paper, "The Magical Number Seven, Plus or Minus Two: Some Limits on our Capacity for Processing Information", gave us "seven plus or minus two," which got quoted for the next fifty years as permission to write seven-item steps. Later research revised the figure down to roughly four items for anything a person has to actively hold rather than simply recognize. Four, on a good day, with nothing else competing.
Here's the step that sent that technician back to the top of the paragraph:
- Verify that line pressure reads between 82 and 88 psi and that the bypass valve is closed before engaging the feed, unless the unit has been idle more than four hours, in which case complete the warm-up sequence first.
Count what he had to carry: two pressure limits, a valve state, an action, a time threshold, and a branch to a different procedure. Six items, and the branch arrives after he's already been told to engage the feed, so he has to go back and cancel the instruction he just read.
The same content, restructured:
- If the unit has been idle more than four hours, complete the warm-up sequence (page 4), then return here.
- Confirm the bypass valve is closed.
- Confirm line pressure reads 82 to 88 psi.
- Engage the feed.
Nothing was removed. The numbers are identical and so is the logic. What changed is that no line asks him to hold anything while he reads the next one.
What does working under pressure do to reading?
Stress narrows attention, and it narrows it fast. Under load, people read less of the page, jump to whatever looks like the answer, and accept the first plausible reading instead of the correct one. Procedures get used on the bad day rather than the calm one, so the useful test of a document is whether it survives a reader who's already behind.
The quality hold that taught me this arrived at four o'clock on a Friday. Two people were reading the disposition procedure at the same time and both skipped the paragraph that mattered, because it opened with three sentences of scope language before it reached the decision. They weren't careless. They were scanning, the way everybody scans when something has gone wrong, and scanning finds headings and numbers and slides past prose.
After that I stopped putting context above actions. When a step carries a condition, the condition goes first, in the shortest form that's still accurate. When a section exists to tell somebody what to do if something breaks, the first line says what to do.
Why do your best people write the worst documentation?
Expertise removes steps from view. Once a task runs automatically, the expert stops experiencing the small decisions inside it and writes the compressed version their own mind now uses. The gaps aren't carelessness. They're what competence does to memory, and a new person reading that document walks straight into them.
I've written about why your best employee writes the worst documentation at more length, and the short version is that you can't interview your way around it. Asking an expert what they do produces the summary. Watching them do it produces the steps.
The cheapest fix I know costs ninety minutes. Put the expert in the room, have somebody who doesn't know the task attempt it from the current document out loud, and ask the expert to stay silent and write down every place the new person stops. That list is the missing content, and it's rarely what the expert would have predicted.
What does this change about the way a procedure gets written?
One action per step. The condition before the action. Numbers, tolerances, and part identifiers on the line where they get used instead of in a table three pages back. Nothing on the page the reader doesn't need at that moment. The test is whether a step can be carried out without holding anything in reserve, not whether the document reads as thorough.
A few practices that follow from it:
- Put the branch before the instruction it changes, never after.
- Repeat a tolerance rather than cross-referencing it. Ink costs less than a page turn.
- Keep an image beside the step it illustrates. A photo on the facing page makes the reader hold the text while they look, which puts the load straight back where you just took it from.
- Write the heading as the thing the reader is trying to do, so scanning lands in the right place.
None of this is about making the document shorter. A procedure written this way often runs longer on the page and shorter in the head, and the head is where the errors happen. More on the mechanics is in how to write an SOP a new hire can actually follow.
Is plain language the same as writing down to people?
No. Plain language answers load, not ability. A chemical engineer reading a procedure with gloves on and an alarm sounding has the same working memory as everyone else, and would rather spend it on the chemistry than on the sentence. In low-risk writing, simple prose is a courtesy to the reader. In high-risk work it does the job of a control.
This is the objection I hear most, usually phrased as some version of "our people are professionals, they can handle technical language." They can. That was never the question. The question is what else they're handling while they read it.
Plain language doesn't mean vague, either. Swapping an exact technical term for a softer everyday word adds load instead of removing it, because now the reader has to work out which specific thing you meant. Keep the precise term, define it once, and spend the simplification on sentence structure, where it's free.
What if your documents are already written the hard way?
Don't rewrite everything. Find the procedures used under pressure by people who didn't write them, and start there. Watch one person use one document and mark every place they stop, reread, or look away to check something. That list is your revision plan, and it's usually far shorter than the rewrite you've been dreading.
Rank what you find by what the confusion costs. A procedure that adds thirty seconds to a task performed twice a year can wait. A procedure that gets misread during a changeover on a line running three shifts cannot, and fixing that one is an afternoon of work rather than a project.
The full rewrite is the thing to avoid. I've watched those run for a year, exhaust everybody involved, and produce a shelf of documents nobody has opened since.
When I take on technical writing work, I ask to watch somebody use the current documents before I propose anything, because the observation finds the real problem faster than the reading does. More on how projects run is on the FAQ, and if you have a document that keeps getting misread, book a discovery call and bring that one.
Frequently asked questions
Why does clear documentation reduce errors?
Reading a procedure draws on the same mental resources as performing the task. A person following a document holds the step, the equipment, and their place in the sequence at the same time, so any sentence that takes effort to decode borrows capacity from the work itself. The cost shows up as a mistake in the task rather than as a complaint about the writing.
How many things can someone hold in their head while following a procedure?
Research on working memory puts the practical figure at roughly four items a person has to actively hold, lower than the familiar seven plus or minus two from Miller's 1956 paper. That is four under good conditions with nothing else competing. A single step carrying two tolerances, a valve state, an action, and a conditional branch already exceeds it.
Is plain language in technical writing the same as oversimplifying?
No. Plain language answers cognitive load, not a reader's ability. An engineer reading a procedure with gloves on and an alarm sounding has the same working memory limits as anyone else and would rather spend that capacity on the technical work than on the sentence. Keep the precise technical terms, define them once, and simplify sentence structure instead.
What should I fix first if my procedures are already hard to follow?
Start with the documents used under pressure by people who did not write them. Watch one person use one procedure and mark every place they stop, reread, or look away to check something. That list is the revision plan, and it is usually far shorter than a full rewrite. Rank the repairs by what the confusion costs rather than by how untidy the document looks.
