Screenshots, and what they cost
They are free to make and they are what makes a procedure go stale. The real cost is not the wrong picture — it is that one wrong picture makes a reader distrust every step they have not checked.
When an image in a procedure carries information words cannot, and when it is a maintenance liability that will make the whole document stale.
Screenshots are the most expensive thing in a document
They are free to make and they are what makes a procedure go stale. Interfaces are redesigned without notice, buttons move, labels change, and the moment one screenshot no longer matches what the reader sees, every screenshot in the document becomes suspect.
That is the real cost: not the wrong picture, but the loss of confidence in the whole page. A reader who finds one step that does not match stops trusting the steps they have not checked, which is the condition most abandoned procedures are actually in.
None of that is an argument against ever using one. It is an argument for using them where they earn their maintenance cost, and writing the rest in words.
When a screenshot earns its place
When the thing being described cannot be named. An unlabelled icon, a region of a screen with no title, a control the reader would have to be shown. Words genuinely fail here and a picture is the shortest correct instruction.
When the risk of picking the wrong one is high. Two adjacent controls with near-identical names, or an irreversible action sitting next to a reversible one. A picture removes the ambiguity that a sentence leaves.
When the reader has to recognise a state rather than perform an action — what the screen looks like when it has worked, or the specific error that means the step failed.
In each of these the picture is carrying information the words cannot. That is the test, and it is stricter than "the picture is helpful".
When words are better and usually shorter
When the element has a name. "Select Save" outlives every redesign that keeps the button called Save, and it survives a change of theme, language or platform. A picture of the Save button does not.
When you are showing a sequence of ordinary clicks. Six screenshots of six clicks is six things to maintain and it reads slower than one numbered list.
When the screen contains anything you would not publish. Customer names, financial figures, internal identifiers, email addresses — this is the ordinary way real data ends up in a document that is later shared outside the team, and it is easy to do without noticing.
When the reader is on a different version, a different platform or a different screen size from the one captured. A picture that does not match their screen is worse than no picture.
If you use one, make it cheap to replace
Capture the smallest useful area. A cropped picture of one control survives far more redesigns than a full-screen capture, and it is faster to remake.
Do not annotate inside the image. Arrows and text baked into a picture mean redoing the annotation every time the picture changes, and they are invisible to anyone using a screen reader. Put the instruction in the caption instead.
Give every image an alt description that says what the step is, not what the picture shows. "Save is at the bottom right of the panel" is useful to a reader who cannot see it; "screenshot" is not.
Number them, and keep the source files somewhere you can find. The reason nobody updates screenshots is that nobody knows where they came from.
Note in the control block which version or release the pictures were taken against. It converts "these look wrong" into "these are from the old version", which is a much cheaper conversation. Document control basics covers what else the block carries.
The same argument applies to screen recordings, more so
A recording captures a whole flow in one artifact, which sounds efficient and means a single change anywhere in it invalidates the entire recording. There is no partial edit.
It also cannot be skimmed. A reader who needs step seven has to scrub for it, and somebody following along has to stop and start a video with the same hands they are working with.
Recordings are good for one thing in particular: showing somebody what a task looks like before they read the procedure. As a supplement they are useful. As the procedure itself they are a maintenance liability with no index.
A default worth adopting
Write the procedure in words first, with no pictures at all. Have somebody follow it who has not done the task before.
Add a screenshot only at the steps where they got stuck or picked the wrong thing. That is usually one or two places in a document, not fifteen.
The result is a document that mostly does not go stale, and whose few pictures are exactly the ones that were doing work. The SOP template is built to be read this way, and every template here is free and needs no account.
Editor's notes
Written by Free Biz Docs about the document above — not reader submissions.
The argument is about trust, not accuracy
A stale screenshot is a small error. What it actually does is make a reader distrust the steps they have not personally checked, which is the state most abandoned procedures are in. That is why the post treats one wrong picture as a document-level problem rather than a step-level one.
The confidential-data warning is the practical one
It is listed among the reasons to prefer words and it is the item most likely to actually bite. Real names, real figures and real identifiers end up in captures without anyone deciding to put them there, and the document is later shared more widely than the screen ever was.
Alt text is not an accessibility footnote here
The instruction is to describe the step rather than the picture, which is better for a reader using a screen reader and better for everyone else too — it means the document still works when the image fails to load, when it is printed, and when it has gone out of date. The accessible version and the durable version are the same version.
These documents are starting structures for you to build on, not professional or legal advice. Anything that will have legal or contractual effect, or that varies by jurisdiction, should be reviewed by someone qualified in the relevant place.
Common questions
- Should an SOP include screenshots?
- Only where words genuinely fail — an unlabelled icon, two adjacent controls that are easy to confuse, or a state the reader has to recognise. Screenshots are free to make and expensive to keep, and one that no longer matches makes a reader distrust every step they have not checked.
- Why do screenshots make procedures go stale?
- Interfaces get redesigned without notice, buttons move and labels change. The real cost is not the wrong picture but the loss of confidence in the whole page — a reader who finds one step that does not match stops trusting the rest.
- When are words better than a picture?
- When the element has a name, because 'Select Save' survives every redesign that keeps the button called Save. When you are showing a run of ordinary clicks. When the screen contains anything you would not publish. And when readers may be on a different version or platform from the one captured.
- How do I make screenshots cheaper to maintain?
- Capture the smallest useful area rather than the whole screen. Do not bake arrows or text into the image — put the instruction in the caption, where it is also available to a screen reader. Keep the source files somewhere findable, and note in the control block which version they were taken against.
- Are screen recordings better than screenshots?
- Worse for a procedure. One change anywhere invalidates the whole recording with no partial edit, and it cannot be skimmed — somebody who needs step seven has to scrub for it. They work well as a supplement showing what a task looks like, and badly as the procedure itself.