There’s a special kind of nonsense that happens when five people are “approving” one design and not one of them has the authority, discipline, or basic adult courage to make a decision.

You know the setup. One person wants it safer. One wants it bolder. One has “just a few small tweaks,” which somehow require rebuilding the whole thing. One disappears until the deadline. And one swoops in at the end with feedback that should’ve shown up three rounds ago, preferably tattooed on their forehead.

So here’s the real question:

What do I do when five people are “approving” the design, all disagree, and somehow I’m the one wasting time?

You stop treating it like a design problem.

Because it isn’t one.

It’s an approval process for design projects problem. And until you fix that, no amount of talent, speed, or caffeine will save you from death by committee. If this kind of client chaos sounds familiar, start with the bigger picture in The Client Game: How Smart Designers Don’t Get Played, Blamed, or Bled Dry.

The real issue isn’t feedback. It’s unmanaged authority.

Most designers think the mess starts when clients give bad feedback. Cute theory. Wrong.

The mess starts much earlier, when nobody defines who is reviewing, who is deciding, and what kind of feedback is actually allowed. That’s why managing multiple stakeholders feels like herding raccoons through a glass factory. Everyone has opinions. Nobody owns the outcome. You, naturally, become the unpaid janitor of their confusion.

When a project has multiple approvers, you need one thing before the first concept is shown: a clear decision maker role.

Not “the team.” Not “everyone on the thread.” Not “we’ll decide internally and get back to you,” which is corporate dialect for we are about to waste ten business days. One person needs final say. One. Singular. Human. Ideally conscious.

If the client refuses to name that person, congratulations: you’ve identified the risk before it eats your week.

Stakeholder alignment should happen before design review, not during it

Here’s where designers keep getting burned. They present design too early to a group that hasn’t aligned on goals, priorities, or taste. Then they act surprised when the feedback reads like five different briefs written by enemies.

This is why stakeholder alignment matters before anyone touches the work. Before the review, force clarity around a few boring but life-saving things:

  • What is this design supposed to do?
  • What must stay fixed?
  • What is open for exploration?
  • Who is giving input?
  • Who is making the decision?

That is how to handle too many stakeholders in a design project: reduce the number of unresolved questions before design enters the room.

Because once visuals show up, people stop thinking strategically and start reacting emotionally. Suddenly Karen from sales has thoughts about fonts “feeling younger,” and some VP who hasn’t read the brief wants to “see an option that pops more.” Tremendous. Very useful. No notes.

If you’ve ever had to decode comments that sound like horoscope fragments, read how to translate vague design feedback.

Your design review meeting structure is probably the reason approvals drag on

Let me save you a few years of avoidable pain: most review meetings are not reviews. They’re unmoderated opinion festivals with screen sharing.

A solid design review meeting structure does not start with “So, what does everyone think?” That question has ruined more good work than bad typography.

Instead, run the meeting like this:

1. Re-state the objective
Open by reminding everyone what the design is meant to achieve. Not what they personally like. Not what their competitor did. The objective.

2. Define the kind of feedback needed
Ask for feedback against goals: clarity, hierarchy, brand fit, usability, conversion, whatever matters for the project. This keeps people from freelancing emotionally.

3. Go one stakeholder at a time
No pile-ons. No interruptions. No performative brainstorming. Get each person’s input cleanly.

4. Separate feedback from decisions
Not every comment deserves action. Some comments are observations. Some are preferences. Some are contradictions wearing business casual.

5. End with a decision
Not “we’ll circle back.” Not “let’s all think on it.” A decision. Approve, revise with specific changes, or reject with stated reason.

That’s how to run a design review meeting that ends with a decision. It’s not magic. It’s structure. Which is less exciting than chaos, but much cheaper. Figma’s guide to how to run a design critique makes the same point in a much more polite tone than I’m willing to use.

Conflicting feedback is not your job to solve alone

Designers make a huge mistake when handling conflicting feedback: they try to reconcile every opinion themselves. Stop doing that.

If one stakeholder wants minimal and another wants loud, that is not a design tweak request. That is a client-side conflict. Your job is to surface it clearly, not absorb it like some exhausted creative sponge.

Say this, in cleaner client language if you must:

“We have conflicting direction from the review group. Before I revise, I need one agreed priority so the next round moves forward instead of sideways.”

That sentence alone can save a project.

Because how to stop conflicting feedback from multiple approvers is not about being nicer, faster, or more collaborative. It’s about refusing to revise against unresolved contradictions.

Otherwise you create Frankenstein comps. Half safe, half edgy, fully useless. Nielsen Norman Group’s breakdown of derailed design critiques is a good reminder that once feedback loses structure, the work usually follows.

How to get faster approvals from a committee without losing your mind

You want faster approvals? Then stop presenting design like it’s a surprise party.

Here’s what actually works:

Show fewer options

More options do not create confidence. They create politics. If the client has five approvers, do not hand them six routes unless you enjoy volunteer suffering. Present one strong direction, maybe two if there’s a strategic reason.

Label the recommendation

Do not just show work. Recommend it. Explain why this direction best solves the brief. People are more decisive when they feel the room has a spine.

Set response rules

Ask for consolidated feedback by a certain date, in a certain format, from the designated decision maker. Random comments in email threads, Slack, and meeting side chatter are not a process. They’re a crime scene.

Tie revisions to goals

When someone requests changes, ask what outcome the change improves. If they can’t answer, it’s probably not strategic. It’s just a passing mood wearing a blazer.

That’s how to get faster approvals from a committee: reduce ambiguity, reduce options, and increase accountability. If you need a cleaner framework for roles in messy approval chains, Asana’s explanation of the RAPID decision-making framework is worth knowing.

If nobody owns the decision, the project owns you

Here’s the ugly truth. Some clients love collective approval because it protects everyone from responsibility. If the work fails, nobody decided. If the timeline slips, nobody delayed it. If the budget bloats, somehow the designer was “iterative.”

That game only works if you agree to play it.

So don’t.

If you want to know how to get one decision maker for a client project, start before the first round: ask who signs off, who reviews, and what happens when feedback conflicts. Put it in writing. Repeat it in kickoff. Repeat it again before review. People ignore process right up until the moment it saves them from embarrassment.

And when they still try to dump committee confusion on your desk, push it back with calm, grown-up clarity. Not drama. Not ego. Just boundaries.

For teams trying to move faster without rebuilding every screen from scratch, solid systems help. A good library of mockups can speed up reviews, and flexible templates make it easier to test directions without turning every revision round into unpaid archaeology.

FAQ

1. What should I do first when a client says several people need to approve the design?
Ask who reviews, who decides, and how feedback gets consolidated. If that isn’t clear, fix the process before you show concepts.

2. How do I respond when stakeholders give opposite feedback on the same design?
Do not revise yet. Summarize the conflict and ask the final decision-maker to choose one priority.

3. How can I run a review meeting so it actually ends with approval or clear next steps?
Restate the goal, collect feedback against that goal, then close with one outcome: approved, specific revisions, or rejected with a reason.

Final thought: you are not slow, the room is broken

If five people are “approving” the work, all disagree, and somehow you’re being treated like the bottleneck, let me translate that properly:

The project has no decision architecture.

That’s it. That’s the disease.

A healthy approval process for design projects gives input a place, gives authority a name, and gives reviews a finish line. Without that, you are not designing. You are officiating a family argument with brand guidelines.

Set the rules early. Protect the work. Refuse contradictory revisions. End meetings with decisions.

And the next time a committee tries to turn your week into a landfill of conflicting opinions, don’t panic. Just remember: confusion is not collaboration, and delay is not your personality. If a client wants a more serious, scalable process instead of chaos in nicer clothes, point them to pricing.