A design review process that works from mockup to live site

Design reviews have a reputation problem. Too often they’re a meeting where the most senior person shares their taste, the designer nods, and nobody’s sure afterwards what was actually decided. Or they’re an asynchronous free-for-all where twelve people comment on the colour of a button.

A good design review is different. It has a clear question, the right people, feedback tied to goals, and it ends with decisions. And on web projects, it doesn’t stop at the mockup — some of the most important design review happens on the built site, where spacing, responsive behaviour and real content finally meet.

Here’s a process that covers the whole journey.

What a design review is for

Before the process, the purpose. A design review exists to answer: “Does this design solve the problem it was meant to solve, and what should change before we move on?”

That framing rules a few things out:

It’s not a vote on whether people like it.
It’s not the moment to introduce new requirements.
It’s not a presentation where feedback is only collected at the end.

It also rules some things in: knowing the goal of the page, the audience, the constraints and the stage the design is at.

The stages of design review on a web project

Feedback needs change as the work matures. Asking for the wrong kind of feedback at the wrong stage is the most common reason reviews go sideways.

Stage	What you’re reviewing	Good feedback	Feedback to park
Concept	Direction, structure, user journey	“Does this flow match how customers buy?”	Pixel spacing, copy tweaks
Wireframe	Layout, content hierarchy, page types	“The pricing is buried below three sections”	Colours, imagery
Visual design	Typography, colour, imagery, components	“The secondary buttons look disabled”	New pages, flow changes
Build review	The real site vs the approved design	“Card spacing is tighter than the design at 1280px”	Redesigning approved pages
Final polish	Details, states, edge cases	“Hover state missing on footer links”	Anything structural

Share the stage and the scope every time you ask for a review.

Who to invite

The right reviewers depend on the stage, but a useful rule: invite the people whose input will change the design, and nobody else.

Decision-maker: one person who can approve or resolve conflicts. Every review needs one.
Domain experts: product, marketing, content or sales, depending on the page.
Implementers: at least one developer from the wireframe stage on — they’ll spot feasibility issues early.
End-user voice: support or research, if available.

For client projects, agree upfront who the client’s decision-maker is. Five client stakeholders with equal say and no tie-breaker is a recipe for endless rounds.

How to frame the review request

A review request should answer five questions:

What is this? “The new pricing page, visual design, version 2.”
What’s the goal? “Help small teams pick the right plan and start a trial.”
What do you want feedback on? “Hierarchy and clarity of the plan comparison.”
What’s out of scope? “Copy is placeholder; we’ll review it separately.”
By when, and where? “Comments in the review link by Wednesday.”

That last point matters more than it seems. Feedback scattered across chat, email and meeting notes is how comments get lost.

Giving useful design feedback

Whether you’re a designer reviewing a colleague’s work or a stakeholder reviewing an agency’s, the same principles apply.

Tie feedback to the goal. “The plan names are small, so it’s hard to compare plans at a glance” beats “make the plan names bigger”.

Describe the problem before the solution. The designer may have a better fix than yours.

Be specific about location. Point at the exact component. On mockups, comment directly on the frame; on the built site, comment on the element.

Separate preference from problem. Both are valid; label which is which.

Ask questions. “What’s the reasoning for the grey background here?” often leads somewhere more useful than “change the background”.

Acknowledge what works. Not as politeness — so it doesn’t get changed in the next round.

Examples

Less useful	More useful
“I don’t love it.”	“The hero doesn’t make it clear what we sell. A first-time visitor might not know within five seconds.”
“Make it pop.”	“The trial button has less contrast than the secondary link next to it, so the eye goes to the wrong action.”
“Too busy.”	“There are four competing headings in the first screen. Which one is the main message?”
“Use our brand blue.”	“Brand guidelines use #1A4FD6 for primary actions; this button is a lighter blue.”

Running a review meeting (if you need one)

Asynchronous reviews work well for most stages. Meetings help when there’s genuine disagreement or a big direction decision. If you meet:

Share the work beforehand so people arrive with thoughts.
Restate the goal and scope in the first two minutes.
Hear from quieter reviewers first, before the most senior voice anchors everyone.
Capture decisions, not discussion. For each point: what was decided, who owns it.
End with next steps and a date for the next review.

Reviewing the build, not just the mockup

Here’s where many design processes stop too early. The mockup is approved, development starts, and the next time a designer looks closely is after launch — when the spacing is off, the hover states are missing and the layout collapses awkwardly at tablet width.

A build review closes that gap. The designer (and ideally the original reviewers) look at the real site on staging and compare it to the approved design.

What to check:

Spacing and alignment against the design system
Typography: sizes, weights, line heights, line lengths with real content
Responsive behaviour at the breakpoints in between your mockups — 1024px, tablet portrait, small phones
States: hover, focus, active, disabled, loading, error, empty
Real content: long names, missing images, translated text, three-line headings
Motion: transitions and animations feel as intended

The big challenge with build reviews is communicating where the problem is. “The cards are misaligned on tablet” sends a developer hunting. Comment on the live element instead. ClientTweak was built for exactly this: designers open the staging URL, switch between desktop, tablet and phone widths, and pin comments directly on the element that’s wrong. Each comment can save a screenshot of what the reviewer was looking at, so the developer sees the problem without reproducing it.

Handling disagreement

Sooner or later two reviewers will want opposite things. That’s normal, and it’s not the designer’s job to pick a winner by guessing.

Go back to the goal. “Which option better helps a first-time visitor understand what we sell?” turns a taste argument into a question with evidence.
Name the trade-off. Bigger product photos versus more room for copy is a real choice; write down what each option gives up.
Test cheaply if it matters. A quick five-person hallway test or a look at existing analytics often settles it faster than another meeting.
Let the decision-maker decide — and record the decision and the reason next to the comment, so it isn’t reopened next round.

Design review for design systems and components

If you work with a component library, reviews have an extra layer: changes to a shared component affect every page that uses it.

Review components in isolation and in at least two real page contexts.
Check every variant and state, not just the default.
Ask “what else uses this?” before approving a change that looks small.
Note component decisions in the design system documentation, not only in the review thread.

Closing the loop

A review isn’t finished when the feedback is in. It’s finished when every comment has an outcome.

Triage: fix now, fix later, or decline with a reason.
Respond: reply on each comment, even briefly. Silence invites the same comment next time.
Resolve: mark items resolved once fixed, so reviewers can see progress.
Verify: the person who raised the point checks the fix.
Record decisions: especially the ones where you decided not to change something, and why.

If your developers track work in Jira, Asana, ClickUp or Trello, send design comments there rather than copying them by hand — ClientTweak can create tasks from comments in each of those tools.

A lightweight template

Design review: [Page / feature] — [Stage], v[number]

Goal of this page: 
What we want feedback on: 
Out of scope: 
Reviewers: 
Decision-maker: 
Deadline: 
Link: 

Please: one comment per point, tie it to the goal, label preferences.

The short version

Name the stage. Invite the people whose input changes the design. Ask a specific question. Tie feedback to goals. Review the real build at real breakpoints. Close every comment with a decision. Do that consistently, and design reviews become the fastest part of the project instead of the slowest.