Screenshot tips for product managers and developers

Bad screenshots waste time. Not bad as in technically poor quality — bad as in the viewer has to do work to understand what they’re looking at. They have to figure out which element you’re referring to, what the expected behavior is, and why you sent this to them.

Good screenshots answer those questions before anyone has to ask.

Bug reports

A screenshot in a bug report serves one purpose: making the bug reproducible without a long description. That means the viewer needs to see:

1. What went wrong — visible in the screenshot
2. Where it happened — enough context that someone can reproduce it
3. Anything non-obvious — annotated, not assumed

The most common failure in bug screenshots is pointing at the wrong level of zoom. A full-screen screenshot with “see the button” in the description forces the viewer to find the button. An arrow pointing at it takes two seconds to add and saves everyone the back-and-forth.

Include the URL bar if the bug is environment-specific. Include the device or OS in the Linear/Jira ticket body — you can’t annotate that in the screenshot, but you can make sure it’s somewhere.

Feature specs and walkthroughs

When you’re documenting a new feature for your team — writing a spec, recording async context, or handing off to design — screenshots are faster than words for anything spatial.

A few habits that help:

• Use a consistent crop across screenshots in the same document. If you’re showing a flow with four steps, crop each one to the same region of the screen. It looks intentional and makes the sequence easier to scan.
• Number your steps with text labels rather than relying on order in the doc. Someone coming back to the doc two weeks later shouldn’t have to count screenshots to understand the sequence.
• Before/after pairs are worth making explicit. Two screenshots side by side labeled “Before” and “After” communicate a change in five seconds. A paragraph describing the change takes longer to read and harder to visualize.

Async product updates

If you’re updating your team on progress asynchronously — in Slack, Linear, or a Notion doc — a screenshot does more than text alone. The key is making it self-contained.

A screenshot with a label is more useful than a screenshot with a caption below it. The person reading at 11pm on their phone will see the screenshot first. If the label is in the image, they get the context immediately. If it’s in the caption below, they have to scroll back and forth.

For Slack especially: export at a size that looks sharp when someone taps to expand it. A screenshot that pixelates on expansion looks careless even if the content is useful.

Redacting before you share

In any screenshot shared beyond your immediate team — to a client, in a public forum, in a changelog — run a quick check for anything that shouldn’t travel:

• Names of users or internal employees who appear in the UI
• Email addresses in settings, account pages, or thread headers
• Internal URLs or admin dashboard paths
• Account balances, card numbers, order details

For bug reports in public issue trackers, this matters especially. If your screenshot includes a user’s name in a thread header, that name is now part of a public bug report.

The fastest improvement

If you’re going to change one thing about how you use screenshots at work: add one annotation before you send. Not five — just one. One arrow pointing at the thing, or one label naming what’s wrong.

The screenshot goes from “something in here needs your attention” to “here’s exactly what I mean.” It takes ten seconds and cuts the back-and-forth in half.