Do screenshots in instructions help? What the research says

The general research says pictures help people learn. The research on software manuals is smaller and more mixed, and one finding stands out: a tightly cropped screenshot can do worse than no screenshot at all. Here is what each body of work found, and the practical rules that follow.

Words and pictures, in general

Richard Mayer has run experiments on multimedia learning for decades. He calls the core result the multimedia principle: people learn better from words and pictures than from words alone. In his 2023 summary, 13 experimental comparisons found that students who learned from words and graphics did much better on a transfer test, one that asks them to apply what they learned, with a median effect size of d = 1.35. An effect size of that kind is large.

What it does and doesn't cover matters. The studies are short lessons in a lab, on how things like tire pumps, brakes and lightning work. They are not studies of software documentation, and they don't test screenshots of a UI. They are a good reason to think pictures can help. They don't settle whether your screenshots do.

Screenshots in software manuals

Researchers at the University of Twente tested screenshots in real software manuals. Their results are smaller and mixed.

Study	What they compared	What they found
Gellevij et al., IPCC 1998	A text-only manual against manuals with full-screen and with partial-screen captures	No difference when the manual was used as a job aid. The full-screen and text-only manuals were both better for learning than the partial-screen one. The authors concluded screen captures "seem not to be vital".
Gellevij et al., IEEE Transactions on Professional Communication, 1999	The same three kinds of manual	For learning, the full-screen and text-only manuals were significantly better than the partial-screen one. No differences for job-aid use. No convincing evidence overall that screen captures belong in manuals.
Gellevij et al., Journal of Experimental Education, 2002	A text-only manual against a visual one where each capture had a job: full screens to show where things are, only the relevant window to check a result	44 students. The visual manual's group finished training 11% faster, scored 14% higher on trained tasks, understood the program better and named screen elements better. During training, the visual group located screen elements faster. On the test afterwards, both groups located them equally well. No benefit shown for checking results, and no sign the pictures overloaded readers.

All three are peer-reviewed. The 1998 and 1999 abstracts don't state a sample size, and those studies mostly found no difference. The 2002 study, with captures designed for a purpose, found clear gains. Present them as mixed, not as proof that screenshots always help. Two signals hold across them: a cropped picture that hides where the control sits did worse for learning than a full screen, and worse than words alone; and showing the whole screen helped readers find things faster while they trained.

Practical rules

Show enough of the screen to find the control. Crop to the part that matters, but keep the landmarks around it: the menu, the panel heading, the corner of the window. A reader has to find the spot on their own screen. In the 2002 study, the manual that worked used full screens for finding things and only the relevant window for checking a result.
Put the picture beside its step. Mayer's results come from words and pictures presented together. A gallery at the end of a page is not that.
Make the words enough on their own. In the 1998 and 1999 Twente studies, the text-only manual beat the partial-screen one for learning. Name the control and where it is, and the picture becomes a check rather than the only instruction.
Keep it matching the product. A screenshot of a screen that has changed shows the reader something they won't find. Readers report them as bugs; see How outdated screenshots show up in real docs.

Alt text

Every screenshot needs alt text. WCAG 2.2 success criterion 1.1.1, Non-text Content, is Level A, the baseline: all non-text content presented to the user needs a text alternative that serves the equivalent purpose.

For a screenshot in instructions, the purpose is to show the reader where they are and what to look for. So:

Say which screen it is, and the state that matters: "The Billing settings page, on the Pro plan".
Name the control the step is about and where it sits: "Change plan is under Current plan, on the right".
Skip "screenshot of" and "image of". Screen readers already announce an image.
If the text beside the image already says all of it, keep the alt text short and don't repeat the step.

Good alt text helps people using screen readers, and it helps AI agents that read the page's text instead of the image. See Your docs' newest readers are AI agents.

Where Screenery fits

Screenery takes care of the fourth rule. Your tests capture each screenshot from the running app, and a push on the default branch replaces the image behind every page that embeds its @latest URL. Because the capture is code, the framing is too: the test decides how much of the screen to show, the same way on every build. See Screenshot automation for docs and READMEs.

Sources

Every page below was opened on 13 November 2026, and each number on this page was checked against it.