Writing Clear Procedures

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.

Draft: "To reset your password, go to the login page and click the forgotten password link, then you should receive an email which will have a link that will let you choose a new password, after which you can log in."

Revised:

1. Open the login page.
2. Click Forgot password.
3. Enter your email address and click Send. The system sends a reset email within a few minutes.
4. Open the email and click Reset password.
5. Enter a new password twice and click Save. You can now log in with the new password.

The revised version has one action per step, imperative verbs, a clear note about what the system does, and an explicit end state. A user who gets stuck can tell you exactly which step failed.

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." Describing what the system does is not passive voice — it states an expected system behavior that helps users verify they're on track.

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.

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.

When a step depends on a choice, put the condition first: "If you use two-factor authentication, enter the code from your app." Readers scanning for their situation find it faster, and nobody performs an action before learning it didn't apply to them.

Put warnings before the step they apply to, not after. "Warning: this deletes all saved drafts" is useless if it appears after the step that deletes them.

If a step commonly fails, tell the user what to do when it does: "If you don't receive the email within ten minutes, check your spam folder or request a new link." Anticipating the most likely failure saves the user a support request.

Use numbered lists for steps that must happen in order and bullets for options or items that don't. Bold the exact names of buttons and menu items so users can match them to the screen.

Keep the number of steps manageable. If a procedure runs past ten or twelve steps, look for natural break points and split it into smaller procedures, each with its own clear outcome.

Screenshots help when the interface is complex or the target is hard to describe, but they go out of date quickly. Use them for the steps where users are most likely to get lost, crop them to the relevant area, and highlight the element to click. Always keep the instruction in text as well, so the procedure still works when the image is outdated or cannot be seen.