How To Stop Endless Stakeholder Reviews

You've been there before. Overlapping deadlines, conflicting stakeholder priorities, and design reviews turning into endless cycles of feedback without clear decisions. It's frustrating, inefficient, and often leads to poor UX compromises.

Yesterday I stumbled upon Parvaneh Toghiani's honest case study on how to deal with exactly this challenge. Parvaneh outlines a very practical framework to make design reviews much more systematic and productive. Let's see how it works.

The Goal Is Not Just A Sign-Off #

One of the mistake I frequently made is assuming that the goal of a design review is to simply get a sign-off. As a result, often I'd focus way too much on presenting and defending my design choices, my way of thinking, my big vision. Just like Parvaneh, I often talked about consistency and alignment, showed too many alternate solutions, focused too much on fine little details that didn't matter that much yet.

In most design reviews, the goal is actually different. It's to be aligned about the direction, and the next steps the team is committed to taking on next. Troubles always start when we guide our work based on big assumptions and wrong expectations from both sides. Parvaneh suggests breaking reviews into 3 distinct categories:

• Alignment (Problem definition) Align on the PRD and discuss concept sketches early.
• Evaluation (Design iteration) Get actionable feedback on 2–3 tangible proposals.
• Sign-off (Solution space) Review final design, priorities, implementation details.

When in a meeting with senior stakeholders, we need first to be clear about the type of design review, and then confirm the phase, the purpose and the desired outcome of that review first. It migght sound like a small detail, but it can make quite a difference and avoid misunderstandings down the line.

Use Different Lenses For Different Stakeholders #

It's not surprising, but worth remembering: different stakeholders typically view design through a very different lens. UX language is overloaded with ambiguous terms and labels, so senior stakeholders rarely understand the deliverables and workflows that we present.

For executives, we need to focus on business impact or company priorities. For cross-functional leads, the focus should be on the problem space and how our work addresses it. And for the core team, we dive deep into execution and details.

Before presenting work, it's helpful to always reflect on previous reviews and what has changed since then. Having clear decision criteria and a design recommendation ready is often very much needed to move the conversation forward.

Always Show Ideas on a Spectrum #

One point from the article that I loved is to always show design ideas and concepts on a spectrum: Most Practical ↔ Blue Sky — with the preferred concept in the middle. This framing helps stakeholders understand the trade-offs between options, and why some requirements or late changes might be risky, expensive and cause delays.

One thing I keep reminding myself of is that there is rarely a need to show all the the fine details for each UX concept. Most design reviews are about finding a direction, not pixel-pushing on the spot.

Define the Meeting Type #

One little thing that has helped me in any meeting is to always start by explaining the completeness of our work. There are vast differences between 50%, 75%, 90% done, so we need to set right expecations first. I also try to explain the desired outcome of that design review, and what we actually need. It's also very practical to illustrate a specific meeting type in email invitations, perhaps with a custom emoji:

I love the meeting taxonomy suggested by Rich Watkins:

• 📣 Broadcast Meetings for announcements, townhalls,
• 🥁 Rhythm Meetings for regular status updates,
• 🏗️ Planning Meetings to set timelines, estimates,
• 🛠 Problem-Solving for workshops, solutions finding,
• 🏕️ Exploration for big questions and complex problems,
• 💚 Team Building Meetings for team spirit and collaboration,
• 🪴 Catch-Up Meetings for connecting without agenda,
• 🏆 Review Meetings for retros, 1:1's, perf reviews.

It's a little changes that sets expectation right early, and I'd rather have everything clear before we even start, rather than when we have to undo, redo or start from scratch.

Wrapping Up #

There is no single way to run a design review. During the different phases of the project, we will need different types of design reviews — with different purposes and different goals.

As Parvaneh writes, design reviews aren't just for approvals. They are where influence, trust, and alignment are built. They are incredible opportunities to grow as a designer — to test your storytelling, explain and defend your thinking, and learn how senior stakeholders make their decisions.

Understanding this helps avoid big misunderstandings too late, and giving a bit more confidence to move forward from the very start.

Useful Resources #

• How To Run Effective Design Critiques (+ Figma template), by Jeremy Bird
• How To Defend Your Design Decisions, by yours truly
• "How We Run Design Critiques At Figma", by Noah Levin

Useful Books #

• Articulating Design Decisions, by Tom Greever
• Discussing Design: Improving Communication and Collaboration Through Critique, by Adam Connor and Aaron Irizarry
• Meeting Design, by Kevin M. Hoffman