Annotated screenshots for remote teams
Turn a screenshot into an asynchronous review request with numbered markers, a short explanation, and one clear decision to make.
10 nov 2026, 16:08 UTCSend a colleague a screenshot with “Could you take a look?” and they may read it hours after you go offline. If the screen shows several changes, it is hard to tell which one matters, where to reply, or when the decision is due. An annotated screenshot can fill in that context. Each marker points to one detail, and the message says what you want the reader to do.
Put the review request into one sentence
Before capturing the screen, write down what you want decided. “Should we move the save button to the bottom row on narrow screens?” is easier to answer than “Let’s review the new panel.” A design decision, a bug report, and an update about completed work serve different purposes. Combining them in one picture makes it harder to know what counts as a useful reply.
When two decisions genuinely depend on each other, put them in order. The team might settle the button’s position before discussing its wording. A move can change how much room the label has. Explain the dependency briefly and say which decision you need in the first round.
Give readers a path through three markers
Crop to the relevant part of the screen, leaving a heading or section name that helps readers orient themselves. Marker 1 can show the current location, marker 2 the proposed location, and marker 3 a detail that affects the outcome. A circle or arrow drawn over a button can cover the very label you want reviewed. Put the marker beside it and use a thin line to point at the target.
Use a number and a short label alongside colour. This keeps the markers distinct in a greyscale preview or for someone who perceives colour differently. Next to the image, add a line such as “1. Current position in the top row.” The decision should still be understandable without reading text embedded in the image. W3C guidance on use of color
Capture before and after under the same conditions
For a comparison, match the window width, zoom, and sample data in both screenshots. A heading that wraps in one image and fits on one line in another may simply have more room in a wider window. Starting from the same conditions helps readers attribute the difference to the proposed change.
For a bug report, add the steps that led to the screen. For example, “Open Settings, save in the narrow layout, then refresh.” Write the observed and expected outcomes in separate sentences. Use sample records when personal account details or customer data are unnecessary.
Say where the reply belongs
Give the recipient the request, the decision owner, and the deadline. “Can you approve the position marked 2 on the task card by Friday at 14:00 UTC?” works across time zones. If the screenshot is for discussion only, say so. Readers should know whether you are asking for ideas or a decision.
Move the final decision out of the chat and into the record for the work. “Marker 2 approved, bottom row on mobile,” with a link to the final screenshot, may be enough for someone revisiting the task a week later. Before sending, open the image on a narrow screen and read the accompanying message on its own. If readers can still tell where to look and what to do, the request is ready.