Design Review Best Practices

The goal of design reviews

Design is an iterative and collaborative process. It takes many conversations to get from an initial idea to a complete product. Early conversations may be about getting alignment on the problem space. Other conversations may be about getting sign off to start building the design in code. For the purposes of this guide, we are looking at conversations meant to get feedback on work in progress. We’ll call these conversations “design reviews.”

Design reviews give us an opportunity to step back and look at the work critically. This type of conversation helps us ensure our designs are on track. A design review has two goals. First, we must understand the design in context. Next, we give feedback to improve the design so it best meets our business objectives and the needs of our users.

When and who

Casual design reviews are helpful for getting feedback on a design in progress. Scheduling these meetings can be as simple as asking “Do you have time today to look at something?” or can happen at regular intervals, like a weekly check-in. This type of review is often a one on one meeting or a small group. It may include your product owner, a member of your design team, or your lead developer. Stakeholders or subject matter experts aren’t required for casual reviews. Keeping the conversation small is key for these types of reviews.

Formal reviews include polished work shown to stakeholders or the wider team. Depending on the project, you may want at least one stakeholder and your product lead in attendance. Include subject matter experts or other team leads as needed. This type of review occurs at regular intervals and requires advance scheduling. Special reviews can occur before/after major events like a milestone or user testing.

Set context

A critical component of design reviews is context. Clear context gives everyone in the room an equal understanding of the design from which to give feedback. This keeps the conversation productive and informed.

Set context by summarizing:

  • The objective of the design and the personas, scenarios, and goals we are designing for
  • The elements of the design related to that objective
  • Any evidence from user testing or design research that informed this design
  • Where you are in your process
  • What you’d like help on

And if this critique is asynchronous:

  • When you need to receive feedback by

If this is a follow-up review:

  • Recap what the team discussed in the previous meeting
  • Highlight the changes made in response to that feedback

In “Discussing Design,” Adam Connor and Aaron Irizarry recommend sending out an email before the review. This email establishes the context listed above. It includes a link to the design work the team will review. This gives participants time to review the work and think of questions ahead of time. This helps avoid on-the-spot gut reactions. An email may be overkill for a casual review but could be helpful with a large group of when there is a significant work to cover.

An objectives-based review

Once the context is in place, we’ll review the work against our goals and principles.

  • Does our solution help users reach their goals?
  • Does the solution help us to test our hypothesis?
  • Is our solution in alignment with design principles?
  • Where are our solutions in alignment? Where are our solutions out of alignment?

Refer to the speclet, product goals, and design principles as much as possible.

Keep the conversation on topic and moving forward. If you don’t understand a reviewer’s feedback, ask questions. If feedback seems out of left field, refer to the goals and principles.

Design reviews aren’t the place to solve design problems. It’s one thing to discuss options, it’s another to deliver a laundry list of changes. “Make X bigger/brighter/more to the left” talk takes us away from our focus on user objectives and product goals. If the review becomes an editing session, consider scheduling a follow-up meeting to discuss these requests.

Be mindful of time and table or reschedule topics as needed.

If possible, assign someone to take notes for you. This will allow you more headspace to engage in the conversation.

For detailed tips on how to take part in a review, see our follow-up guide: best practices for giving and receiving feedback.

Recap and prioritize

Once we’ve received feedback from a critique, we’ll need to process, prioritize, and follow up on what we’ve heard. This allows us to form clear next steps and preserve project momentum.

  • Document any outstanding questions and plans for how to get them resolved.
  • Make a list of the changes requested and prioritize by
    • The relevance of feedback to product goals
    • How soon the design element is needed
    • The amount the group agrees on the feedback
    • The knowledge and expertise of the person giving the feedback
    • Identify feedback you won’t be acting on. Not all feedback merits a change to the design.
  • Share this information, along with your notes from the critique, with the team.

Follow up with your team as you make progress on your next iteration.

Sources:

Adam Connor and Aaron Irizarry, Discussing Design (O’Reilly, 2015.). Available in hand cheat-sheet form: http://www.discussingdesign.com/downloads/Critique_CheatSheet.pdf

Adam Connor, Discussing Design without Losing Your Mind (Slide Share, 2014.)

Elaine Lin Hering, Thanks for the Feedback: Skills for Receiving Feedback Well (Meetup, 2017 based on the book Thanks for the Feedback: The Science and Art of Receiving Feedback Well by Douglas Stone and Sheila Heen)

Tom Greever, Articulating Design Decisions: Communicate with Stakeholders, Keep Your Sanity, and Deliver the Best User Experience (O’Reilly, 2015.)