Design Reviews: Going Beyond the Surface

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).

Early review

In an early design review, you might be looking at UI sketches, or even flowcharts, or product briefs. The team is formulating what the product will be and laying out the user journey in broad terms. Product managers might be very involved at this stage, as well as engineers who are looking to evaluate feasibility. At this point, the main questions to ask are:

• What is the underlying problem and can it be described succinctly?
• Who is your user and will they recognize themselves as the audience?
• Is the problem interesting, addressing a real user need, and is it worth valuable designer and developer time?
• Has the problem been contextualized within a typical user’s journey?
• Is the problem solvable with a technology solution? Be sure to frame the problem as solvable with the resources you have.

A great app will address a clearly laid out problem hypothesis which is instantly recognizable to the target user group.

Mid-stage review

The mid-stage design review is probably most familiar to designers: You are evaluating medium to high fidelity mocks, short videos, prototypes, and early builds. Deliverables may include print outs of screens posted around a room, presented on a large screen, or passed around on a device for people to inspect more closely. These reviews are to evaluate proposed solutions to the problem in more detail. Now your questions should primarily be about whether or not the UX is effectively solving the problem:

• Is your design actually addressing the problem all stakeholders have agreed upon?
• Is the architecture and organization of the app or feature intuitive?
• Is information hierarchy clearly expressed both through visual and interaction design? Don’t clutter your user’s primary task flow.
• Are your colors delightful and useful? Is the gridded layout guiding the eye through data, and is your text the right size to be readable?
• Does the motion design support the information architecture, guide the user through the flow, and match your brand’s character?
• Are you using predictable UI patterns that are recognizable and appropriate for the platform?
• Are you overusing predictable patterns such as cards because many popular apps do?
• Does a new user come away with the correct description of what your app can do for them, and can the user get all the way through to the end of a major task?
• Does the solution show off why people should be using your product over others?

A great app will have a strong solution. The product’s unique value proposition should be obvious at first inspection, and the design should guide the user easily, both adhering to and deviating from platform and UI conventions with purpose.

Post-implementation review

Post-implementation design reviews are important to evaluate finer details and determine how engineering constraints might have affected the work. Reviewers should evaluate full engineering builds of features on the intended platform and on the relevant devices. Look for anything about your expression that is getting in the way of solving your problem for users. Useful questions to ask at this stage:

• How close to design spec is the engineering implementation? Is all interaction, visual, and motion design implemented as it was intended, and is there any inadvertent “jank” making the experience less than perfect?
• Are the text strings on screen helpful and clear? Thoughtless writing makes UI confusing.
• Is your brand fully present and can your users distinguish your app from your competitor’s?
• Are you inadvertently alienating users? Watch out for issues in the areas of accessibility and internationalization for different languages.
• Is it a good player in the platform and device ecosystem? Does it use notifications appropriately, is it screen orientation-independent, and does it support a variety of screen sizes?

A great app will have beautiful design that is on-brand and executed with expertise and loving care. The implementation should be robust enough to accommodate all users. The full expression—problem, solution, implementation—should hold together in a compelling package.

Asking yourself and your team these questions for the first time in a design review can be like stretching muscles you haven’t used for a long time—it’s tough, you might squirm a little, but ultimately, you know it’s good for you. Try sending this article around before your next design review. The more you practice asking the right questions, the easier it will be to get your team focused on what really matters—building a product that brilliantly meets your users’ needs.

Material Design and Google’s developer/design relations teams have run nearly 1,000 design reviews for groups both within and outside of Alphabet.