How to run a design review with clients — on the live build, not the mockup

A design review on a Figma mockup and a design review on the implemented build are different reviews. The first is about intent; the second is about reality. Both are necessary — but most agencies skip the second, and that's where the worst surprises hide.

Here's how to run the implemented-build review well, with clients in the loop, without it turning into a forty-message email thread.

1. Review on the rendered page, not on screenshots

Screenshots are where design reviews go wrong. They strip the cursor states, the hover transitions, the responsive behaviour, the real fonts at the real sizes, the actual rendering on the reviewer's monitor. By the time a client says "can you make this lighter?" from a screenshot, you've lost the opportunity to interact with the design as it actually is.

Send your client a link to the real, deployed build (staging is fine) and let them review there. The interactions matter. The hover states matter. The font kerning at the actual size matters. The way the layout reflows on their monitor matters more than how it looked on yours.

Why staging is enough

Some teams resist staging review because it's "not the real environment". For design review, this is a non-issue. The design is the same. Anything that's environment-specific (analytics, payment gateways, integration tokens) isn't what's being reviewed. Use staging; you don't have to wait for production.

2. Capture feedback in-context, not in email

Feedback like "the spacing on the third row looks off" is ambiguous because the third row depends on the viewport. Feedback like a pin on the exact element with a comment "this padding feels too tight at desktop" is unambiguous because the location is the message.

Use a tool that lets the client click on the page and drop a comment in place. Every comment then has a precise location and a screenshot. WebPinch does this; so do a few others. The point is: don't run design reviews in Gmail.

The single most useful design-review skill an agency can develop is not visual taste — it's the ability to remove ambiguity from feedback. Pin-based tools do that for you.

3. Review at every breakpoint, deliberately

Design review only catches half the issues if it only happens at one viewport. Most agencies should run desktop, tablet, and mobile reviews back-to-back, with a clean handoff between them.

• Desktop (1440 wide). The canonical view. Most clients will spend their time here.
• Tablet (768 wide). Where odd breakpoint logic surfaces. Nav menus, grids, and image sizes often break here first.
• Mobile (375 wide). Where most real users will visit. Skip at your peril.

Use a tool that toggles viewport size inside the review surface, so the same click-and-comment pattern works at every breakpoint. Otherwise reviewers default to whatever size their browser happens to be at — which is rarely all three.

4. Turn every comment into a Kanban card

A design review with forty comments and no structure is a folder of nags. The same review with forty comments on a Kanban board becomes a burn-down: triage, assign, fix, move to Done. The board is the artefact; the round closes when the board is clear.

Set up columns for the three states that matter:

1. To Do. New comments, untriaged.
2. In Progress. Actively being worked on.
3. Done. Fixed, ready for the client to verify.

Optionally add a fourth column — Won't Fix — for items you and the client explicitly agree to leave. This column is your defence against re-litigation later: "we already decided to leave that, here's the note from round 2."

5. Run rounds, not "the review"

Reviews never end on the first pass. Plan for at least two:

• Round 1 — the bulk of the feedback. Expect 60–80% of total review pins to land here.
• Round 2 — the residual after fixes. Includes regression checks on round 1 items, plus anything the client now sees because the round-1 fixes uncovered it.

For clients, the round structure is comforting. They know what "Round 2" means and they know when they're done. For your team, rounds give a predictable cadence: design, build, review round, fix, review round, ship.

The decision-maker problem

Open the review to too many stakeholders and every pin becomes a debate. Five-person review committees produce contradictory feedback by design — one stakeholder wants more whitespace, another wants more content above the fold; both are right from their own goals.

The fix isn't fewer reviewers — agencies need the broad input. The fix is designating a single decision-maker on the client side who has final say over which pins become tasks. Other stakeholders pin freely; the designated owner decides which pins to action and which to mark "won't fix — leaving as-is".

Make this person explicit in your kickoff. Not the project sponsor, not the most-senior person — the person who'll be available to make these calls quickly. A senior decision-maker who takes a week to respond is worse than a mid-level one who responds in an hour.

The brief-to-the-client matters too

The instructions you send the client at the start of the review shape the quality of feedback you'll get. Compare these two briefings:

Bad: "Here's the staging link, please share your thoughts."

Better: "Here's the staging link. Click anywhere on the page to leave a comment — your comment will be pinned to the exact spot. Please review on desktop and mobile. We're specifically looking for feedback on the hero, the pricing section, and the contact form. Feedback on the typography and colour palette is locked at this stage. Reply with anything you'd like to discuss live."

The second framing tells the reviewer what to focus on and what's out of scope. It saves both sides hours.

What makes design review fast

• Pre-review your own work. Before sending the link, run through it yourself with the lens of an outsider. Catching ten obvious issues yourself saves ten round-trips.
• Batch feedback responses. Don't reply to pins one at a time. Triage in chunks, communicate decisions in chunks.
• Resolve as you go. Move pins to Done the moment the fix is deployed. Don't let the board fill up.
• Set a deadline. "Please complete round 1 by Friday" works. "Whenever you have time" never does.

What kills design review velocity

• Reviewing in Slack DMs. Switch to a pin-based tool.
• Mixing design feedback with bug reports on the same board without tags or filters. Separate the two streams.
• Allowing scope creep mid-round. Defer new requests to a future round, document them, move on.
• Waiting for the perfect implementation before sending for review. Review early; iteration is cheaper than perfection.

The summary

Review on the actual implemented build at every breakpoint. Capture feedback in-context with screenshots and DOM positions saved automatically. Turn every comment into a Kanban card. Run rounds, not "the review". Designate a clear client-side decision-maker. Brief the client deliberately. Burn the board down.

Do those things, and design review stops being the part of your engagement everyone dreads. It becomes the moment you stop guessing and start finishing.