Key Takeaways — Chapter 22: Instructions and Procedures

A one-page summary card. Use it to re-ground before the quiz, or to review weeks later.

The one idea

The reader is doing, not reading. They use your instructions as a tool while their attention is on a task—a machine, a screen, a server, a patient. They execute one action, glance back at the page, execute the next. They skip your introduction, enter at step 7, and want each glance to be short. Every rule of procedural writing follows from this one fact: you are not writing prose to be understood; you are writing a tool to be operated.

🚪 Threshold concept: Instructions are not a description of a task—they are directions for performing it. Novices write a smooth paragraph about the task as they remember it ("and then, assuming everything's fine, you'll go ahead and…"). That's a description; a doer can't execute it without already knowing the task. The shift is from describing (narrate, flow, completeness) to directing (command, step, one action at a time).

The core moves

• Numbered steps: one action, imperative, in order. One action per step (so the reader tracks their place between glances). Imperative mood—lead with the verb the reader performs ("Click Save," not "you'll want to click Save"; that's Chapter 3's "free the verb" applied to steps). Exact performance order, with everything the reader needs assembled in a "Before you begin" prerequisites block.
• Warnings go before the step they govern. Never after (too late to prevent the harm), never only at the top (the skipping reader misses it)—repeat the specific warning at the point of use. Choose the signal word by severity: Danger (will cause serious injury) → Warning (could) → Caution (minor injury or equipment/data damage) → Note (helpful info, no hazard). Name the hazard, the why, and what to do—"be careful" is useless.
• Write for the reader who skips around. Headings name tasks, not form (Chapter 4). Steps survive being entered mid-stream—name the noun ("Drag the config.json file"), don't orphan a pronoun ("Drag it"). Provide an entry map for long procedures.
• Annotated screenshots, used carefully. Crop to what matters, annotate the specific element with numbered callouts, and keep the text instruction authoritative (name the element) so it survives a stale or unloaded image. Never "click the button below" with no name.
• Troubleshooting catches the failure. Index by symptom in the reader's words (they don't know the cause), order fixes cheapest/most-likely first, and give an escalation path.
• SOPs remove ambiguity. A standard operating procedure adds purpose/scope, roles, prerequisites, compliance notes, and a revision record—but its defining discipline is making any two people do the task identically. "Approve if it looks good" is not an SOP; a checkable rule is.

The diagnostic

The "someone who has never done this" test. You cannot judge your own instructions—your expertise is the contamination, because your mind silently fills every gap (the curse of knowledge). Give the instructions to a real beginner, have them attempt the task with no coaching, watch silently, log every stall, and revise the instructions (not the tester). Each stall is a defect. The test reliably surfaces the assumed step (the invisible "save the file"), the undefined term, the ambiguous instruction, and the prerequisite mentioned too late.

The cautionary tale

A clean-reading quick-start guide for a Wi-Fi sensor failed five ways—ambiguous app, unnamed button, no pairing-mode signal, a missing 2.4 GHz prerequisite, and "you're all set!" with no definition of done. The author read it five times and saw none of them; one beginner, doing nothing but trying, found all five in forty-five minutes. The guide wasn't badly written. It was untested. (Case Study 2.)

The test to apply before you ship anything procedural

Has someone who has never done this task followed my instructions to success, with no help from me?

If no, you don't know whether they work. Your confidence is not evidence—it's the curse of knowledge. Watch one beginner try.

Themes this chapter surfaced: #2 audience-is-everything (the audience is a doer) · #5 structure-serves-the-reader (the structure is the task, in performance order) · #6 every-sentence-earns-its-place (each step is one action; cut the rest) · #4 revision-is-where-the-writing-happens (testing-and-revising is where a procedure becomes good).

Threshold concept: The reader is doing, not reading.

Back to: Chapter 22 · Exercises · Quiz · Further Reading