How to Write a Visual Work Instruction: A Practical Guide
A visual work instruction is a click-by-click guide for a computer task, built so that a new hire or a covering colleague can follow it without asking anyone questions. Text instructions for software are chronically misunderstood, “click the settings icon” fails when the reader is looking at a screen they’ve never seen before. A screenshot with an arrow doesn’t fail. This template pairs one cropped screenshot per step with one short instruction, plus a verification checklist and a what-to-do-when-it-breaks section.
When to Use This
Use this template for any software task someone has to repeat and that currently depends on tribal knowledge: raising a purchase order in the finance system, setting up a new user account, running the monthly report, configuring a new phone, processing a refund. If the task is done less than twice a year, a work instruction may be overkill. If it’s done monthly and only one person knows how, you’re one resignation away from chaos.
Pick tasks where the cost of getting it wrong is real, wrong data entered, a step skipped, a client charged incorrectly. The template is deliberately narrow: one task, one system, one instruction. Don’t write a guide to “using the finance system.” Write a guide to “raising a purchase order in the finance system.”
How to Fill It Out
The header table. Fill in the task name as a plain-language title, the software or system it covers, who prepared the document, who owns it (the person responsible for keeping it current), the version, the date created, and the review date. The owner is the person who gets told when the software updates and this guide breaks, name a real person.
Before you start. List what the reader needs before step 1: logins, access permissions, files, anything they must have in hand. Then list any precondition, an approval received, a request logged, that must be true before they begin. This section prevents the most common support interruption: someone halfway through a ten-step guide discovering they don’t have access.
Step-by-step instructions. This is the heart of the document. One row per step, three columns: step number, screenshot, action instruction plus expected result. Write exactly one action per step, starting with a verb, “Click ‘Add new user’”, and state the expected result: “A ‘New user’ form opens.” The expected result is what lets the reader self-correct; if the form doesn’t open, they know they’re on the wrong screen before step 5.
Paste one cropped screenshot per step. Crop tightly to the button or field being used, a full-screen capture at unreadable size helps nobody. Add a circle or arrow if the target isn’t obvious. Take screenshots fresh for this document; a six-month-old screenshot of a redesigned screen is worse than no screenshot. And never show login credentials, API keys, or personal data in a screenshot, blur or cover them before you paste.
Verification checklist. Three checkboxes covering the proof the task is done: the result is visible where it should be (the new user can sign in), any confirmation email, reference number, or receipt is saved in the stated location, and the requester or manager has been told. If a task can’t be verified, it can’t be handed over, this checklist is what makes the document trustworthy.
If something goes wrong. Write the one most common error, what causes it, and who to contact. One error is enough, this isn’t a troubleshooting manual. Name the person or role to contact and, critically, tell the reader when to stop trying: “If you see ‘You do not have permission,’ stop and contact the system administrator, do not keep retrying.” Repeated retries are how small mistakes become locked accounts and corrupted data.
The screenshots note. The template includes a note that screenshots show third-party software for internal training only, that the software provider’s terms apply, and that credentials must not appear in screenshots. Keep it in the document, it’s your reminder to blur secrets before sharing.
Common Mistakes
1. Multiple actions in one step. “Click Save, then go to Settings and enter the reference” is two steps. When one step contains two actions, the reader who fails the second one doesn’t know which half worked. One action per step, always.
2. Screenshots that show everything and highlight nothing. A full desktop capture with a 12-point font reduced to thumbnail size is decoration, not instruction. Crop tight, annotate clearly, and delete screenshots that don’t earn their space.
3. No expected result. Without the “what you should see next” line, the reader follows steps blindly and only discovers a wrong turn at the end, or never. The expected result is the cheapest quality check in the whole document.
4. Out-of-date screenshots. Software interfaces change. A guide whose screenshots no longer match the live screens teaches people to ignore guides. Review this document after every software update, not just on the annual schedule.
Who Needs to Sign Off
The preparer drafts the guide, usually the person who actually does the task. The procedure owner reviews it for accuracy and approves it. If the task touches another team’s system or data (finance, IT, HR), have a representative from that team check the relevant steps. A guide that tells someone to do something in another department’s system without that department’s knowledge will be unwelcome the first time it’s used.
How Often to Review and Update
Review the guide annually at minimum, the review date in the header is there for this. But the real trigger is software change: any interface update, new version, or system migration means checking every screenshot and every step before the next person uses it. Assign this check to the procedure owner and make it part of the change process, not an afterthought. When you update, bump the version number and record the new review date.
Download the free Visual Step-by-Step Work Instruction Template.