Phase-Based Checklist¶
Checklist — instantiates Chunked Information Design
A checklist grouped by stages of action rather than as one flat list.
Phase-Based Checklist groups the items of a procedure by the stage of work in which they're done, so that instead of one intimidating 40-item list, a doer faces a short block for the phase they're in, completes it, crosses a boundary, and only then sees the next block. Its defining trait is that the chunking axis is temporal — each chunk is a phase of action, ordered as the work actually unfolds — and each phase transition is a deliberate stop-and-verify gate. Unlike a reference document or a lookup card, this artifact is executed in sequence over time, and the "you are in this phase" cue is what keeps a busy operator located in the run.
Example¶
A film crew shooting on location works from a shoot-day checklist that used to be one long column of 50 items; ADs skipped around it and things got missed. It's rebuilt into four phases matching how the day runs: Pre-Light (rig lights, lay track, set marks), Blocking (walk the scene with talent, set final camera), Shooting (roll, check gate, confirm coverage), and Wrap (strike gear, account for equipment, secure location).
Each phase is a bounded block the crew works only when they're in it — the Shooting items simply aren't shown while the crew is still rigging, so nobody jumps ahead. The transition between phases is a hard gate: the AD confirms every Pre-Light item is checked and calls the move to Blocking out loud, which is both a verification point and the signal that the phase has changed. A header banner shows the current phase so anyone glancing at the sheet knows where the day stands. Missed items drop because the crew handles one phase's short list at a time and can't advance until the phase is genuinely done.
How it works¶
- Chunk by phase of action. Items are grouped by the stage of work in which they're performed, not by topic or owner — the grouping axis is the timeline of the task.
- Order phases as the work runs. Phases follow real execution order, so the checklist unfolds in step with the doer rather than being scanned out of sequence.
- Gate each transition. The boundary between phases is a stop-and-verify point: the current phase's items must be confirmed complete before the next phase opens, which is what a flat list can't enforce.
- Show the current phase. A visible marker keeps the operator located — which phase is live, which are done — so a glance re-orients someone pulled away mid-run.
Tuning parameters¶
- Phase granularity — few broad phases or many fine ones. Fewer phases are simpler but let a phase's block grow long; more phases keep each block short but multiply the stop-and-verify gates.
- Gate strictness — whether a phase truly locks until confirmed, or transitions are advisory. Hard gates prevent skipping but slow a practiced team; soft gates trust the operator but re-admit the skip-ahead error.
- Read-Do vs. Do-Confirm — whether each item is read then done, or done from practice then confirmed at the gate. Read-Do suits novices and rare procedures; Do-Confirm suits experts running a familiar flow.
- Phase visibility — showing only the active phase vs. the whole run at once. Active-only enforces focus; whole-run gives overview but re-admits jumping ahead.
- Gate ceremony — how heavy the transition ritual is (a spoken call-out, a second signer). Heavier gates catch more but cost time at every boundary.
When it helps, and when it misleads¶
Its strength is that it converts a daunting flat procedure into a sequence of short, crossable stages, and the phase gates give the doer natural checkpoints that catch omissions before they compound. Grouping by phase also matches how people actually think about work in progress — "we're in blocking now" — so the tool tracks the mental state of the run.[n1]
Its central failure mode is workflow lock-in: a phase structure assumes one ideal path, and when reality demands doing a later item early or looping back, a rigid checklist has no honest place for it and the operator either fights the tool or abandons it. Over-fine phasing turns a smooth job into a bureaucracy of gates; a gate treated as a rubber stamp gives false assurance that a phase was truly complete. The discipline is to phase only where the work genuinely has stages, to keep gates meaningful rather than ceremonial, and to build in an explicit path for the legitimate out-of-order case rather than pretending it never happens.
How it implements the components¶
Phase-Based Checklist fills the temporal-sequencing components — the ones that stage an executed procedure:
chunk_boundary— each phase transition is a hard boundary, a stop-and-verify gate that a flat list lacks.chunk_sequence— phases are ordered by real execution order, so the checklist unfolds as the work does.orientation_cue— the current-phase marker keeps the operator located in the run and signals when a phase has changed.
This artifact stages action; it is not a labeled reference or a cross-linked web. It does NOT implement chunk_label (the retrieval-handle headings of Chunked Documentation), grouping_principle (discovered by Card Sort), or cross_chunk_link (the dependency links of Chunked Documentation); a phase checklist runs forward through stages rather than cross-referencing them.
Related¶
- Instantiates: Chunked Information Design — Phase-Based Checklist applies the archetype to an executed procedure, chunking by stage of action.
- Sibling mechanisms: Card Sort · Recall or Findability Test · Chunked Documentation · Grouped Dashboard · Interface Sectioning · Learning Module · Nested Navigation Menu · Quick Reference Card
Editorial Notes¶
Form Classification¶
Form family: Protocol, Workflow & Routine
Rationale: Phase-Based Checklist operates as a repeatable ordered procedure or handoff sequence that coordinates action because it a checklist grouped by stages of action rather than as one flat list.
Independent corroboration: The frozen evidence defines Phase-Based Checklist as 'A checklist grouped by stages of action rather than as one flat list', so its operative form is Protocol, Workflow & Routine.
Review outcome: Independent reviewer agreement; medium confidence.
Origin Attribution¶
Primary origin: Medicine & Healthcare
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Phase-Based Checklist is rooted in medicine and healthcare: High-consequence procedural practice places checklist pauses at natural phases of work.
Related originating lineages:
- Aviation & Aeronautics — Aviation and aeronautics materially shaped Phase-Based Checklist through recertification, safety checks, and high-consequence operations. Aviation checklists materially developed phase-of-flight organization.
- Organizational & Management Science — Organizational and management science materially shaped Phase-Based Checklist through coordination, organizational learning, performance, and change practice. Organizing standard work by process stages is a common operations-management and quality practice.
Review resolution: Light authoritative-source research resolves the primary-origin disagreement in favor of medicine and clinical practice. WHO: Case-Based Discussion Tool directly documents the defining practice or theory described in the selected origin rationale. Other listed domains are retained only where the blind reviews identify material co-development or translation; broader adoption remains separate as domain_reach=multi_domain.
Attribution caveat: Phase-based checklists converged across high-reliability professions rather than arising from one exclusive lineage.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Atul Gawande's The Checklist Manifesto distinguishes a Read-Do checklist (read the item, then do it) from a Do-Confirm one (do the work, then pause to confirm) and stresses pause points at natural breaks in a procedure — precisely the phase boundaries this mechanism formalizes. ↩