Why Everyone in Your Design Review Knows Nothing Will Change (And Shows Up Anyway)

Written by tanyadonska | Published 2025/11/06
Tech Story Tags: product-design | design | startups | startup-lessons | product-management | team-collaboration | leadership | hackernoon-top-story

TLDRDesign reviews aren't about making design better, they're blame distribution. The more people in the room, the worse the feedback gets. "Just thinking out loud here..." becomes code for "I have no useful input"via the TL;DR App

I watched a designer present a checkout flow redesign to fourteen people in a conference room, plus three on Zoom with cameras off.

She'd spent three weeks solving a real problem: users were abandoning at payment because the form asked for information in an illogical order. She'd tested the new flow with six users. All completed checkout faster. The data was clear.

Slide three. She's explaining the user flow. VP of Marketing's phone buzzes. She glances down, looks up: "Can we make the logo bigger?"

The designer blinks. "Sorry, which logo?"

"The one at the top."

"The header logo? It's the same size as our current…"

"Yeah, it feels small. People need to know what brand they're buying from."

The designer pulls up analytics from the previous sprint. "We tested brand awareness during checkout. 94% of users correctly identified…"

"But what if someone forgets?"

Fourteen people on the call. Nobody says anything. Everyone knows this logo debate will take twenty minutes.

Slide seven, someone from Legal who joined forty minutes late: "Can someone catch me up on what we're deciding?"

By the end of the hour: 27 requested changes. Eight about the same color. At least four that directly contradicted each other. One that just said "thoughts?"

The designer left with a notebook full of feedback she knew she'd ignore because shipping anything requires ignoring most of it.

The checkout flow that tested well with users? Never shipped. The designer quit two months later.

What design reviews actually are (when you're honest)

Design reviews aren't about making design better. They're blame distribution.

The more people in the room, the worse the feedback gets. Not because people are stupid—because design reviews optimize for shared liability, not quality.

Here's the actual pattern:

Whoever has the least context speaks first. Usually someone senior who walked in from another meeting, glanced at the slides for thirty seconds, and has strong opinions about button placement.

Everyone else performs contribution. Silence means irrelevance. So people find something—anything—to critique. "Just thinking out loud here..." becomes code for "I have no useful input but need to justify being here."

The designer transcribes without deciding. They're not defending trade-offs. They're nodding, writing, promising to "take another look."

Nobody decides anything. Meeting ends with "lots of good feedback to consider" which means another review next week.

You spent an hour making the design worse. But if it fails, seventeen people share the blame.

The psychological game everyone's playing

Design reviews exist because making decisions alone feels dangerous. If it fails and you decided solo, you're the a**hole who didn't listen. If it succeeds, seventeen people claim credit anyway.

The math is obvious: never decide alone.

I worked with a SaaS company running 12-person design reviews. Asked the founder why so many people. "We want everyone to feel heard."

Translation: we're terrified of someone feeling excluded and making it a problem later.

Here's what "everyone feeling heard" produces: design by committee, where the goal is making no one unhappy rather than making users successful.

The person in the room for 90 seconds has equal voting power as the designer who spent three weeks solving the problem. That's not collaboration. That's liability insurance.

They ran this same review three times for one checkout flow. Same designer, different stakeholder mix each time. By round three, the design was worse than the original. They never shipped it.

But nobody could be blamed. Everyone contributed.

The spreadsheet that revealed everything

A designer showed me her feedback tracker. Sixty-eight rows from eight weeks of review hell. What started as a neat list now had sub-rows, color codes, and chaos.

Green for “implemented.” Yellow for “still discussing.” Red for “contradicts other feedback.”

Twelve green. Eighteen yellow. Thirty-eight red.

Row 14: “Make it simpler.” Row 27: “Add more information.” Same meeting. Both marked high priority. Both red.

Row 43: “thoughts?” From a VP. She’d followed up twice. No reply.

“How many of these actually helped users?” I asked.

She did the math in her head. Long pause. “Maybe… five?”

Five out of sixty-eight. Over eight weeks.

Design reviews aren't about making design better. They're about making stakeholders feel like their opinion matters more than user research.

The version that tested well? Still yellow. Still being “discussed.” Still stuck in a spreadsheet only she ever read.

What actually works (and why most companies won't do it)

Here's what I recommend now:

One decision-maker. Not twelve. One. The person with authority to say yes or no.

Fifteen minutes maximum. If you can't review work in fifteen minutes, the designer hasn't done enough thinking.

Three questions:

  1. What problem does this solve?
  2. How do you know it solves it?
  3. What's the trade-off?

If the designer answers all three with data or clear reasoning, approve it. If they can't, send them back to answer these specific questions.

No feedback collection. You're making a decision. Yes, no, or "answer these questions first."

The SaaS company I mentioned? If they’d been running this model for the past two years, they’d be shipping three times faster than their competitors. Designer retention would be flawless—no one would have left.

Most companies won't do this. Not because it doesn't work—because one person making decisions feels dangerous. What if they're wrong and everyone knows who to blame?

Three signs you're distributing blame, not improving design

More than five people in the room. You're not reviewing design. You're managing anxiety about who gets excluded from decisions.

Feedback contradicts itself in the same session. "Make it simpler" and "add more information" means people are performing contribution, not thinking about users.

Same work reviewed three times. You're not iterating toward better. You're stalling because no one wants to make a decision and risk being wrong alone.

The company with 14-person reviews? Four sessions for a settings page. Twenty-eight people total. Never shipped.

The designer quit. Joined a startup with two-person reviews. Three years later, design director. Still there.

Original company? Fourth designer in two years. Still running 14-person sessions. Still wondering about "retention issues."

Your users don't sit in design reviews. They sit in front of your product wondering why it doesn't work.

Fourteen stakeholders and zero users in the room.

That's not design review.

That's the problem.


Written by tanyadonska | London UX/UI Design Studio for SaaS & Web Products, helping SaaS companies and product teams improve UX.
Published by HackerNoon on 2025/11/06