How to create a job aid that stays accurate when the UI changes

Remember when writing job aids would take an afternoon? For some, that’s still a reality and it doesn’t end there. Keeping it true after the next release is the part most teams never budget for.

One change management lead we spoke to was preparing an ERP rollout across 30 countries and needed 300 job aids ready before go-live. Now picture the first point release after launch. A menu item gets renamed, and someone has to open 300 Word files to find the ones that mention it.

Another team told us 90% of what they produce is quick reference guides built in PowerPoint, and the effort is out of proportion to what comes out. Those files were right on the day they shipped. But nothing in a PowerPoint slide records which screen a screenshot came from, so every fix starts with a hunt.

What makes a job aid stay accurate when the software changes?

A job aid stays accurate when every part of it can be regenerated from one source: a recording of someone doing the task in the current version of the software. If the steps and the screenshots trace back to that recording, a UI change means you record the workflow again and rebuild the aid. If they don't, you're hunting through a document for every place the old screen shows up.

A regenerable job aid is a one-page, single-task reference whose steps and screenshots come from one recording of the workflow, with every step named by its on-screen label. When the interface changes, you replace the recording and rebuild the aid from it instead of editing text and swapping images by hand.

The usual advice is to cut screenshots and write around the user's intent, so there's less to go stale. That helps, but it gives up the thing people open a job aid for. Someone halfway through an expense claim wants to see the screen they're stuck on. Keep the screenshots, but stop pasting them in, because a pasted screenshot carries no record of which screen it came from or when.

How do you create a job aid that stays accurate?

Five design decisions do most of the work. Make them before the first step, because each is expensive to retrofit.

1. Scope one aid to one workflow, captured in one recording. "Submit a purchase requisition" is a job aid. "Procurement in the new ERP" is a manual that will be half wrong by the second release. One workflow per aid means a UI change touches a short, findable set of files. It also means one recording is enough to rebuild any of them, which is the property everything else here depends on.

If you're also writing the SOP for the same process, keep it in its own document, with the policy and approvals there and only the clicks in the aid. Managing systems change with SOPs and job aids covers how the two split during a rollout.

2. Anchor every step to the on-screen label, never to a position. "Click the blue button in the top right" breaks the moment a designer moves the button. "Select Submit for approval" survives a layout change, and it gives you something to search for when the label itself changes. Copy the label exactly as the software shows it, with the same capitalization, and set it in bold.

That one habit turns a release note saying "Submit for approval is now Request review" into a search across every aid you own. For aids that ship in several languages, use the label from the localized interface, not a translation of the English one, because that's the word the user is looking at.

3. Take screenshots from the recording instead of pasting them. Nobody can tell which version of the screen a screenshot pasted from Snagit shows. Replacing it means taking a new one, then cropping and annotating it to match the rest. A screenshot taken from the recording of the workflow is replaced when the recording is.

At Clueso, step-by-step guides are generated from the same screen recording as the video. Each screenshot is a frame captured as you record, and it stays tied to the clip it came from. When one step changes, you swap the clip for that step and the rest of the aid stays as written. Clueso users have created more than 300,000 step-by-step guides.

On the Enterprise plan, the Auto Updates add-on goes further: hand it a new recording of the workflow and it rewrites the guide's text and the video's narration together. Auto Updates plan details are on the pricing page. If you're starting from a process recording and need an SOP rather than a quick reference, the free SOP generator works from a video.

4. Put the parts that rarely change above the steps. The purpose of the task, who does it, the decision rules ("if the amount is over $5,000, route to finance"), and what success looks like all survive most UI changes. Keep them in a short block at the top, separate from the numbered steps. When the interface moves, you rebuild the steps and leave that block alone.

5. Name an owner and tie the review to releases, not dates. A "review every six months" rule can leave an aid wrong for most of those six months. Put a small header on every aid naming its owner and the system version it was recorded against. Update the date on it each time someone checks it against the live product.

Then make "check the job aids" a line item in the release checklist for that system. The owner should be whoever does the task, because they'll notice a changed screen before the training team does.

What should you do when the UI changes?

Treating a renamed button like a redesign wastes a day, so work out which kind of change you're looking at before you open anything.

Redesigns are where scoping each aid to one workflow saves the most time. Re-recording a four-minute task and regenerating its aid takes less time than finding every stale screenshot in a 20-page document.

How do you find which job aids a release broke?

You need a list of what each aid touches and the release notes for the new version. If every step names its on-screen label in bold, you already have the list, because searching the aid text for a label finds every aid that uses it.

When release notes arrive, pull out every renamed or moved label and search your aid library for each one. Every hit is an aid to fix, and the table above tells you which fix. For labels the notes don't mention, the owner's walkthrough catches them. Spend 10 minutes running the task with the aid open beside the live screen and mark anything that doesn't match.

For a library in the hundreds, keep a register in a spreadsheet with one row per aid, listing its system, owner, and recorded version. Sort it by system when a release lands and you have a work queue before anyone opens a file. How to automatically update help center articles covers the detection problem at that scale, and how to keep a training video library current covers it for video.

Frequently asked questions

What is a job aid?

A job aid is a short reference someone uses while doing a task, not before it. It covers one job, usually on one page, with the steps in order and a screenshot or two where the screen is hard to describe. Training teaches the task, and the job aid is what people keep open beside the screen the fifth time they do it. Longer procedures for operations and shop-floor tasks usually go by work instructions, and the same design rules apply.

What does a job aid look like?

A title names the task, and a short block underneath gives the purpose and any decision rules. Numbered steps follow, each naming the on-screen label to click, with a screenshot where the screen is hard to describe. The best ones end on a one-line success check, so the user knows the task worked. Formats range from a one-page PDF to a printable quick reference card or an in-app snippet.

How do you create a job aid in Word or PowerPoint?

Most enterprise teams start there. Use a table with one row per step, the label in bold in the first column and the screenshot in the second, and file the screenshots in a folder named by system version. Word and PowerPoint have no link between a screenshot and the screen it came from, so the review in step 5 has to carry the whole maintenance load.

What is the difference between a job aid and an SOP?

An SOP defines the official process: who does what, in what order, and why. A job aid helps one person carry out one part of that process in the software. Because a job aid has to change every time its screen moves, and an SOP only when the policy does, keeping them in separate documents stops one from dragging the other out of date. Managing systems change with SOPs and job aids goes deeper on the split.

Pick the job aid your team opened most last month. Run the task with it open beside the live product and count the steps that no longer match the screen. If the answer is more than zero, time how long the fix takes. That number, multiplied by the aids you own and the releases you get each year, is what your current format costs you.