How to Write Step-by-Step Instructions People Can Actually Follow

Someone opens your instructions because they want to get something done, usually in the middle of other work. If step 4 is vague, they guess. If they guess wrong, they file a support ticket or give up. Good step-by-step instructions remove the guessing.

This guide shows you how to write step-by-step instructions that work on the first try. It covers what to decide before you write, how to phrase each step, how to handle optional and conditional steps, how to format for people who scan, and how to test your work with a real reader.

What are step-by-step instructions? Step-by-step instructions (also called a procedure) are a numbered sequence of actions that takes a reader from a clear starting point to a specific result. Each step tells the reader to do one thing, in the order they need to do it.

Before you write: define the goal, the reader, and the starting point

Most unclear instructions go wrong before step 1. The writer knows the task so well that they skip the setup a newcomer needs.

Name the task as a goal

Write the title as the thing the reader wants to do, starting with a verb: "Export a monthly sales report," not "Reports" or "Report export functionality." A goal-shaped title tells readers they are in the right place, and gives you a finish line.

Say who the reader is and what they already know

A new hire needs more context than an admin who does the task every week. If you must serve both, write for the newer reader and keep steps short so experts can skim.

List prerequisites before step 1

Tell readers what they need before they start: access rights, files, account settings, or tools. Google's developer documentation style guide puts it simply: make sure the reader has the information they need to prepare for the task ahead of time. No one wants to reach step 6 and learn they needed admin permissions all along. A lead-in such as "Before you start, make sure you have editor access" does the job.

How to write each step

Give one action per step

Each step should ask the reader to do one thing. "Click Save, close the window, and reopen the file" is three steps hiding in one. Readers who lose their place need a number to return to, and that only works if each number maps to one action.

A small exception: you can combine short, sequential menu selections into a single step, such as "Click File > Export > PDF." Google's style guide recommends this angle-bracket pattern for menu paths.

Start each step with a verb

Write steps as direct commands: "Click," "Enter," "Select," "Turn on." Google's style guide asks that the first sentence of every step include an imperative verb, which keeps the action easy to spot.

Compare:

• Weak: "The Share button should then be clicked."
• Strong: "Click Share."

Put the location before the action

Tell readers where to look before you tell them what to do: "In the top menu, click Settings." If you write "Click Settings in the top menu," the reader may start hunting for a Settings link before they reach the location. Google's guide recommends writing in the order the reader needs to follow and stating the location of an action before the action itself.

The same logic applies to purpose. When a step needs a reason, put the reason first: "To keep a copy of the old version, click Duplicate."

State the result after the action

After an important step, tell readers what they should see: "Click Publish. A confirmation message appears at the top of the page." Readers can check they are on track before moving on. Google's guide suggests the action first, the result second, both in the same step. You don't need a result everywhere, only where readers could go wrong or the screen changes unexpectedly.

Keep steps parallel

Use the same sentence pattern for every step. If most steps begin with a verb, don't suddenly start one with "Now you will want to…" Predictable is what you want in a procedure. The US government's plain language guidance on lists makes the same point: items in a list should be built the same way so they serve the same function.

How to handle optional, conditional, and nested steps

Real tasks aren't always a straight line. Here is how to handle the bumps:

• Optional steps: Start the step with "Optional:" so readers can decide right away whether to skip it. For example: "Optional: Add a cover image."
• Conditional steps: Put the condition first: "If you see a warning about missing fields, fill in the fields marked in red." Readers can then skip the step if the condition doesn't apply to them.
• Sub-steps: When one step has smaller parts, nest them under it. Google's style guide labels sub-steps with lowercase letters (a, b, c) and the next level with lowercase Roman numerals.
• Single-step tasks: If a task really is one action, don't number it. Google's guide recommends writing it as one sentence in a bulleted list.
• Warnings: Put a warning right before the step it applies to, not after it. By the time a reader sees a warning below a step, they have already done the thing you were warning them about.

If a procedure keeps branching ("if you're on plan A, do this; on plan B, do that"), consider splitting it into separate procedures, each with its own clear starting point.

Format your instructions for people who scan

Readers rarely read instructions from top to bottom like a story. Eye-tracking research from Nielsen Norman Group describes several scanning patterns, including a "layer-cake" pattern, where people fix mostly on headings and subheadings, and a "spotted" pattern, where they jump to specific words that stand out, such as bold text or list items. Their advice is to support scanning by chunking content into sections and lists, writing meaningful subheadings, and visually styling key words.

For step-by-step instructions, that means:

• Use a numbered list for steps. Numbers show order and give readers a way to find their place again. The US government's plain language guidelines recommend numbering list items when you outline the steps in a process.
• Introduce every list with a lead-in sentence. One line such as "To export your report:" tells readers what the list is for.
• Bold the interface labels readers need to find, such as Save or Settings, and match the wording on screen exactly.
• Use task-based headings when a page holds more than one procedure, so readers who scan the headings can jump straight to the right one.
• Add a screenshot or diagram where a step is hard to describe in words, and label the area the reader should look at.

Step-by-step instructions example: before and after

Here is a typical first draft, written as a paragraph:

To get your report you'll need to go to the reports area, which you can find under Analytics, and then pick the date range you want and choose the PDF format before exporting it. You should get an email when it's ready, though you might need to be an admin.

And here is the same task rewritten as step-by-step instructions:

Export a monthly sales report

Before you start, make sure you have admin access.

1. In the left menu, click Analytics > Reports.
2. In the Date range field, select the month you want.
3. In the Format list, select PDF.
4. Click Export. You receive an email with a download link when the report is ready.

The rewrite has a goal-shaped title, a prerequisite stated up front, one action per step, location before action, and a result where the reader might otherwise wonder what happens next.

Test your instructions with a real reader

You can't judge your own instructions well, because you already know the task. Watch someone else try.

Nielsen Norman Group calls the think-aloud method its number one usability tool: you ask a participant to use the product while saying their thoughts out loud. It is cheap, it needs no special equipment, and a handful of participants is usually enough to show the biggest problems.

For instructions, the test is simple:

1. Pick someone who hasn't done the task before.
2. Give them your instructions and nothing else.
3. Ask them to talk through what they are thinking as they work.
4. Note every pause, wrong click, or question. Each one points to a step that needs fixing.

Rewrite, then test again with a new person. Even one round tends to catch the step an expert writer skips.

Keep your instructions accurate after you publish

Instructions go stale every time the product, process, or screen changes. A few habits help:

• Give each procedure an owner who updates it when the task changes.
• Collect feedback on every page so readers can tell you when a step no longer matches what they see.
• Keep a version history so you can see what changed and roll back if an update causes confusion.

This is the kind of work Sonat is built for. Your team can write in Google Docs or Sonat's editor, publish manuals and help pages with one click, collect reader feedback on every topic, and restore any earlier version when needed. A built-in readability guide helps you keep steps short and clear.

Checklist for writing step-by-step instructions

Before you publish, check that your procedure follows these points. For broader rules on tone and terminology, pair it with a technical writing style guide.

• Has a title that names the goal and starts with a verb
• Lists prerequisites before step 1
• Gives one action per step, starting with a verb
• States the location (and purpose, if needed) before the action
• Shows the result where readers could go wrong
• Marks optional and conditional steps clearly
• Places warnings before the step they apply to
• Uses a numbered list with a lead-in sentence
• Has been tested by someone who has never done the task

Conclusion

Writing step-by-step instructions is less about elegant prose and more about seeing the task through a newcomer's eyes. Start with the goal and prerequisites, give one action per step, show readers where to look and what should happen, and test with a real person before you publish. If your procedures live inside a larger guide, see how to write a user manual.

If you want a simple place to write, publish, and maintain instructions your readers can follow, try Sonat for free.