Writing Clear Procedures
A procedure is a sequence of actions that produces a predictable result. Writing one well requires precision, an understanding of your reader's knowledge level, and a discipline about scope that most writers underestimate.
Atomic steps: one action per step
Each step should describe exactly one action. "Log in and navigate to Settings" is two steps. Break it.
The test: can the user complete this step without simultaneously doing anything else? If a step requires two distinct actions to execute, it's two steps.
Atomic steps make procedures verifiable. After each step, the user should be in a specific, checkable state. If they're not sure whether they've completed a step correctly, the step isn't specific enough.
Imperative voice
Write every step in imperative voice: "Click Save" not "The Save button should be clicked." Imperative voice is direct, unambiguous about who acts, and easier to follow.
Passive voice in procedures creates ambiguity. "The file should be saved" — by whom? The user? The system automatically? Passive voice forces the reader to infer what imperative voice states directly.
When the system does something (rather than the user), say so explicitly: "The system will display a confirmation message." This is not passive — it's a description of an expected system behavior that helps users verify they're on track.
State the purpose and prerequisites first
Before the steps, tell the user what they're about to accomplish: "This procedure configures two-factor authentication, which adds an additional verification step at login." Users who understand the goal are less likely to skip steps or make substitutions.
List prerequisites immediately before the procedure: "Before you begin, ensure you have administrator access and the authenticator app installed." A user who discovers a missing prerequisite mid-procedure must start over.
Estimated time is useful when the procedure takes longer than a few minutes. Users who know they're starting a 20-minute process will plan differently than users who think they're clicking three buttons.
Testing your procedures
Follow your own procedure from the beginning in the actual environment — not from memory, and not in a test environment that differs from production.
Have someone unfamiliar with the task follow your procedure without assistance. Watch without speaking. Note every moment of hesitation, confusion, or error — each one is a failure in the procedure, not in the user.
Update the procedure based on what you observe. "Users should figure it out" is not a solution to a confusing step.
Key Takeaways
- Each step describes one action — if a step requires two actions, it's two steps
- Imperative voice ("Click Save") is clearer than passive or conditional phrasing
- State the purpose and prerequisites before the first step
- When the system acts, say so explicitly — don't leave users wondering what to expect
- Test your procedures by watching an unfamiliar user follow them without assistance
Try it in WolfScribed
Open a project and use the Scene Planner to put these ideas into practice.