How to Write Work Instructions People Can Follow

A new teammate opens a work instruction titled ‘Update the account.’ Step 4 says, ‘Ensure all required information is entered correctly.’ Which fields are required? What makes an entry correct? What should appear after saving? The writer recognizes the path because they already know it. The reader is being asked to guess. That is the central failure this guide fixes.

What is a work instruction?

A work instruction tells a defined performer how to complete one bounded task under stated conditions and how to recognize a correct result. It sits at the execution layer. A process explains end-to-end flow; a procedure or SOP defines the approved method and responsibilities; a policy establishes rules; a work instruction resolves the moment a person must act. Organizations use these labels differently, so define your own document hierarchy instead of treating the names as universal law.

The distinction is practical, not ceremonial. One customer-refund procedure may link to separate work instructions for verifying eligibility, entering the refund, and reconciling the payment. The instruction should not repeat the full policy; it should surface the exact rule or link to its controlled source at the decision point. For the SOP layer itself, see what an SOP is.

Use a performance contract, not a page-count target

Treat each instruction as a small performance contract. The writer promises that a qualified reader who starts in the declared state, follows the actions and branches, and checks the described evidence can reach the declared exit state—or stop and escalate safely. This model forces six questions that attractive templates often leave unanswered.

This does not mean every click needs six labels. It means the document as a whole cannot depend on hidden prerequisites, invisible success, or an unexplained choice. When a user can continue after an action silently failed, evidence belongs beside that step rather than in a distant troubleshooting appendix.

How to write work instructions in 12 steps

1. 1

   Name one observable outcome

   Use a verb and object: ‘Issue an approved account credit,’ not ‘Billing system.’ Define where the task starts and the visible state that means it is finished. Split unrelated outcomes into linked instructions.

2. 2

   Define the real performer

   State role, permission, environment, assumed knowledge, language needs, assistive-technology considerations, and whether the reader performs the task routinely or under pressure. Do not write for an imaginary average employee.

3. 3

   Identify authority and risk

   Locate the current policy, system owner, quality rule, safety control, data classification, and escalation owner that govern the task. Mark claims that require approval. Never infer a consequential rule from one expert’s habit.

4. 4

   Observe a correct real run

   Ask a skilled performer to complete a representative case in the normal environment. Capture actions, system feedback, decisions, searches, waiting, workarounds, and questions. Use synthetic or properly protected data.

5. 5

   Compare at least one variant

   Check a different case, performer, permission level, or system state. Reconcile legitimate variants, personal shortcuts, outdated behavior, and disagreements with the accountable owner before declaring one path standard.

6. 6

   Draft the skeleton from states

   Write the entry state, major state changes, decisions, required records, and exit state first. Then add interface actions. This prevents a transcript of cursor movement from masquerading as an instruction.

7. 7

   Write action-first numbered steps

   Begin with an imperative verb and name the object precisely. Put the environment before the action when context could be ambiguous. Keep one meaningful action per step unless tiny actions form one obvious unit.

8. 8

   Attach feedback to the action

   Describe the result the performer should see, hear, receive, or verify. If success is delayed, say how long to wait, where status appears, and when to stop rather than repeatedly submit.

9. 9

   Expose decisions as conditions

   Use observable if/then criteria, name the source of the rule, and link each branch to its next action. Replace ‘when appropriate’ and ‘if necessary’ with conditions a qualified performer can actually evaluate.

10. 10

    Add failure containment and recovery

    For likely failures, state what not to repeat, what evidence to preserve, whether work can be reversed, who can approve a retry, and how to escalate. Put severe warnings before the hazardous or irreversible action.

11. 11

    Add only useful visual evidence

    Use a focused screenshot for location or state, and short video for motion, timing, or continuity. Redact secrets and personal data, provide meaningful text alternatives, and do not make color or audio the only carrier of necessary meaning.

12. 12

    Test, approve, publish, and trigger review

    Watch a representative user find and perform the instruction without coaching. Correct observed failures, obtain required approval, publish one canonical version at the point of work, and reopen it after system, policy, role, incident, or feedback changes.

Write steps the way people act

Google’s procedure style guidance defines a procedure as numbered steps for a task and recommends imperative verbs, parallel structure, explicit context, one action per step in general, and action before result. Its technical-writing course also recommends active voice for most technical writing. Those are useful defaults because they reveal the actor and reduce grammatical work. They are not a license to omit necessary reasons, warnings, or system feedback.

• Prefer the control’s visible label over its color, position, icon shape, or an internal nickname.
• Preserve exact values, formats, units, tolerances, and time zones when they affect correctness.
• Define unfamiliar terms where they first control an action; do not make a worker hunt through a glossary mid-task.
• Put optional actions behind an explicit ‘Optional’ label and state their effect.
• Use notes for context, not to hide a required action or warning outside the numbered sequence.
• Link shared prerequisites and policies instead of copying them into several documents that will drift apart.

Design decisions and exceptions without creating a maze

A decision is not an action with the word ‘check’ attached. It needs an observable condition, mutually understandable outcomes, and a destination for each outcome. If the branch depends on judgment, provide examples near the boundary and identify who has authority to decide. If the rule changes frequently, link to a controlled table rather than freezing values inside screenshots and prose.

Do not bury the exceptional path merely because it occurs less often. Frequency and consequence are different dimensions. A rare action that can disclose data, duplicate a payment, lock an account, or cause injury may deserve more prominent control than a common reversible click. Have the appropriate domain owner assess the risk; documentation cannot manufacture authorization.

Screenshots and video: evidence, not decoration

Use one screenshot to answer one visual question: which similarly named control, which state, or which boundary? Crop enough to preserve orientation, highlight without hiding the interface, and place it immediately after the related action. The W3C Images Tutorial says informative images need text alternatives that convey their essential information, while decorative images should use a null alternative. A screenshot full of essential instructions is not made accessible by the words ‘screenshot of page.’

Video is useful when a gesture, sequence, timing relationship, or transition is hard to reconstruct from still frames. Keep the numbered text as the exact-reference path and the video as a demonstration. Add accurate captions and, when necessary information is visual, a suitable descriptive transcript or equivalent explanation. Do not record live credentials, tokens, customer data, private messages, or security details merely because blur can be added later.

A reusable work instructions template

Test performance, not reading preference

Digital.gov’s plain-language guidance centers content on a specific audience and includes design and testing for understanding. For work instructions, go further than asking whether a draft seems clear. Give a representative participant a realistic trigger, access to the normal environment, and the same constraints they would have at work. Then observe silently.

1. 1Test discovery. Can the person find the canonical instruction from the situation they face, not from its exact title?
2. 2Test entry. Can they decide whether the instruction applies and identify missing prerequisites before changing anything?
3. 3Test execution. Record hesitations, rereading, wrong targets, searches, skipped steps, questions, and deviations—without rescuing them.
4. 4Test decisions. Include a boundary or exception case and check whether the person chooses the correct branch from the stated evidence.
5. 5Test detection. Introduce a safe simulated failure. Can the performer recognize that the expected response did not occur?
6. 6Test recovery. Can they contain the problem, preserve useful evidence, avoid a harmful retry, and reach the right escalation route?
7. 7Test completion. Does the output meet the stated quality criteria, required record, and handoff condition?
8. 8Revise the instruction, then retest. Treat unexplained variation as evidence about the document or system before blaming the participant.

Track task success, consequential errors, unsupported questions, time to first correct action, recovery success, and defects found later. Reading time and satisfaction can help, but neither proves correct execution. One expert’s successful run proves almost nothing about a new user, a different permission set, or an exceptional case.

Standard work instructions and document control

‘Standard work instructions’ can refer broadly to the approved task method or, in Lean environments, to a more specific operational practice with defined sequence, timing, and work conditions. Do not borrow the label while dropping the surrounding operating system. Define whether the document describes the present approved method, a training reference, a safety-critical control, or a baseline for improvement.

Be precise about standards claims. ISO’s official page says ISO 9001:2015 remains current as of this review and is expected to be replaced by a new edition. The public page does not establish a mandatory universal work-instruction template. If certification or regulation matters, use the licensed applicable text, amendments, jurisdiction-specific requirements, your management system, and qualified advice—not a blog’s document hierarchy.

• Show status and applicable product, equipment, location, or environment version where mismatch could matter.
• Name an owner with authority and capacity to investigate feedback and coordinate approvals.
• Connect system releases, policy changes, incidents, defects, audit findings, role changes, and user reports to review triggers.
• Maintain one controlled source; make exports identify their source and status when offline copies are necessary.
• Retire or visibly mark obsolete copies so search does not return two plausible answers.
• Preserve required history according to applicable rules without leaving superseded instructions in the active path.

Where recording and AI help—and where review begins

Workflow-capture products such as Scribe position themselves around turning performed work into visual steps. That can remove blank-page labor and preserve interface evidence. A capture still records one route through one case. AI can label actions, summarize narration, crop images, and propose steps; it cannot independently validate permissions, decide which expert behavior is authorized, discover unobserved exceptions, or accept the consequence of a wrong instruction.

stepvideo records a browser task and uses interaction evidence to help produce an edited tutorial video and a written guide with step screenshots, narration, voiceover, and captions. Use that shared evidence to draft task execution, then have the performer, process owner, and relevant safety, security, privacy, quality, or legal reviewer validate what belongs. For the broader flow around the task, see workflow documentation. For general procedural writing, see how to write step-by-step instructions. To govern the larger operation, see how to document a process.