How to Write Instructions People Can Actually Follow

Everyone has been stuck on step 4 of instructions that assumed you already finished a step 4 that was never written. The reader gets lost, gives up, and files a support ticket — or worse, does the wrong thing. Clear instructions are not about writing more; they are about removing every place a reader can get stuck.

This guide walks through how to write instructions that people can follow on the first try: how to break a task into steps, how to phrase each step, how to make the whole thing scannable, and how to check that it actually works before you publish it.

What makes a good set of instructions

Good instructions turn a task into an ordered list of single actions a reader can perform without guessing. Each step says what to do, in the order it must happen, in language the reader already understands. That is the whole job — and most instructions fail because they quietly skip one of those three.

The bar is not “technically correct.” The bar is “a real person, under a little pressure, can follow this without stopping to ask a question.” Everything below serves that bar.

Why most instructions fail

The first reason is that readers do not read instructions the way you wrote them. Usability research has found that about 79% of users scan a page rather than read it word for word. They jump to the numbered list, look at step 3, and act. If a critical detail is buried in a paragraph above the list, it does not exist.

The second reason is ambiguity. “Configure the settings and continue” assumes the reader knows which settings, what to set them to, and what “continue” looks like. Every assumption you leave in is a place the reader can stall.

The good news is that the fixes are known and measurable. In the same body of research, concise text improved measured usability by 58%, a scannable layout by 47%, and both together by 124%. Instructions are the format where those gains matter most, because the reader is trying to do something, not just understand it.

Start with the task, not the feature

Before you write a single step, name the task from the reader’s point of view: “Reset your password,” not “Password management.” Instructions are organized around what someone is trying to accomplish, and a task-shaped title tells the reader they are in the right place.

Then write down the two things every set of instructions needs up front: what the reader needs before they start (access, information, a prerequisite step) and what they will have when they finish. Stating the end state first follows the inverted-pyramid pattern that matches how people scan — they know where they are headed before they take the first step.

How to write step-by-step instructions

This is the core of the work. Five rules cover almost every case.

1. One action per step

The most common mistake is packing three actions into one step. “Open Settings, select Billing, and enter your card” is really three steps, and a reader who completes the first two and gets interrupted will lose their place. Split them. A numbered step should be a single, checkable action.

2. Lead each step with the action

Start each step with the verb, in the active voice: “Select Save,” not “The Save button should now be selected.” Plain-language guidance is consistent on this — the active voice and short sentences are easier to follow and leave less room for misreading. Front-loading the verb also lets a scanning reader see the action without reading the whole line.

3. Put the condition before the action

Readers act on the first thing they see, so order matters inside a step. Write “If you use two-factor authentication, enter your code,” not “Enter your code if you use two-factor authentication.” A reader who doesn’t use two-factor should be able to skip the step before they start doing it.

4. Say what success looks like

After an action with a non-obvious result, tell the reader what they should see: “A green checkmark appears next to the file name.” This lets people confirm they are on track and catch a wrong turn immediately, instead of discovering it four steps later.

5. Show, don’t only tell

A screenshot, a short clip, or a small example after a tricky step removes the last of the ambiguity. You don’t need a picture for every step — add one where words alone would make the reader guess which button, which field, or which screen.

Make the instructions scannable

Because readers scan, the layout does as much work as the words. Use a numbered list for anything that must happen in order and a bulleted list only for options that don’t. Keep each step to one idea, bold the interface labels a reader is hunting for, and use short, meaningful headings so someone can find the section they need without reading the ones they don’t.

The test is simple: can a reader skim only the step numbers and bold labels and still get through the task? If yes, you have written for how people actually use instructions.

Write work instructions that stay accurate

Instructions have a second failure mode that has nothing to do with wording: they go out of date. A perfectly written set of work instructions is worse than useless if it describes a screen that changed three releases ago, because the reader trusts it and gets stuck.

Keep instructions in one canonical place, versioned, so there is a single source of truth and no stale copies floating around in chat threads and old PDFs. This is where a purpose-built platform helps: in Sonat, your instructions live with the rest of your documentation, a readability guide keeps each step clear, an approval step catches errors before publish, and a full version archive lets you see what changed and roll back a bad edit.

Test your instructions on a real person

You cannot proofread your way to usable instructions, because you already know the answer. The reliable test is to watch someone who doesn’t follow the steps exactly as written — no hints. Plain-language practice treats this “test for understanding” as a core step, not a nicety. Every place they hesitate is a step to rewrite. One five-minute walkthrough will find more problems than an hour of re-reading.

Common mistakes to avoid

• Assuming the starting point. If a step depends on the reader already being somewhere, say how to get there.
• Mixing actions and explanation. Keep the “why” out of the step itself; put background before the list, not inside it.
• Vague verbs. “Manage,” “handle,” and “set up” hide the real action. Name the exact click, entry, or selection.
• No way to confirm. If the reader can’t tell whether a step worked, they will either stop or barrel ahead into an error.
• Never re-testing after a change. When the product changes, the instructions changed too — even if nobody edited them.

Write the first version, then cut

The fastest way to clear instructions is to write the steps out fully, then remove every word the reader doesn’t need to act. Break the task into single actions, lead with the verb, show the success state, make it scannable, and watch one real person try it. Do that, and you will spend far less time answering the same question over and over.