Facilitating Successful Design Reviews
A three part approach to promote objective debate
Successful design reviews minimize subjective debate by positioning design work in the context of specific objectives. When we get teams to assess the degree to which designs solve problems, we change the conversation–its tenor, tone, and outcome. As such, good design reviews describe problems and how you solved them. For your design review, consider a simple, three part structure: problems, objectives, and solutions.
Part 1: Reiterate the problems
Design problems provide the source for all our projects. In fact, starting a new project requires our identifying and prioritizing those problems (for insights into how to do that, see my earlier post Discovery Wolves). Between the kick-off and subsequent work, however, the articulation of project objectives gets lost. We sometimes forget to use these in the design review. Instead, we should use them to frame design recommendations and subsequent reviews.
What kinds of problems are there? As User Experience designers, our focus is the user, and addressing their needs. Those, however, are often coupled with business and/or content problems as well. Here are some examples of problems properly framed and expressed as a design input:
Example Problem Statements
- “Users can’t find the information that they need quickly and easily.” User Problem
- “Content is imprecise, inadequate, and not effectively addressing real needs.” Content Problem
- “Publishing new content is time consuming and expensive.” Business Problem
Stating these at the outset, as a summary of the project’s intent, establishes a context for the rest of the conversation.
Part 2: Tie problems to objectives
Participants, without anything else to go on, will rely upon personal preference to judge design work rather than how well designs meet objectives and solve problems. Design reviews without objectives are breeding grounds for aimless feedback.
With the problems summarized, you can recap the design objectives, which align to those problems. We must point back to objectives when reviewers raise questions challenge the design decisions. Ultimately, the objectives provide a rationale for the design decisions, and provide a yardstick for measuring the effectiveness of the design decisions.
Design objectives come in different shapes and sizes. Here are some (sanitized) examples from a project I recently completed:
Example Design Objectives
- Make it easy to scan, preview, and share data.
- Contextualize data points
- Educate users about appropriate use of data.
- Prioritize the most recent data without complicating access to historical data.
Objectives are concrete, specific, and reflect the design problems established early in the project. Reviewing them in the meeting reminds participants what the design must achieve.
Part 3: Show how (and how well) you solved problems
The story culminates in how the design meets objectives and solves problems. One effective technique is rating how well I believe the design accomplishes the objectives. In fact, when presenting a design, I’ll start with the solutions and the relative success of the design. This technique is particularly useful early in the design process when weighing a few different approaches and hashing out the relative priorities of the objectives.
Here’s an example from a recent design document:
How I can objectively review my own work relative to goals? Why I would design something that doesn’t meet all the objectives perfectly?
One view of design is that it resolves tensions between overlapping and conflicting objectives. Equal emphasis on all objectives can yield designs that lack focus or try to pack too much into the user experience. Being transparent about these tensions can lead to worthwhile conversations about priorities.
By taking the problem — solution approach, the design review turns into a discussion for evaluating a design with concrete criteria. The conversation focuses on whether a design meets an objective, which is the right conversation to have. The best solutions emerge when teams can weigh solutions against problems and offer suggestions that move an idea close to those goals.
I encourage you to try this simple structure during your next design review. Get your problems and objectives clarified and review your design exclusively in that context. I’m confident you’ll discover tighter, more effective, and less contentious design reviews.
Originally published at www.eightshapes.com.