Exercises — Chapter 22: Instructions and Procedures

Writing is learned by writing. These exercises ask you to produce and revise real procedural text, not just recognize it. Difficulty: ⭐ (warm-up) to ⭐⭐⭐⭐ (extension). Selected solutions and rubrics are in appendices/answers-to-selected.md; open-ended tasks include a self-assessment rubric here.

Part A — Analyze This ⭐

For each, identify what works or what's broken. Name the specific principle from the chapter (one action per step, imperative mood, performance order, warning placement, the assumed step, vague condition, linear-reader assumption, etc.).

A1. A step reads: "5. Once you've confirmed the backup completed and assuming you have admin rights, go ahead and run the migration script, being careful not to interrupt it." List every problem you can find in this single step.

A2. An instruction says: "3. The system will validate your entry and display a confirmation." What's wrong with including this as a numbered step in a procedure?

A3. A furniture manual: the warning "Do not fully tighten the bolts until all panels are in place" appears as the last line of the assembly instructions, after step 12 (the final step). What's the placement error, and what does the reader who follows the steps in order experience?

A4. A help article titled "Resetting Your Device" opens: "As discussed in the previous section, your device should already be in pairing mode before you continue." Why is this opening sentence a problem given how people actually arrive at help articles?

A5. An SOP step: "Review the submission and approve it if the quality is acceptable." Why does this fail the test of a standard operating procedure?

A6. A troubleshooting entry is titled: "Resolving SMTP authentication handshake failures (error class 535)." The reader's actual experience is "I clicked send and got an error that my password was wrong." What's the mismatch, and what would a better entry title be?

A7. An instruction reads: "Click the button shown in the screenshot below to continue," with no button name given. Identify two distinct failure modes this creates.

A8. Read this short, well-made procedure and name three specific things it does right:

Before you begin: You'll need the order number and the customer's email. You must have the "Refund" permission—if you don't, ask your team lead before starting. 1. In OrderTool, search for the order by order number. 2. Confirm the customer email matches the refund request. 3. Click Issue Refund. 4. Confirm the amount matches the purchase price. If it doesn't, stop and escalate. 5. Click Confirm Refund and wait for the green "Submitted" banner.

Part B — Revise This ⭐⭐

Rewrite each passage so it follows the chapter's rules. Where information is missing (an assumed step, an undefined term), either supply a plausible specific or flag it explicitly as "[ASSUMED STEP — needs testing to confirm]".

B1. Rewrite as numbered steps, one action each, imperative mood:

"To reset your password, you'll want to go to the login page and click the 'Forgot password?' link, then you'll enter your email and the system will send you a reset link which you should click, and then it's just a matter of entering your new password twice and saving."

B2. Fix the mood and conciseness in these steps:

1. The user should locate the reset button on the back of the unit. 2. It is necessary to press and hold this button. 3. You'll want to keep holding it until the light starts blinking. 4. The device will then reset to factory settings.

B3. This step bundles too many actions. Split it into proper numbered steps:

"4. Remove the SIM tray with the ejector tool, take out the old SIM, insert the new SIM with the gold contacts facing down and the notch in the corner, then slide the tray back in until it clicks."

B4. Move the warning to the correct place and improve it (name the hazard, the why, and the what-to-do):

1. Remove the blade guard. 2. Replace the blade. 3. Reattach the guard. Warning: The blade is extremely sharp.

B5. Rewrite this troubleshooting entry to lead with the symptom in the reader's words and give ordered, actionable fixes:

"A 'connection refused' state on port 5432 indicates the PostgreSQL daemon is either not running or not accepting TCP connections due to host-based authentication configuration."

B6. This step assumes the reader read everything before it. Rewrite it to survive a reader who jumped straight here from a search result:

"9. Now paste it into the field you saw earlier and submit."

B7. Rewrite "the vague procedure" below (a fictional onboarding snippet) as proper instructions. Add a "Before you begin," number the steps, and flag at least two assumed steps a beginner couldn't perform:

"Getting set up is easy. Just request access to the usual systems, clone the repo, install the dependencies, set up your environment, and you should be able to run the app locally. Ping the team if you get stuck."

Part C — Write This ⭐⭐–⭐⭐⭐

Produce a complete document for each scenario.

C1. (⭐⭐) A short how-to. Write complete instructions for a simple everyday task you know well (making pour-over coffee, jump-starting a car, sending a calendar invite, replacing a smoke-detector battery). Include: a title and one-line scope, a "Before you begin" block, numbered one-action steps in the imperative, and at least one note or caution placed correctly. Then mark the one step you suspect a true beginner would stall on, and say why.

C2. (⭐⭐) A warning set. Choose a task with at least one real hazard (using a pressure cooker, handling a lab reagent, working near a live circuit, operating a table saw). Write the three-to-five steps surrounding the hazard, and place a properly-worded warning (correct signal word, named hazard, why, what-to-do) immediately before the dangerous step. Then write the wrong version (warning misplaced or mis-signaled) and label what you changed.

C3. (⭐⭐) A troubleshooting section. For a task or product you know (a printer, a Wi-Fi router, a piece of software, a coffee machine), write a troubleshooting section with at least four entries. Index each by the symptom in the reader's words, give one or two ordered fixes (cheapest/most-likely first), and end each with an escalation path.

C4. (⭐⭐⭐) A real SOP. Write a standard operating procedure for a recurring task at your work, school, or a club (closing a register, backing up a database, onboarding a new volunteer, running a weekly report). Include all SOP scaffolding from §22.7: purpose/scope, roles, prerequisites, numbered steps, any compliance/safety notes at the step, and a revision record line. The acid test: would two different people, following only your document, do the task identically? Name the one step where you had to remove a judgment call to pass that test.

C5. (⭐⭐⭐) An annotated visual procedure (described). Pick a software task with an on-screen reference. Write the numbered steps, and for at least two steps describe an annotated screenshot (what's cropped in, what's circled/numbered, the callout numbers) and write the alt-text for each image so the procedure works for a reader who can't see it. Confirm that a sighted reader and a screen-reader user could both complete the task.

Part D — Synthesis & Critical Thinking ⭐⭐⭐

D1. Translate for three audiences. Take one task—"deploy the application to production"—and write the same procedure three ways: - (a) for a senior engineer who's done it on other systems but not yours (assume competence; name your system's specifics), - (b) for a brand-new hire on their first week (assume nothing; specify every step and term), - (c) as a strict SOP for compliance (roles, approvals, warnings, revision record). Then write two sentences on what changed between them and why. (This integrates Chapter 2's audience analysis with this chapter.)

D2. Find the flaw. Here is a procedure that passes a quick read but will fail a beginner. Find every defect and rewrite:

Updating the firmware 1. Download the latest firmware. 2. Put the device in update mode. 3. Run the updater and select the file. 4. Wait for it to finish. 5. The device will reboot and you're done. (Note: do not unplug during the update.)

D3. The over-specified vs. under-specified call. A colleague argues your equipment SOP is "way too detailed—anyone can see how to do this." Using §22.9's "it depends" framework, write a short argument for when heavy specification is right and when it's condescending, and decide which this case is. What two facts about the task and audience determine the answer?

D4. Cross-chapter integration. Chapter 4 said headings should name content, not form. Chapter 10 said design is part of meaning. Explain, in one paragraph, how both lessons apply to a 30-page user manual that a reader will navigate non-linearly—and name one concrete thing you'd do that serves all three chapters (4, 10, 22) at once.

D5. The verification gap. Most instructions tell the reader what to do but not how to know it worked. Take any procedure from Part B or C and add a verification check ("You'll know it worked when…") to the three steps most likely to silently fail. Why is verification especially important for a reader who's doing, not reading?

Part M — Mixed Practice (Interleaved) ⭐⭐–⭐⭐⭐

These mix this chapter with earlier ones, so you must choose the right tool.

M1. You're handed a 400-word paragraph that "explains how to file an expense report." Decide first: is the right fix a clarity pass (Chapter 3), a structure pass (Chapter 4), or a conversion to numbered steps (Chapter 22)—or all three, in what order? Justify the order, then convert the (fictional) paragraph's likely content into steps.

M2. A teammate's setup instructions are clear and correctly stepped, but the page is a wall of dense, single-spaced text with no white space between steps and headings that look like body text. The writing is fine. Which chapter's tools does this need (3, 4, 10, or 22), and what specifically would you change? (Trap: don't rewrite content that's already correct.)

M3. You must write a one-paragraph email to your team announcing a new SOP and linking to it (Chapter 19), plus the SOP itself (Chapter 22). Draft both. Note how the email's job (get them to read and adopt) differs from the SOP's job (let them perform the task identically)—different audience needs, different genre.

M4. A step in a procedure reads: "Configure the cache settings appropriately based on your workload." Is the right fix here a Chapter 3 clarity move, a Chapter 7 word-choice move, or a Chapter 22 vague-condition move? Diagnose it, then rewrite it as a checkable instruction.

M5. Take the troubleshooting entry you wrote in C3 and apply Chapter 3's "so what?" and conciseness passes to it. Did cutting words make it more or less usable for a stressed doer? What does that tell you about conciseness in procedures specifically?

M6. You're documenting how to run a data export. The reader is, per Chapter 2's categories, sometimes an expert engineer and sometimes a non-technical office manager, arriving at the same help page. How do you serve both in one document? (Hint: think layering, from Chapter 4—and progressive disclosure.)

Part E — Extension ⭐⭐⭐⭐ (optional)

E1. Run a real usability test. Recruit one person who genuinely doesn't know a task you do. Give them only your written instructions (from any earlier exercise), watch them attempt it, and say nothing—no coaching. Log every stall: where they paused, what they misread, what they did wrong, what they asked. Then write a short report: (a) the stalls, (b) the defect each one revealed, (c) the revision you made. Identify the one assumed step the test surfaced that you could not have found by re-reading. This is the chapter's central skill; doing it once changes how you write procedures permanently.

E2. Reverse-engineer a great manual. Find a set of instructions you think are excellent (a well-known product's setup guide, a respected open-source project's docs, IKEA's wordless assembly diagrams). Analyze why they work using this chapter's vocabulary: How do they handle one-action-per-step, warnings, the skipping reader, verification? What do they do that this chapter didn't mention? Write 400–600 words. (Reading as a writer, previewing Chapter 39.)

E3. The accessibility audit. Take a real procedure (yours or a published one) and audit it strictly for accessibility (Chapter 10 + §22.4): Does every visual have text-equivalent steps and useful alt-text? Does any instruction rely on color or position alone? Could a screen-reader user complete the whole task? Could someone with images disabled? List every failure and fix it.

Self-Assessment Rubric (for the open-ended Part C and D tasks)

Score each produced procedure against these criteria. Aim for "Strong" on all before considering it portfolio-ready.

Selected solutions and rubrics: appendices/answers-to-selected.md. For tasks with a defensible single answer (A1–A7, B1–B6, D2), the appendix gives a worked solution; for open-ended tasks (C-series, D1, D3–D5, E-series), use the rubric above to self-assess.