Run a design review that moves work forward

Say what the review is for

Design reviews go wrong in a predictable way. The designer wants help with the order of steps in a task. The product manager is thinking about a launch date. Someone from marketing is looking at the colours. Everyone leaves frustrated, and the designer has a list of contradictory comments to sort through.

The fix is simple: put the review question in the invite, and say it again at the start. “Today I need help deciding between these two approaches to bulk approval.” Then say what’s ready for feedback, what’s already decided and what’s out of scope. That doesn’t stop people challenging things. It just gives the challenge somewhere to land.

Show the task and the evidence

Present the design in context. Who’s the user, what are they trying to do, and what constraints apply? Walk through the screens with that story in mind. Share the evidence that shaped the direction, and be honest about which parts are still assumptions.

Say you’re reviewing an admin tool with a bulk action. Explain why the bulk action exists and which mistakes would be costly. Reviewers can then judge whether the interaction supports the task. Without that context, feedback drifts towards personal taste or comparisons with unrelated products.

Make feedback specific

Ask reviewers to tie each comment to a problem, a consequence or a question. “This feels off” gives the designer nothing to work with. “I can’t tell which requests this action will affect” gives them something concrete to investigate.

It helps to name three kinds of input. Evidence is something observed. A constraint is a real requirement or limit. A preference is one person’s view. Preferences are welcome, but they shouldn’t quietly turn into requirements. And when someone suggests a solution, ask what problem it’s solving. Often the problem is valid and the solution isn’t.

Don’t forget access and the awkward states

A review should look beyond the default desktop view. Ask about keyboard use, readable content, error recovery and what happens with ten times more data. These questions are far cheaper to answer now than after the build.

An internal review can spot accessibility risks, but it’s no substitute for testing with disabled people and running proper technical checks. Make that clear, so no one assumes the review covered it.

Handle disagreement well

When two directions are both plausible, name what the disagreement is about. User behaviour? Delivery effort? Brand? Business policy? Each one has a different way to settle it. A quick prototype test for behaviour, an engineering spike for feasibility, a decision-maker for policy.

And please don’t ask the designer to implement every suggestion. The review should sharpen the reasoning, not produce a collage of everyone’s preferences. Someone should own the final call, and the reason for it should be written down.

End with a short record

Close with a two-minute recap:

• Decisions made, and the evidence behind them.
• Changes the designer will explore next.
• Questions that need research or technical input.
• An owner for each follow-up.
• When the work comes back for review.

Keep that record next to the design file so anyone joining later understands why things are the way they are. In our experience of managing and mentoring designers, this habit does more for a team’s confidence than almost anything else: decisions stop being reopened every week.

If your designers are doing good work but reviews keep going in circles, Design Leadership gives your team an experienced outside perspective on the decisions that matter.