Because nobody agreed what was being reviewed. Without a stated purpose, a design review becomes six people saying what they would have done differently. That is not a review, it is a group edit, and it produces a website that looks like a committee designed it because one did.
We have sat in plenty of those meetings. The tell is when feedback starts with the words "I just think" and ends somewhere near the colour of a button.
This article is how we run ours instead. It is our process rather than the only correct one, and the principle underneath it is simple: separate what can be measured from what has to be argued.
A design review exists to catch the things that will cost money after launch. Broken flows, unreadable text, pages that fail on a phone, and messages that do not match what the business sells. It is a risk check, not a taste contest, and framing it that way changes who speaks and what they say.
The reframe does most of the work. When people understand they are looking for problems rather than preferences, the conversation gets specific fast.
It also protects the designer. A review with a defined purpose is much harder to hijack with a personal opinion about typefaces.
Twice, and both times before launch. The first review happens on the design while it is still in Figma and changes are cheap. The second happens on the built site in the browser, because a design only reveals its real problems once it is running at actual sizes on actual devices.
Skipping the first review is the expensive mistake. Structural problems found in a static file cost an afternoon, and the same problems found in a built site cost a week of rebuilding components.
Skipping the second is the embarrassing one. Things that looked fine in a design file break in the browser routinely, especially long text, long names, and content that is twice the length the designer assumed.
This is one of the reasons we design in the browser as much as we can. The gap between the picture and the running site is where most late surprises live, and closing it early removes a whole class of problem that shows up in our piece on why most website redesigns fail.
Fewer people than you think, and one person who can decide. We want the designer, the person building it, and the one client-side decision maker who can say yes. Everyone else can send written comments in advance, which they will do more carefully than they would speak.
The single decision maker is the part that matters most. A review with three people who each have partial authority produces contradictory feedback and no resolution, and the designer is left to guess.
Sales and support people are worth including for one specific reason. They know the questions customers actually ask, and they will spot a missing answer faster than anyone in the design conversation.
Keep it short. An hour with four people beats three hours with nine, every time.
The measurable things get checked against published thresholds, not opinions. Performance goes against Core Web Vitals, contrast and target sizes go against WCAG, and either the page passes or it does not. Nobody gets to have a view about whether 3.9 seconds is fine.
On performance, Google's guidance is that Largest Contentful Paint should occur within 2.5 seconds of when the page first starts loading, that pages should have an Interaction to Next Paint of 200 milliseconds or less, and that Cumulative Layout Shift should stay at 0.1 or less. Those thresholds are assessed at the 75th percentile of page loads, segmented across mobile and desktop.
On contrast, WCAG Success Criterion 1.4.3 requires a ratio of at least 4.5 to 1 for normal text and at least 3 to 1 for large text at Level AA. The W3C defines large as 18 point, or 14 point bold, which works out to roughly 24 pixels and 18.5 pixels. The thresholds are exact, and the W3C notes that 4.499 to 1 does not meet a 4.5 to 1 requirement.
On interaction, WCAG Success Criterion 2.5.8 requires pointer targets of at least 24 by 24 CSS pixels at Level AA. We check that on every button and every icon control before anything else gets discussed.
Clarity, hierarchy, and whether the page says the right thing to the right person. These cannot be measured, so we make them answerable instead. Rather than asking whether a page looks good, we ask what a stranger would think the company sells after five seconds on it.
The five second question is the most useful one we have. It converts a vague aesthetic argument into a factual answer that anyone in the room can check by trying it.
We ask a second question about every section: what is this here to do. If nobody can answer, the section is decoration and the page will read faster without it.
Hierarchy gets checked by squinting, which sounds unserious and is not. Blur the page and see what still stands out. If the wrong thing dominates, that is a real finding, and it connects straight to what we wrote about visual hierarchy.
Describe the problem, not the solution. Saying the headline does not tell me what you do is useful. Saying make the headline bigger and blue is not, because it hands the designer a fix without telling them what was broken, and they cannot judge whether it is the right fix.
We ask everyone in a review to phrase feedback as an observation about a reader. When I land here I cannot tell what this costs. That is a finding a designer can solve five different ways.
The other rule is to attach a severity. Blocking, worth fixing, or noted. Without that, everything arrives at the same volume and the important things get buried under preferences about spacing.
Write it down as you go. Verbal feedback in a call evaporates, and the person who remembers it best is rarely the person doing the work.
Find out whether it is a disagreement about facts or about taste, because they need different answers. If it is about facts, test it or measure it. If it is genuinely about taste, the client decides, because it is their business and their brand.
Most disagreements that feel like taste turn out to be about facts underneath. An argument about a hero image is often really an argument about who the customer is, and that one has a right answer the client knows better than we do.
Where we hold firm is on anything that fails a published standard. We will not ship text below the contrast minimum because someone prefers the lighter grey. That is not a preference, it is excluding people who cannot read it.
Being clear about that line early makes the whole relationship easier. Clients respect a studio that says no to a specific thing for a specific reason.
A short list, deliberately. A broken conversion flow, a failed accessibility threshold, content that is factually wrong, and anything that breaks on a common phone. Everything else goes on a post-launch list, because a site that never ships helps nobody.
We are strict about keeping that list short. If everything can block a launch, then blocking loses its meaning and real problems get negotiated away alongside trivial ones.
The corollary is that the post-launch list has to be real. It needs owners and dates, or it is just a way of saying no politely while planning to do nothing.
The rest of the launch day checks sit in our guide to testing a website before you launch it, which covers the technical pass that runs alongside the design review.
Before your next review, write down two things: what the review is for, and who makes the final call. Those two sentences prevent most of the dysfunction we see in design feedback, and they cost nothing to agree in advance.
Then split your checklist in two. Put the measurable items on one side with their thresholds, and the judgement calls on the other with a question attached to each. The measurable side should be settled before the meeting even starts.
If you want a second pair of eyes on a design before it goes live, or you want help setting up a review process your team will actually follow, we are happy to talk it through. Reach us at phoenix.studio and tell us where you are in the project.
Tell us where you want to go. We'll tell you how we'd get you there.