Screenshots for client feedback and design reviews on Mac

A screenshot does not create clear feedback by itself. It gives the reviewer a shared visual object. The review becomes useful when the image preserves the state, points to one decision, and leaves enough context for someone else to act.

Capture the state before you annotate it

Apple’s Screenshot tool documents full-screen, selected-area, window, and menu capture. Use the smallest capture that still proves the point:

• one component for a spacing or copy question;
• one window for a flow or layout question;
• the full screen when context or placement is the question.

The Control modifier sends the capture to the Clipboard. That is useful for a quick issue or chat, but save an original file when the review needs a durable record. Keep the unannotated capture beside the marked-up copy.

A good filename carries the state: checkout-v3-error-state.png is more useful than Screen Shot 2026-09-21 at 10.14.08.png. Apple’s current guide documents the default naming pattern and Screenshot destinations; project naming remains an editorial practice.

Put one decision on each image

Do not circle every element. Write the question first:

• “Should this button be primary or secondary?”
• “Does the empty state explain what happens next?”
• “Which value should the user trust here?”
• “Is this permission message actionable?”

Then annotate only the region that supports that question. If a review has five unrelated questions, use five numbered frames or one frame with five labeled regions and a matching checklist.

Apple’s Mac User Guide documents the native follow-up: when the floating thumbnail appears, click it to open a window where you can mark up the screenshot or share it. Use that Mac Markup flow for the review annotation and keep the original beside the marked-up copy.

Keep annotations separate from evidence

A red arrow is an annotation. The button, label, and state underneath are evidence. If your tool flattens both into one file, retain the original first.

For sensitive information, cover fake credentials or use synthetic data in the review protocol. Do not assume a blur or pixelation layer is irreversible unless you have tested the exported file. A black rectangle in an editor can be a visual object rather than a destructive redaction.

Share the source with the right access boundary

Figma’s current help page describes sharing files and prototypes for collaboration with teammates and clients, with access determined by the file’s sharing settings. That makes a Figma link a collaboration surface, not a substitute for a screenshot archive.

Use a shared design file when reviewers need to comment in context. Use a static screenshot when the state must remain frozen. If the source is a live prototype, record the URL, version, and access setting in the review note so a later reader knows whether the image and the source can drift apart.

Do not paste a client’s private screen into a public link tool simply because the tool makes comments easy. Check who can view, comment, duplicate, or download the artifact.

Write a text equivalent

A review should remain understandable without the pixels. W3C’s informative-image guidance says alternative text depends on the image’s purpose and surrounding context. For a design review, the text should state the visual fact and the decision it supports:

Checkout page, error state. The primary button is disabled while the address field shows an invalid postal code. Question: should the helper text explain the format before the user submits?

That is more useful than “screenshot of checkout.” It also helps a reviewer who cannot inspect the image at full size.

A repeatable review packet

For each issue or review item, keep:

1. original screenshot;
2. annotated copy;
3. one sentence describing the observed state;
4. one question or requested decision;
5. source URL or screen path;
6. capture date, product version, and viewport if relevant; and
7. reviewer response or chosen action.

When comparing before and after, keep crop, displayed scale, and labels consistent. A tighter crop or cleaner sample can make a change appear stronger than it is. State what changed in the product separately from what changed in the presentation.

Public documentation supports the capture, markup, sharing, and text-equivalent workflow; the review outcome still depends on your process.

Source note: Apple screenshot support, Apple Mac Screenshot User Guide, Figma share files and prototypes, and W3C informative images, retrieved September 21, 2026. No client file, account, design workspace, or screenshot was opened for this revision.