Drafting and Structure

How-To Instruction Planner

Plan tested instructions with clear prerequisites, actions, decisions, expected results, warnings, errors, recovery paths, and completion checks.

Free editable Markdown · Technical writers, support writers, and product educators · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Task context

Task and reader: [Enter]
Product/system and version: [Enter]
Device, browser, or environment: [Enter]
Permissions or account level: [Enter]
Prerequisites and materials: [List]
Time, cost, or limit: [Enter]
Risk or irreversible action: [Describe]
Successful end state: [Observable result]

Step card

Duplicate for every action.

Step number and goal: [Enter]
Starting state: [What should be visible?]
Action and exact label: [Write]
Input or choice: [Enter]
Expected result: [What changes?]
Decision branch: [If condition, then path]
Warning before action: [Enter or None]
Evidence tested: [Tester, version, date]

Errors and recovery

Error or symptom: [Copy exact message/behavior]
Likely cause: [Enter]
Safe correction: [Tested action]
Data or progress preserved: [Yes / No / Unknown]
When to stop: [Condition]
Support route and information to provide: [Enter]
Recovery verified by: [Name/version/date]

Release checks

Product reviewer: [Name/date]
Live verification: [URL/version/date]
Update trigger and owner: [Enter]

A new user completed the primary path without coaching.
Important branch and error paths were tested.
Warnings appear before consequential actions.
Labels, links, screenshots, and downloads match the current version.
Keyboard, zoom, narrow layout, and media alternatives were checked.

How to use this template

Define reader, environment, version, prerequisites, risk, and observable completion.
Perform the task and record each action, interface label, decision, and expected result.
Add warnings before risky actions and test common failure and recovery paths.
Ask a fresh reviewer to complete the task from the instructions without assistance.
Correct the final rendered guide and assign ownership for product-change updates.

Define the start and finish states

Describe who performs the task, their permissions and prior knowledge, the product or physical environment, version, device, inputs, cost, time, and irreversible consequences. State what a successful finish looks like and how the reader can recognize it. This prevents instructions from starting halfway through or ending at an action without confirming its result. Put prerequisites before step one, including backups, access, safety equipment, or information the reader must gather. If different readers begin in different states, provide explicit branches rather than mixing them into one sequence.

Write observable action-result pairs

Each step should identify one action using the interface's current label and then state the expected response. Avoid “simply,” “obviously,” and vague verbs such as “handle” or “configure.” Capture decision points: if a setting appears, choose based on this condition; if it does not, follow another verified path. Place warnings before the action that creates risk and explain the consequence without alarmist language. Screenshots can orient readers, but the text must remain complete when the interface changes, images fail, or a person cannot see visual annotations.

Test success, failure, and recovery

Run the procedure from a clean starting state, then test realistic permission, connection, format, and validation errors. Record exact messages, likely causes, safe corrective actions, and when to stop or contact support. Have a fresh reader perform the task without coaching and note where the instructions force guessing. Verify links, downloads, keyboard use, zoom, and narrow layouts in the final page. Assign a product owner and recheck trigger, because an accurate procedure can become harmful when labels, limits, or prerequisites change.

See the fields in context

Fictional example: export a notebook

CloudPencil and its interface are invented. These are not instructions for a real product.

Prerequisite: The fictional user must have editor access and enough local storage before opening Export.
Action-result pair: Select “Markdown bundle”; the imaginary preview shows the notebook title and file count.
Decision: If attachments exceed the fictional limit, remove none automatically—link to a tested split-export path.
Warning: Save current edits before disconnecting; the warning appears before the fictional disconnect action.
Completion: The downloaded archive opens and its manifest lists the expected number of pages.

Frequently asked questions

Should every action be a numbered step?

Number sequential actions. Use bullets for options, notes, or materials that do not represent order.

Where should warnings appear?

Immediately before the action that creates the risk, with the consequence and safe alternative stated clearly.

Are screenshots necessary?

They can help orientation, but instructions should not depend solely on images, color, arrows, or exact layout.

How often should instructions be retested?

On relevant product releases, reported failures, changed limits, scheduled review, or any update to the task path.