KM-301e · Module 2
Runbooks, Decision Trees & Annotated Screenshots
4 min read
Runbooks, decision trees, and annotated screenshots each solve a different documentation problem. Runbooks solve the problem of complex operational procedures that require explanation alongside instruction. Decision trees solve the problem of highly branching diagnostic or routing logic. Annotated screenshots solve the problem of UI-based processes where the interface is the process. Choosing between them is a content strategy decision, not an aesthetic one.
- Runbooks A runbook is a step-by-step operational guide that combines instruction with context. It answers "what do I do?" and "why does this matter?" at each step. Runbooks are appropriate for complex operational procedures — server deployments, incident response, compliance workflows — where the practitioner is executing under pressure and needs enough context to make judgment calls, not just execute a checklist. Structure: numbered steps, context annotations, expected outputs, and error handling for each step.
- Decision Trees A decision tree is a hierarchical branching structure that takes a starting condition and walks through yes/no questions to a specific outcome. Decision trees are optimal for diagnostic processes ("what is wrong?"), triage processes ("what category does this belong in?"), and recommendation processes ("what should the customer do?"). The decision tree format is more precise than a flowchart for pure logic — every node is a question, every leaf is an outcome, no narrative.
- Annotated Screenshots For UI-based processes — operating a software tool, navigating a workflow system, configuring a platform — annotated screenshots are the most efficient transfer format. Text descriptions of where to click and what to enter are consistently outperformed by numbered annotations directly on screenshots of the actual interface. The annotation points to the exact element. There is no ambiguity between what is described and what is visible.
- Format Selection Framework Apply four criteria: complexity (how many steps and branches?), audience expertise (trained practitioner or first-timer?), environment (pressure/time constrained or deliberate execution?), and primary challenge (navigation, logic, or interface operation?). Complexity + trained + pressure = flowchart. Complex + first-timer + deliberate = runbook. Pure logic + any audience = decision tree. UI-based + any audience = annotated screenshots.
Do This
- Match format to process type: runbooks for operational complexity, decision trees for diagnostic logic, screenshots for UI procedures
- Use annotated screenshots for any process that involves operating a specific software interface
- Combine formats when the process has distinct phases — a flowchart overview with runbook detail for each sub-process
Avoid This
- Default to a numbered list for every process regardless of complexity or audience
- Use prose descriptions of UI interactions when screenshots are available — "click the blue button in the top right corner" is worse than a screenshot with an arrow
- Create decision trees for processes with fewer than three decision points — a two-option list is sufficient