Checklists are 5-10 items that catch what competent people skip under load — not comprehensive process documentation

Why This Is a Rule

Atul Gawande's "The Checklist Manifesto" distilled decades of aviation and surgical checklist research into one insight: effective checklists are short, focused on the steps most likely to be skipped, and designed for competent practitioners — not beginners. The 5-10 item limit reflects working memory constraints: a 30-item checklist produces checklist fatigue, where users check boxes mechanically without actually verifying each step. A 5-10 item checklist is short enough for genuine engagement with each item.

The scope criterion — steps most likely to be skipped or forgotten under load — separates checklists from process documentation. Process documentation describes everything comprehensively for training purposes. A checklist catches only the critical failure points: steps that competent people know but skip when tired, rushed, or multitasking. These are typically non-obvious safety checks, easy-to-forget sequence requirements, and confirmation steps that feel redundant but prevent cascading errors.

A checklist that includes obvious steps ("open the application," "click the button") wastes cognitive space on items that don't need checking, diluting attention from the items that do. Each item on the checklist should earn its spot by addressing a documented failure mode.

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.