How to run a design review with more than ten people

Wenjing Yang
d.studio
Published in
6 min readDec 18, 2018

Why run such a large design review?

As a design team, we often have design reviews, both formal and informal. We can easily grab two or three colleagues in the office and gather feedback from them. A lot of blog posts suggest that to keep things moving, design review should not have more than six people per session. Then why do we need a design review with the whole design team (more than ten people) together?

We were working on a complicated product suite called Build (www.build.me). It is a cohesive set of tools, and our designers are assigned to various aspects to support the design.

Three issues we always face:

1. Even though we know what we are working on (via our daily stand up), we don’t know other co-workers’ designs in detail.

2. If we only focus on one section, we don’t get a holistic view of the product

3. Often we encounter problems related to other sections of the product that delay the design process

Those issues were affecting the quality of our work, so design review involving the whole team was urgently needed.

How we do it

Before we jump into the review, we take some time to design the session and define basic rules:

- Team members need to join this meeting in person; online meetings don’t work in this context.

- Everyone needs to speak up and share their views.

- Focus — no distractions.

We also spent some time preparing a doc to help the team understand the responsibilities of each role (presenter, reviewer, and facilitator) before, during and after the review session.

The guidance for our design review

Before the session:
We designed a template for our presenter to prepare for their share-out.

A simple template we prepared for our presenters

The template helps our presenters to make sure they prepare the following information:

- Problem statement
- Context
- Intention
- Assumptions they’ve made
- The kind of feedback they’re looking for
- What they hope to get out of this review
- Constraints

It is essential to share this information about the design topic, so the reviewers can understand the design decisions and what to focus on when providing feedback.

During the session:
Ensuring that everyone participates and all feedback is heard is the top priority for the session. We tried several methods but found the following two worked best for us.

The First: “Round Table Method”

Write done feedback during the presentation

During the presentation, every reviewer writes down questions and feedback.

After the presentation, we allow one round of clarifying questions. Any reviewer can ask questions on the problem or the design. If any reviewer doesn’t have questions, they can skip this step.

The first round focuses on something the reviewer likes. Everyone picks the top element they like about the design or the design process and discuss it with the group. No one can skip this session. If two reviewers share the same point, the one behind should choose the second like from his/her list and share it with the group.

Share what we like first, it can be anything

The second and third round focuses on suggestions, concerns, and feedback. Like the first round, all the reviewers need to prioritize their feedback, and everyone needs to share and discuss it with the design owner. If we have time, we end with a final round of likes.

Even though everyone shares only four points of feedback, we have more than ten designers, so important feedback is usually covered.

The Second: KJ-technique (https://articles.uie.com/kj_technique/)

We only use this method when the presenter has one focus question, for example: with the new design proposal, what is the first time user experience of Build like?

During the presentation, all reviewers will note their observations and suggestions on sticky notes to answer the focus question. After the presentation, everyone places their notes on the wall, allowing others to read them.

Put sticky notes on the wall and cluster them silently

Cluster the sticky notes without conversation — following the instruction of KJ-methods — and focus on the important feedback instead of borderline items.

After the clusters are done, we discuss and give a name to each group — these group names should answer the question as well, which will become suggestions/feedback for the design. Finally, we vote for the top five suggestions that the next round of design iteration should focus on.

How do they compare?

Both methods help us to run these sessions efficiently with more than 10 participants. Everyone’s opinion is heard, and feedback is prioritized, so the presenter knows what to focus on for the next iteration.

After the session:
Because we have designers in other locations worldwide who can’t join our meetings, we make it a point to share the design with them in order to receive feedback from the larger team.

The topic owner needs to reprioritize all the feedback because not all feedback is good.

What impact has it made?

It is one of the most important meetings on our calendar. All of our design team members hate heavy meeting schedules, but this is the one that all of us don’t want to miss. Sometimes we will have more than two topics lined up, and we need to choose the main one based on the priorities.

It’s pretty easy to assume the design review is helpful for the presenter (topic owner). What surprised us is that the reviewers themselves get quite a lot from these meetings. The internal design review helps the team to:

1. Get familiar with the latest designs of various parts of the product, know who is working on what, know who to reach out to when similar issues arise.

2. Understand the design process and the rationale behind each design decision, understand the constraints and opportunities others are facing.

3. Gain a wider perspective in comprehending the upcoming design problems; think of the product holistically and not focus solely on the specific topic.

How are we improving our review?

We have a distributed design team, with designers not only in Palo Alto but also in Dublin, Paris, and Bangalore. However, since we only allow people to join the meeting in person, our colleagues cannot join if they’re not in Palo Alto. We tried several ways to improve this situation, but none of them are easy:

1. Our colleagues tried to put their designs online and share them with designers in other locations. However, without explanation, it’s really hard to get the context of the designs.

2. We also tried to record the presentation and share with other locations, but the problem here is that even if you gain some degree of explanation, you miss the clarifying questions, so sometimes feedback is out of context.

3. We considered an online review session with all the locations together once a month. But the quality of online meetings, time differences, and telepresence availability are poor.

How do your team run design reviews?

What are the challenges you are facing? What does your process look like? Tell us about your experience!

--

--