Step Lists: How to Write How-To Steps

A step list is an ordered procedure that takes a reader from a known starting state to a verifiable outcome. Its numbers carry meaning: step 2 depends on step 1, and changing the sequence could waste work, create an error, or prevent completion. Each step explains more than where to click. It gives the reason, action, success state, and recovery path needed to keep moving.

1. Confirm that sequence changes the result. Why: Numbering promises dependency, so false order misleads readers and machines. Action: Try swapping two actions. Success: At least one swap would change, block, or invalidate the outcome. Recovery: If every action still works, replace the sequence with bullets or a checklist.

2. Write the observable success state. Why: Readers need evidence that the action worked before they continue. Action: Name what they can see, measure, download, or test. Success: A person unfamiliar with the draft could decide pass or fail. Recovery: If success depends on judgment alone, add a concrete threshold or example.

3. Add a recovery path for failure. Why: A procedure that assumes perfect execution abandons the reader at the first error. Action: State the safest correction, retry, or escalation. Success: The reader can return to the expected state without guessing. Recovery: If no safe recovery exists, warn before the action and identify who can help.

That live example is deliberately compact, but it still fulfills the step contract. The rest of this page defines how to produce the element consistently across publishing systems.

Why this element matters

Procedural readers want to know what to do now, why it matters, whether it worked, and what to do when reality differs from the happy path. “Click Save” answers only the first question. It leaves the reader to infer what confirmation to expect and what failure means.

The step list reduces that uncertainty by creating a repeated decision rhythm. An imperative title begins with a command such as “Connect,” “Verify,” or “Publish.” The reason establishes relevance before the reader invests effort. The action supplies enough detail to execute. The success state makes completion observable. The recovery path prevents a failed action from becoming a dead end. This is the step contract, and every visible step must satisfy all five parts.

The same regularity improves machine extractability: the ability of a search engine, AI agent, or transformation system to isolate an instruction without losing its role. Stable order, descriptive titles, explicit outcomes, and bounded recovery guidance let a machine distinguish the instruction from its verification.

Numbers do not create that meaning by themselves. They expose meaning that the content already has. When the sequence is genuine, numbering communicates dependency to a scanning reader and preserves position for structured data. When the sequence is artificial, numbering creates a false promise.

When to use it

Use a step list when the reader must perform a procedure in order and each completed action establishes the starting state for the next one. Appropriate uses include account setup, software configuration, a repeatable analysis workflow, a migration, a repair sequence, or a publishing process with dependencies.

Do not use a step list merely because numbers look authoritative. Use bullets when the items are options, examples, ingredients, or characteristics. Use a checklist when items are independent gates that can be verified in any order. Use a comparison table when the reader is choosing among alternatives rather than moving toward one outcome. Use ordinary prose when there are only one or two obvious actions and neither needs independent verification.

Near-miss cases cause most misuse:

• “Ten ways to improve a landing page” is a listicle unless item 4 requires the output of item 3.
• “Before publishing, check the title, links, images, and author” is a checklist because the order does not determine validity.
• “Choose a plan, enter payment details, and confirm purchase” is a step list because each state unlocks the next.
• “If the import fails, try A, B, or C” is troubleshooting guidance. It becomes a step list only when the diagnostic branches must be tried in a defined order.
• A chronology describes what happened over time. It is not a procedure unless the reader can perform its actions to reach the stated outcome.

Run the swap test whenever intent is unclear: exchange two adjacent items and ask whether the procedure remains correct. If every swap is harmless, ordering is decorative and this is the wrong element.

Ready to Monitor Your AI Visibility?

Track how AI chatbots mention your brand across ChatGPT, Perplexity, and other platforms.

Get Started Contact

Where to place it

A step list belongs after the reader understands the outcome and has the inputs needed to begin. Place a prerequisite block immediately above it naming the starting state, permissions, files or data, tools, supplies, time, and irreversible risks. Omit fields that do not apply; never hide a required input inside step 4.

Place an outcome block immediately below the final step. It states the finished condition, the artifact or state the reader should now have, and the next sensible action. This closes the procedure instead of leaving the reader to infer that the absence of another number means success.

The element may appear once as the main procedure in a how-to page or several times as clearly named phases in a longer tutorial. A phase heading must explain the intermediate outcome, and numbering must either continue across phases or use explicit identifiers such as “Phase 2, step 1.” Do not silently restart at 1.

A step list must not sit directly beside another numbered list with a different purpose; a heading or transition must explain the boundary. It must not begin before a warning that changes whether the task is safe to attempt. Do not place a generic call to action between steps, put references between an action and its success state, or insert an unrelated comparison table mid-procedure. Supporting material belongs inside the relevant step only when it helps complete that action; otherwise place it before or after the complete sequence.

Anatomy

The anatomy has three collection-level regions and five repeated step-level regions:

1. Prerequisites: the starting state, access, tools, supplies, time, and important constraints.
2. Sequence label: a descriptive heading that names the procedure and its outcome.
3. Step number: the semantic position, generated by the ordered-list renderer rather than typed into the title.
4. Imperative title: one action-led phrase that lets a scanner predict the task.
5. Why: the dependency, risk, or benefit that justifies doing the step now.
6. Action: the exact instruction, including relevant location, input, and choice.
7. Success and recovery: the observable done state followed by the next safe response when that state does not appear.
8. Outcome: the final state and what the reader can do with it.

The legend stays in the page because labels are content, not artwork. If the design changes, the same semantic regions must remain identifiable without editing pixels.

Stay Updated on AI Visibility Trends

Get the latest insights on AI mentions, brand monitoring, and optimization strategies.

Email address

Subscribe

Design examples

The default variant handles most editorial procedures. A compact variant may reduce spacing but cannot remove contract fields. A screenshot-assisted variant pairs an ambiguous interface step with one focused image. A phased variant groups a long procedure by intermediate outcomes while retaining a coherent overall sequence.

No “minimal” variant may drop reasons or recovery paths. Presentation may compress whitespace, not the editorial contract.

Parameters

These parameters define source content, not optional visual decoration. The source column shows whether a value comes from an attribute, a nested item body, or its first heading.

The normal per-step length is 50–140 words across the five contract fields. Shorter steps tend to omit reasoning or verification; longer steps usually conceal several actions.

Syntax and code examples

The canonical structure follows the element writing rules : the parent holds collection settings, and each repeated step is a nested item. The examples below encode the same two-step fragment for mapping clarity; a publishable procedure should normally contain at least three steps.

Portable Markdown directive

:::step-list{totalTime="PT15M" variant=default}
## Connect and verify the data source

Prerequisites: administrator access and the property identifier.

::item
### Open the property connection screen

**Why:** Starting from the correct property prevents data from being attached to the wrong account.

**Action:** Open Settings, choose Data sources, and select the property identifier shown in the prerequisite block.

**Success:** The selected property name appears in the connection summary.

**Recovery:** If it is absent, confirm account access and reload the property list.
::
::item
### Run the connection test

**Why:** A successful test proves that credentials and permissions work before the first import.

**Action:** Select Test connection and wait for the status response.

**Success:** The interface displays “Connected” with a current timestamp.

**Recovery:** Reauthorize the account; if the test still fails, copy the error code for support.
::

Outcome: the source is connected and ready for its first import.
:::

Hugo shortcode mapping

{{< step-list totalTime="PT15M" variant="default" >}}
Prerequisites: administrator access and the property identifier.
{{< step title="Open the property connection screen" >}}
**Why:** Starting from the correct property prevents data from being attached to the wrong account.
**Action:** Open Settings, choose Data sources, and select the property identifier.
**Success:** The selected property appears in the connection summary.
**Recovery:** Confirm access and reload the property list.
{{< /step >}}
{{< step title="Run the connection test" >}}...{{< /step >}}
Outcome: the source is connected and ready for its first import.
{{< /step-list >}}

This notation defines the adapter contract; authors must use the site’s registered renderer when it is available. This page renders its live example as semantic Markdown and does not introduce a new Hugo shortcode.

WordPress block mapping

<!-- wp:amicited/step-list {"totalTime":"PT15M","variant":"default"} -->
<!-- wp:amicited/step {"title":"Open the property connection screen"} -->
<p><strong>Why:</strong> Starting from the correct property prevents data from being attached to the wrong account.</p>
<p><strong>Action:</strong> Open Settings, choose Data sources, and select the property identifier.</p>
<p><strong>Success:</strong> The selected property appears in the connection summary.</p>
<p><strong>Recovery:</strong> Confirm access and reload the property list.</p>
<!-- /wp:amicited/step -->
<!-- /wp:amicited/step-list -->

Platform output may differ visually, but every field and its meaning must survive.

Examples

Good: verify a domain before collecting data

1. Add the verification record. Why: The record proves control of the domain without exposing account credentials. Action: Copy the exact TXT value into the domain’s DNS settings and save it at the root host. Success: The provider shows the record in its DNS list with no extra quotation marks. Recovery: If it is missing, check that the host field uses the root symbol required by the provider and wait for DNS propagation before retrying.
2. Confirm ownership in the product. Why: Confirmation prevents collection from starting against an unverified property. Action: Return to the verification screen and select Verify once the record is publicly resolvable. Success: The domain status changes to Verified and shows the verification time. Recovery: If verification fails, query the TXT record, compare it character for character, and correct the DNS entry before another attempt.
3. Start the first collection. Why: A verified but idle property produces no baseline. Action: Select Start collection and retain the default scope unless the project requires a documented exclusion. Success: A queued job appears with the verified domain and current time. Recovery: If no job appears, refresh once; then capture the domain, time, and error message for support rather than creating duplicates.

This works because order is real, titles are imperative, checkpoints are visible, and failure guidance is safe.

Bad: improve an article

1. Add internal links.
2. Rewrite the introduction.
3. Check spelling.
4. Add examples.

The list is bad for two reasons. First, its order is arbitrary: spelling could be checked before links, and examples could be added before the introduction. It should be a checklist. Second, every item merely names an activity. None explains why it belongs, how far to go, what counts as success, or what to do when the check fails. Adding more verbs would not fix the semantic mismatch.

Granularity and nesting

One step should produce one meaningful state change. Several clicks can belong to that step when they form one uninterrupted interaction and share one success signal. For example, “Choose CSV, select UTF-8, and export the file” is one step if the observable result is a downloaded CSV. Split it when an intermediate result needs verification, a different permission, a material wait, a decision branch, or a distinct recovery path.

Use the sentence test: if the title needs “and” to join two outcomes, it probably contains two steps. Use the failure test too: if the first half can succeed while the second fails and each requires different recovery, split them.

Nesting is limited to one level and three short substeps. Substeps clarify a tightly bounded action; they do not create a procedure inside a procedure. Promote the sequence to its own page when it has separate prerequisites, more than three actions, multiple screenshots, more than one failure branch, or an outcome that another page could use independently. Link to that sub-procedure, then keep the parent step focused on when to perform it and how to confirm its result.

Screenshot policy per step

A screenshot earns its place when words cannot identify the control or state reliably. Use one when labels are duplicated, the control is hidden in a menu, spatial position matters, the interface uses an unfamiliar icon, or the success state is visually ambiguous. Crop to the task area, preserve enough context for orientation, and describe the relevant state in alternative text and nearby prose.

Omit the screenshot when the interface label is unique and the success state can be stated exactly. Also omit screenshots of routine actions such as selecting a clearly labeled Save button, terminal commands already shown as text, or every screen passed on the way to one meaningful choice. Fourteen screenshots for fourteen obvious steps turn a procedure into a slow, brittle slideshow and make interface changes expensive to maintain.

Use no more than one screenshot per step. If a step needs before, during, and after images, its granularity is probably too broad. Never reference an asset until it exists, and never put essential instructions only inside the image.

Schema markup and accessibility

Schema markup is machine-readable code that describes the meaning and relationships of visible content. When the page genuinely teaches a complete procedure, the step list may feed a Schema.org HowTo object expressed as JSON-LD . The mapping is direct:

Markup must mirror the visible procedure exactly. Never add hidden steps, combine two visible steps into one schema item, reorder them, or omit recovery guidance to make the structured version shorter. Do not apply HowTo merely because a page contains a numbered list; the page must describe a completable process.

Accessibility begins with an <ol> containing one <li> per step. The number and order must remain available to assistive technology. Do not type numbers into headings, because copied text, CSS counters, and screen-reader output can disagree. Use logical heading levels, stable fragment identifiers, descriptive screenshot alternatives, and text labels for success and recovery rather than color alone.

Avoid interactive controls that change step order without announcing the change. If steps collapse, the control needs an accessible name and expanded state, and keyboard focus must remain predictable. Printable and no-JavaScript output must retain the entire procedure.

Writing rules

Write 3–10 steps, normally 50–140 words each. Begin every 2–8-word title with an imperative verb and describe one outcome. Explain the reason before an action readers might skip, reorder, or misunderstand. Use calm, direct language.

Every step must contain the five contract fields, though the rendered design does not need to repeat bulky labels when typography conveys them accessibly. The success state must be observable: a status changes, a file exists, a value falls within a stated range, an email arrives, or a test passes. “Everything looks good” is not observable. Recovery must be safe, specific, and proportionate; distinguish retrying from undoing, and identify escalation when the reader cannot repair the state.

Do not put unrelated background, promotional calls to action, testimonials, a second independent procedure, or several decision branches inside a step. Move background above the list, promotion below the outcome, and substantial branches into troubleshooting sections. Do not use “simply,” “obviously,” or “just” for an action that may fail. Never promise a screen, label, time, or result that the product does not actually provide.

Post types that use it

The postTypes frontmatter records these relationships for catalogue and validation use. Only registered playbook post-type pages receive links; other rows describe supported editorial patterns without inventing routes.

QA checklist

Before publication, verify all of the following:

• Swapping adjacent steps would change, block, or invalidate the outcome.
• Prerequisites name every required starting state, permission, tool, supply, and risk.
• The procedure contains 3–10 steps or documents a justified exception.
• Every step has an imperative title, reason, action, observable success state, and recovery path.
• Each step produces one meaningful state change and stays within one nesting level.
• Any sub-procedure that has its own prerequisites or outcome has been separated.
• Screenshots appear only where the interface or state is ambiguous, with no more than one per step.
• The outcome block states what now exists and what the reader can do next.
• Ordered-list semantics, heading order, fragment links, and alternative text work without color or scripting.
• HowTo properties, when present, match visible steps, order, duration, supplies, tools, text, and images exactly.
• Portable Markdown, Hugo, and WordPress mappings preserve the same fields and meaning.
• Links and metadata pass the broader pre-publish QA checklist .

FAQ

How many steps should a step list contain? Use 3–10. Put one or two actions in prose; group or split more than ten.

What makes a numbered list a true step list? Order must affect the outcome, and every step must fulfill the five-part contract.

Does every step need a screenshot? No. Add one only when words cannot identify the interface, location, or state reliably.

Can a step contain substeps? Yes, at one level. Separate any sequence with its own prerequisites, outcome, or more than three actions.

When should it become a checklist? When items can be completed in any order or are independent verification gates.

The Step List is one of the SEO content elements that carries behavior as well as presentation. Its quality is proven when a reader can recover from failure and still reach the promised outcome—not when the numbers merely look tidy.