We’ve all been there. You’ve gathered crucial stakeholders to review your latest round of design mocks, and the productive conversation you’d hoped for is just. Not. Happening. Two people are in the corner arguing about hamburger menus, one person is silently writing down critiques, and a cheerful soul is propping up the review with their opinion of how they “like the font you chose.” How do you get your colleagues to focus—and on what, exactly? How do you frame the review so that you all make progress on solving the same problems?
There are many factors that go into creating a successful design review, such as format and number of invitees (see Jake Knapp’s take on how to run a design critique for more examples), and running a design review looks different for every organization, whether it’s large or small. However, one very simple tactic you can use to ensure you get something out of every review is to first clearly articulate (and agree!) on the problem you are trying to solve. This is the heart of a successful design review, because, at the end of the day, all the design details must support the solution to that problem.
Design work can roughly be divided into three stages: early conceptual work, mid-stage mock and prototype creation, and late-stage build. Each of these stages maps to a different part of a product: problem, solution, and implementation. An effective design thoroughly addresses the underlying problem, the expression of a solution in UI, and the implementation of that solution. It’s a multilayered stack that should add up to a design that supports your ultimate goals.
It’s important to ask the right questions depending on which stage you're in. You’ll get insights that are more likely actionable during the current stage of the development process, and it can be appropriate—even enlightening—to pull questions from earlier stages back into later stages to cross-check your work. For example, you might discuss in a mid-stage design review how your app looks confusing because there are too many calls to action. It could be that you haven’t fully discussed the problems your app is trying to solve for the user—you're trying to solve all problems within a certain market, rather than focusing on just one. Knowing which questions to ask during each stage of review will help you see past the surface of your design, and it'll save you a lot of time (which can be better spent elsewhere).