How to Run Design Reviews That Are Actually Useful

A design review is a critique session, not an approval process. That distinction matters enormously. If your design reviews have become meetings where everyone nods until a senior leader weighs in, you have an approval process disguised as a design review.

Here's how to run reviews that produce useful feedback and lead to better design.

The purpose of a design review

A design review serves two purposes:

1. Identify problems — are there UX issues, edge cases, accessibility concerns, or inconsistencies with the design system that the designer missed?
2. Build shared understanding — do the engineers, PMs, and other designers understand what's being built well enough to build it?

It is not: a vote on whether the design looks good, a place for everyone to suggest their preferred visual direction, or a meeting where hierarchy determines the outcome.

When design reviews are treated as critiques, they produce specific, actionable feedback. When they're treated as approval gates, they produce political feedback shaped by who's in the room.

Who to include

Core reviewers (always invite):

• The designer presenting
• One or two other designers who know the context
• The engineering lead or a senior engineer who'll implement it
• The PM who owns the feature

Optional (when relevant):

• A designer who specializes in what's being reviewed (an accessibility expert if the design involves complex interactions, a motion designer if animation is central)
• A customer success rep who hears user feedback firsthand

Keep the group small. More than six people makes design reviews slow and political. If there are more stakeholders who need to weigh in, use asynchronous review first and only bring a smaller group to the synchronous session.

Synchronous vs asynchronous review

Most design feedback doesn't require a meeting. Figma comments are excellent for async review — reviewers can look at the design on their own time, leave specific comments on specific elements, and the designer can respond without a scheduled call.

Use async review (Figma comments) for:

• Visual and layout feedback
• Questions about specific design decisions
• Reviews from stakeholders in different time zones
• Incremental updates and revision reviews

Use synchronous review (a meeting) for:

• First presentation of a complex design direction
• Discussions that require dialogue (design debates with no clear right answer)
• Reviews where you need to walk people through a prototype or flow
• High-stakes decisions where alignment is the primary goal

A good rhythm for ongoing product design: send the Figma file for async review 48 hours before a sync session. Reviewers leave comments. The sync session addresses the complex questions — the straightforward feedback is already handled.

How to structure feedback

Good design feedback is specific, actionable, and separates observation from solution.

Specific: "The contrast between this body text and the background is too low" is specific. "The typography needs work" is not.

Actionable: "I'd recommend darkening this gray to at least gray-700 to meet WCAG AA" is actionable. "This looks off" is not.

Observation before solution: "I'm not sure users will understand that tapping this opens a modal rather than navigating to a new screen" is an observation. Letting the designer solve it is better than "make this a button instead."

Feedback should also distinguish between:

• UX concerns — real usability, accessibility, or comprehension problems
• Personal preference — "I'd use a different color" or "I'd make this bigger"

Personal preference feedback is fine to share, but mark it as such. "Just a personal preference, but I'd consider..." helps the designer decide whether to act on it.

Running the session

As the designer presenting:

• Open with context: what problem is this solving, who are the users, what constraints are you working within
• Walk through the design in flow order, not feature order
• Flag your own uncertainties: "I'm not confident about this decision — I'd appreciate input here"
• Stop talking about what you intended and invite questions

As a reviewer:

• Ask questions before making suggestions: "What happens when a user who hasn't set up their profile reaches this step?"
• Give the feedback, not the redesign: describe the problem you see, let the designer solve it
• Acknowledge what's working, not just what isn't

Tracking and responding to feedback

After a design review, every piece of feedback should be tracked somewhere. Figma comments work for visual feedback. For larger action items, something like Linear is better.

Try Linear Free

Create a ticket for each piece of feedback that requires a design change: describe what needs to change, why, and link to the relevant Figma frame. This creates a paper trail, makes progress visible, and prevents feedback from falling into the void.

Respond to all comments, even if the response is "acknowledged, no change." Designers who don't respond to feedback in Figma comments make reviewers feel ignored, which makes them less likely to give detailed feedback next time.

A simple Notion page works well for tracking the feedback cycle on complex projects — "Feedback received → Being addressed → Resolved" with links to the relevant comments.

Try Notion Free

Separating design taste from UX concerns

This is the hardest part of running good design reviews, and the most important.

When a senior stakeholder says "I'd make that button bigger," is that a UX concern or personal preference? Probably preference. But when they say "I don't think users will understand what this button does," that's a testable UX question worth taking seriously.

Developing the vocabulary to distinguish between these in real time takes practice. When you're not sure, ask: "Is this a concern about usability or accessibility, or is this more of a stylistic preference?" That question clarifies the conversation without being confrontational.