Write a screenshot style guide before you need one
Look at any product's documentation that has been maintained by more than two people over more than two years. The screenshots disagree. Different window sizes, different themes, different account names, arrows in four colours, some with browser chrome and some without.
None of it is anyone's fault. Everybody made a reasonable local decision, and nobody made a global one.
A screenshot style guide is a short document that makes those decisions once. It takes an afternoon and it stops a slow, permanent decay.
The six decisions
1. Theme. Light or dark, and no mixing. Whichever your product defaults to is usually right, because that's what most readers will be looking at when they compare your image to their screen.
2. Window dimensions. Pick one width and stick to it. Consistent dimensions are most of what makes a documentation page feel deliberate rather than assembled from whatever people had open.
3. The demo account. One account, one name, one avatar, one plausible set of
data. Not your account. Not test test. Not asdfasdf. A believable account
makes screenshots look like the product working; a junk one makes them look like
someone poking at a staging server.
Real, seeded demo data is one of the highest-return investments here, and it pays off in sales material as much as documentation.
4. Chrome or no chrome. Do captures include the browser window, the URL bar, the operating system title bar? All three answers are defensible. What isn't defensible is varying it page to page.
A common split that works: no chrome in feature documentation, chrome included in troubleshooting guides where the URL is part of the information.
5. Annotation style. One colour for callouts, one line weight, one font. Numbered markers for sequences. Decide whether arrows are permitted at all — plenty of teams find that a tight crop plus numbered markers covers everything and looks far cleaner.
Pick a colour that doesn't appear in your product's interface, or the annotation will read as part of the UI.
6. Redaction. Solid opaque shapes, never blur or pixelation — those are reversible transformations rather than deletion. Agree on the colour and the shape so redacted regions look intentional rather than like a rendering bug.
Write down the environment too
The decisions above describe the output. The setup that produces it is worth recording alongside them:
- Which browser, at what zoom (100%, always)
- Notifications silenced, unrelated tabs closed
- Which display, if the team has mixed pixel densities — captures from different densities produce visibly different sharpness in the same document
- The demo account credentials, in your password manager
Someone joining the team in a year should be able to read this and produce a screenshot indistinguishable from one taken today. That's the actual goal.
Keep it to one page
The failure mode for a style guide is length. A twelve-page document describing every conceivable case will not be read, and the screenshots will drift anyway.
One page, six decisions, a short setup checklist, and two example images — one correct, one deliberately wrong. People pattern-match against examples far more readily than they follow rules.
When to write it
Before the second person starts taking screenshots.
That's the moment the cost of not having one starts compounding, and the last moment when writing one doesn't also mean reshooting a backlog. If you're past that point — most teams are — write it now anyway and apply it going forward, reshooting only the pages people actually read.
What you're really preventing
The visible symptom is inconsistency. The real cost is that inconsistent screenshots make a product look unmaintained, and readers extend that judgement from the documentation to the software.
Someone comparing two tools, reading two sets of docs, will notice that one has coherent images and the other doesn't. They will not articulate it as "the screenshots are inconsistent." They'll just trust one product more.