A raw screenshot of a full app window asks the reader to find the thing you mean. An annotated screenshot tells them. That's the whole job of annotation: shorten the time between “read the step” and “click the right thing.”
This guide covers which annotation to use when, the style rules that keep a help center looking consistent, and a step-by-step workflow you can run with the free screenshot annotator and screenshot beautifier. Both run in your browser with no sign-up.
Pick the right annotation for the job
Most documentation needs only four kinds of marks. Each one answers a different question for the reader.
| Annotation | Use it to say | Avoid when |
|---|---|---|
| Arrow | “Click exactly here.” Best for small targets like icons and menu items. | The target is already large and obvious, or you need more than two. |
| Box | “This whole area matters.” Panels, form sections, table rows. | It would surround most of the screenshot; crop instead. |
| Highlight | “Read this.” A value, a status label, a line of text. | You're pointing at a button; an arrow or marker is clearer. |
| Numbered marker | “Do these in order.” Multi-action screens that map to numbered steps. | There is only one action; a single arrow is simpler. |
A fifth mark, redaction, isn't about guiding attention but about removing it from private data. We cover it separately in how to redact screenshots.
Style rules for documentation screenshots
Readers notice inconsistency faster than they notice good design. A help center where one article uses red circles, another green arrows, and a third yellow boxes feels unmaintained, even if each image is fine on its own. These rules keep things uniform.
One idea per screenshot
If a screenshot needs a paragraph to explain its annotations, split it. A good test: could you caption the image in one short sentence? “Click New project in the sidebar” passes. “Here are the settings, the save button, the billing link, and where errors show” does not.
Numbered markers match step numbers
When a single screen involves several actions, use numbered markers and make the numbers match your written steps exactly. If step 4 in the text says “Choose a plan,” the marker on the plan picker says 4, not 1. Readers glance between the text and image, and matching numbers make that instant.
A small, fixed color system
- Action color (one bold color, often your brand accent or red): arrows, boxes, and markers for things to click.
- Attention color (a soft highlight like yellow): text or values to read.
- Caution color (used rarely): destructive actions, such as “Delete workspace.”
Write these down and reuse them. Color can't carry meaning by itself, either: the W3C's accessibility guidelines say color should not be the only visual means of conveying information. Pair every colored mark with a number, label, or step text that says the same thing.
Crop first, annotate second
Cropping is the most underrated annotation. Cut the screenshot down to the panel or dialog in question plus enough surrounding UI for orientation, like the page header or sidebar edge. A tight crop often removes the need for a box entirely.
Keep marks out of the way of the UI
Arrows should point at targets, not cover them. Angle them in from empty space, and keep stroke weight consistent so marks look intentional at every image size. Don't stack a box, an arrow, and a highlight on the same element. Pick the one that answers the reader's question.
How to annotate a screenshot, step by step
Here's the workflow for a typical help-article screenshot, using an “Invite a teammate” article as the example.
- Capture at a sensible size. Shrink the browser window to a normal laptop width before capturing, so the UI isn't stretched across a huge empty canvas.
- Clean the scene. Close unrelated tabs and notifications, use demo data, and clear anything private. Redact what you can't avoid.
- Crop to the relevant area. For the invite flow, crop to the Members page header and the invite dialog.
- Add the marks. Drop marker 1 on Invite, marker 2 on the email field, and marker 3 on the role dropdown. In the screenshot annotator, the Step tool numbers markers automatically in the order you click.
- Check against the text. Read your written steps 1–3 while looking only at the markers. If anything is ambiguous, adjust the step text or the mark.
- Polish for publishing. Add consistent padding, rounded corners, and an optional window frame in the screenshot beautifier, especially for images in marketing pages, changelogs, or the top of an article.
- Export and name it. Save a PNG and name the file after the step (for example, invite-teammate-step-1-3.png), so it's easy to find and replace later.
Before and after: a real-world rewrite
Before: A full-screen capture of a settings page with three red circles and the caption “Configure your settings as shown.” The reader has to work out the order, what each circle means, and which values to enter.
After: Two images. The first is cropped to the Notifications panel, with markers 1 and 2 on the Email digest toggle and the frequency dropdown. The caption reads “Turn on Email digest (1), then choose Weekly (2).” The second image shows the Save button with a single arrow. Each image has one job and the text and numbers agree.
Adjust annotation to where the screenshot lives
The same rules apply everywhere, but the amount of annotation should change with the reader's situation. Someone following an SOP mid-task needs precision. Someone skimming release notes needs one quick visual cue.
| Where it appears | Reader's situation | Annotation approach |
|---|---|---|
| Help center article | Following along in the product | Tight crop, numbered markers matching steps, one image per step or per screen |
| Internal SOP | Doing the task under time pressure | Markers on every click target, highlight values to check; see how to write an SOP |
| Support ticket reply | Stuck on one thing | One screenshot, one arrow, one sentence |
| Release notes or changelog | Skimming what's new | A single box or highlight on the new element, plus beautifier polish |
| Onboarding email | Not in the product yet | Minimal marks; let the crop and caption do the work |
Common annotation mistakes
- Circling everything. If every element has a mark, nothing stands out. Remove marks until only the action remains.
- Numbers that drift from the text. A step gets added to the article, but the markers still say 1–3. Re-check numbering whenever steps change.
- Annotating a full 4K screen. Marks become tiny when the image is scaled down in a help article. Crop first so marks stay readable.
- Hand-drawn shapes. Freehand circles look rushed in documentation. Use clean arrows, boxes, and markers.
- Text baked into the image. Long explanations inside the screenshot can't be searched, translated, or edited easily. Keep instructions in the step text and use the image for pointing.
- Forgotten private data. A perfect arrow next to a real customer's email is still a leak. Redact before you publish.
Most of these come down to one habit: treat the screenshot and the step text as one unit. When you edit one, check the other.
Annotation at scale: when manual stops working
Annotating a handful of screenshots by hand is fine. Annotating every step of every guide, then redoing it after each UI change, is where documentation teams lose whole weeks.
Steperly approaches it differently: you record the workflow once and get a step-by-step guide with a screenshot for each step, which stays editable, including annotations. The same source also produces a walkthrough video with click zooms and AI voiceover, and an interactive demo. See how this works for support documentation, or the full workflow in how to turn a screen recording into a step-by-step guide.
For one-off images, the free tools are enough. For a help center you plan to maintain, generate the screenshots from a recording and spend your time on the words.