How to Use Screenshots for Client Feedback and Design Reviews on Mac

Why screenshots produce better design feedback than meetings

Design review meetings are expensive. You schedule 30 minutes, spend 10 minutes getting everyone on the same page, then get feedback like "I don't love it" or "can we make it pop more?" The problem isn't the client — it's the format. Real-time discussion doesn't give people space to think carefully about visual design.

Screenshots flip this dynamic. When a client receives an annotated screenshot with specific questions — "Does this button hierarchy feel right?" or "Is this the correct logo placement?" — they respond with specific answers. The visual reference eliminates ambiguity. There's no "which screen are we talking about?" confusion. Every piece of feedback maps to a precise location in the design.

This approach also creates a paper trail. Six months later, when someone asks why the navigation was redesigned, you have a thread of annotated screenshots showing exactly how the feedback evolved. Try finding that in a meeting recording.

Setting up your capture workflow for design reviews

Consistency matters more in design review screenshots than anywhere else. If you're asking a client to compare two options, both screenshots need identical viewport widths, zoom levels, and surrounding context. A difference in capture conditions becomes a false signal that distracts from the actual design choices.

Standardize your viewport

Pick a single browser width for all review screenshots. 1440px works well for desktop designs — it's the most common laptop resolution and shows enough of the layout to judge spacing and hierarchy. For responsive reviews, capture at 1440px, 768px, and 375px to cover desktop, tablet, and mobile.

Set your browser window size precisely before capturing:

# Set Chrome window to exact width for consistent captures
osascript -e 'tell application "Google Chrome" to set bounds of front window to {0, 0, 1440, 900}'

Capture the right amount of context

A common mistake is screenshotting just the component you're asking about. Clients need surrounding context to evaluate a design decision. If you're asking about a card layout, show the full page section the cards live in. If you're asking about a button style, show the form it belongs to.

Use Cmd+Shift+4 to select a region that includes enough context without overwhelming the viewer. Include at least one full "parent" level above the element you're asking about.

Remove distractions before capturing

Before you screenshot for a review, clean up anything that isn't the design:

• Close browser DevTools and extensions panels
• Hide bookmark bars and sidebars
• Use a neutral browser profile without personal bookmarks
• Clear any notification badges or popups
• Hide the macOS dock if it's visible at the bottom

On Mac, press Cmd+Option+D to toggle the Dock's auto-hide. This keeps the focus on the design, not your desktop setup.

Annotating screenshots for clear feedback

Raw screenshots are ambiguous. When you send a bare screenshot with "thoughts?", you'll get scattered feedback about whatever catches the client's eye first — usually something irrelevant to what you actually need decided. Annotations direct attention and frame the conversation.

Use numbered callouts

Number each annotation point (1, 2, 3) and pair them with specific questions in your message. This gives the client a clear structure for their response:

• 1 — "Does this heading size feel right relative to the subheading?"
• 2 — "Should the CTA button be green (action) or blue (brand)?"
• 3 — "Is the spacing between cards too tight on this row?"

Clients can reply with "1: yes, 2: green, 3: add more space" instead of writing paragraphs that you have to interpret.

Highlight specific areas

Use semi-transparent colored rectangles to highlight the areas you're asking about. Red or orange boxes draw attention immediately without obscuring the design underneath. Avoid opaque shapes that hide the very thing you're asking about.

macOS Preview works for basic rectangles: open the screenshot, use the rectangle shape tool, set the fill to a semi-transparent color, and draw over the area. For more control — numbered callouts, arrows with labels, blur for redaction — use a dedicated annotation tool.

Show alternatives side by side

When presenting design options, put them in a single image rather than sending multiple files. A side-by-side comparison eliminates the "which one was that?" problem. Label each option clearly — "Option A: Full-width hero" and "Option B: Split layout" — so the client can reference them by name.

For before/after comparisons, place the current state on the left and the proposed change on the right. This matches the natural reading direction and makes the difference immediately scannable.

Structuring a design review round

A design review isn't just "send screenshots and wait." The structure of how you present work determines the quality of feedback you receive.

Limit scope per round

Send 5–8 screenshots maximum per review round. More than that triggers decision fatigue — clients start approving everything just to get through the list, or they fixate on one minor issue and ignore the rest. If your project has 20 screens to review, break them into logical groups and space the reviews a day apart.

Frame what kind of feedback you need

Tell the client explicitly what level of feedback this round requires:

Without this framing, you'll get final-polish feedback on wireframes ("can we make the button blue?") and layout feedback on polished designs ("actually, can we move the sidebar to the right?").

Provide a response template

Make it dead simple for clients to respond. Include a template in your message:

Screenshot 1 (Homepage hero):
- Approved / Needs changes
- Notes:

Screenshot 2 (Pricing cards):
- Approved / Needs changes
- Notes:

Screenshot 3 (Footer layout):
- Approved / Needs changes
- Notes:

Clients are busy. The easier you make it to give structured feedback, the faster you'll get it and the less time you'll spend interpreting vague responses.

Comparing design versions over time

Design projects evolve through iterations. Being able to show how a design changed — and why — is valuable for keeping clients aligned and preventing scope creep.

Name your screenshots systematically

Use a naming convention that makes versions sortable and searchable:

project-name/
  review-01-wireframes/
    01-homepage.png
    02-pricing.png
    03-dashboard.png
  review-02-visual/
    01-homepage.png
    02-pricing.png
    03-dashboard.png
  review-03-polish/
    01-homepage.png
    02-pricing.png

When a client asks "what did the homepage look like in the wireframe stage?", you can pull up the exact screenshot in seconds.

Create before/after composites

When you make changes based on feedback, show what changed. A before/after screenshot composite makes it easy for clients to verify their feedback was addressed without re-reviewing the entire design.

Capture both versions at identical settings, then combine them with a clear divider and labels. This also protects you — if a client says "I never asked for that change," you can point to the annotated screenshot from the previous round showing their exact request.

Sharing screenshots securely with clients

Design work is often confidential. You don't want pre-launch screenshots of a client's product floating around on public image hosts.

Use expiring share links

Rather than attaching screenshots directly to emails (where they live forever in everyone's inbox), use share links that expire after a set period. Most screenshot tools offer this — set links to expire 30 days after the project wraps. This limits exposure if a client's email gets compromised.

Strip metadata before sharing

Screenshots on Mac include metadata like your computer name, the date and time of capture, and the application used. For client work, strip this metadata before sharing:

# Remove EXIF/metadata from screenshots before sharing
sips -d all /path/to/screenshot.png

This is especially important if you're working under NDA or handling sensitive product designs that haven't been announced publicly.

Blur or redact sensitive data

If your screenshots show real user data, API keys, or other sensitive information in the background, redact it before sending. Use a solid rectangle fill — not a pixelation filter, which can sometimes be reversed. Black or dark gray boxes over sensitive text are the safest option.

Common mistakes in design review screenshots

Asking "what do you think?" with no direction. This produces rambling, unfocused feedback. Always pair screenshots with specific questions that can be answered in one sentence.

Sending screenshots at different zoom levels. If one screenshot is at 100% and another at 125%, the client perceives a size/spacing difference that doesn't exist. Standardize your zoom level across all captures in a review round.

Including lorem ipsum text. Clients get distracted by placeholder text. Use realistic content — even if it's not final copy — so they evaluate the design with appropriate content density and line lengths.

Forgetting mobile views. Sending only desktop screenshots invites feedback that doesn't account for responsive behavior. Include mobile screenshots for any layout-sensitive decisions, even if you only ask "does this stack correctly on mobile?"

Over-annotating. If your screenshot has 15 numbered callouts, the client won't address any of them properly. Maximum 5 callouts per screenshot. If you need more, split it into multiple screenshots of different sections.