Checklists are 5-10 items that catch what competent people…

When This Fires

• When designing any operational checklist for repeated procedures
• When an existing checklist exceeds 10 items — it needs pruning
• When a checklist exists but users report it "doesn't help" — it's probably too long or includes obvious steps
• When converting process documentation into operational checklists

Common Failure Mode

Comprehensive checklists that try to document the entire procedure: "Step 1: Open the system. Step 2: Log in. Step 3: Navigate to..." This is a procedure manual, not a checklist. Users either check every box without reading (defeating the purpose) or stop using the checklist entirely because it's too long. The checklist should only contain the steps that competent users demonstrably skip — determined by failure data, not by process documentation.

The Protocol

(1) Identify the procedure's failure points: which steps, when skipped, produce the worst consequences? Review error logs, incident reports, or personal failure patterns. (2) Select the 5-10 steps most commonly skipped or most consequential when skipped. These become checklist items. (3) Write each item as a verification, not an instruction: "Backup confirmed?" not "Run the backup script." The user knows how to do the step; the checklist verifies they did it. (4) Order items in the sequence they should be verified, matching the procedure's natural flow. (5) Test: run the procedure with the checklist. Does it catch the errors it was designed to catch? Is it short enough that every item gets genuine attention? (6) Iterate: remove items that are never missed (they don't need checking) and add items when new failure modes emerge.