A screenshot is better than a description. An annotated screenshot is better than both — when it's done well.
Done badly, it's a full-screen capture with a red scribble somewhere near the middle and a note that says "fix this." The developer squints, guesses, and gets it half right. Here's how to annotate so the person on the other end can't misread you.
The four tools and what each is for
Almost every annotation tool gives you the same four marks. Each has a job.
Boxes: "this area"
A rectangle says "the problem is inside here." Use it for:
- A component that's wrong as a whole — a card, a form, a navigation bar
- A region with a spacing or alignment problem
- Anything where the boundary itself is the point ("this section should be full width")
Keep boxes tight. A box around half the screen is a box around nothing.
Arrows: "this exact thing"
An arrow points at one specific element. Use it for:
- A single word, icon or button
- Small details a box would hide
- Showing movement: "this should move here"
Arrows work best when they start in empty space and end right at the target. An arrow that crosses the content it's pointing at makes it harder to see.
Freehand: "roughly this shape"
A pen or marker is for things boxes and arrows can't express:
- Circling an irregular area
- Sketching the shape you want ("a curve here instead of a corner")
- Striking through something that should be removed
It's the most expressive tool and the easiest to overuse. If a box or arrow would do, use that — it's cleaner.
Text: "here's what's wrong"
A short label on the image connects the mark to the meaning. "Should be 16px," "wrong logo," "remove." Keep it to a few words and place it next to the mark, not on top of the content.
The rule: the mark shows where, the text says what. You usually need both.
Six habits of useful annotations
1. One issue per screenshot. Five annotations on one image become five tasks crammed into one. Split them, or at minimum number them and describe each separately.
2. Say what you expected, not just what's wrong. "Wrong colour" starts a conversation. "Should be the brand teal, like the header button" ends one.
3. Keep enough context. A heavily cropped screenshot of a button leaves the developer guessing which page, which button and which state. Include enough surrounding page to make the location obvious.
4. Use one colour for problems. Red or a bright accent that contrasts with the page. Rainbow annotations look busy and suggest categories that don't exist.
5. Don't cover the problem. Put your text and arrows beside the issue. The developer needs to see what you saw.
6. Mind what's in the frame. Screenshots capture everything on screen — customer data, email addresses, other open tabs. Check before you send, and avoid capturing sensitive information in the first place.
Built-in tools if you're annotating manually
If you're taking screenshots by hand, your operating system already has decent tools:
- macOS: press Shift-Command-4 to capture an area; the preview thumbnail opens Markup, with shapes, arrows, a pen and text.
- Windows: press Windows-Shift-S to capture with Snipping Tool, then use its pen and highlighter to mark up the capture.
- Browsers: some browsers include a screenshot tool (Firefox has one built in), and many screenshot extensions add annotation.
These work. The problem is everything around them: saving the file, attaching it somewhere, describing which page it was, which browser, which screen size. That admin is why so many screenshots arrive without the context needed to act on them.
The faster way: annotate where you capture
The biggest improvement isn't a better markup tool — it's removing the steps between noticing an issue and reporting it.
In pinreview, a reviewer clicks the element they want to comment on, and the tool takes a full-page screenshot automatically. Before submitting, they can annotate it with rectangles, arrows, freehand pen and text. The report then arrives with context nobody has to type:
- The exact CSS selector of the element they clicked
- The page URL, viewport size, browser and OS
- Any console errors at that moment
So the annotation does what annotations are good at — showing intent — while the tool handles the facts. The result lands as a task on a board rather than an attachment in someone's inbox.
For the wider picture of what makes a report actionable, see our visual bug reporting guide.
A quick example
Before: a full-window screenshot, a red scribble around the middle, and the message "this looks weird on my laptop."
After: a pin on the pricing card, a tight box around the three plan names, an arrow at the misaligned "Business" label, and the text "labels should be baseline-aligned, like the prices below." Viewport and browser are attached automatically.
The first starts a thread. The second is a ten-minute fix.
The bottom line
Good annotation is simple: a box for an area, an arrow for an exact element, freehand only when you need it, and a few words of text to say what you expected. One issue per screenshot, and never cover the thing you're pointing at.
The faster route is to annotate where you capture, with the technical context attached automatically. That's what pinreview does, and it's why reports arrive ready to fix.