Design Review: Not Another Bulls***t Meeting

Design Review meetings, or as we at Minute Media like to call them, Product Reviews, are some of the best tools you can use to increase transparency and relations among teams, and of course, the quality of the product. This meeting is an essential part of the design process, purposefully bringing together a diverse group of people to gather feedback while the project is still a ‘work in progress’ allowing for beneficial feedback and an optimized final product. In this post, I will explain how to run a productive design review session that people will actually want to attend.

Why are we having this meeting?

We fill our days with meetings that are not always the best use of our time. However the Design Review, if facilitated correctly, can not only be very productive, but can become one of those events no one wants to miss. We will start by diving into the two main objectives for a design review: to gather feedback and to increase transparency among teams.

Gather Feedback

How often do we get to see and comment on a work in progress? In my experience, not so often. People are more inclined to share projects once they are complete, but when you do this, you usually talk about the process and the obstacles you overcame; the feedback at that point is somewhat irrelevant.

In the design review, we share projects we’re still working on, the challenges we’re still struggling with, and the decisions we can’t seem to make. We share raw material instead of a well-processed solution, making the feedback much more meaningful. We’re not just asking for feedback for the sake of it, but rather to use the input we receive to help tackle the most significant issues in our projects.

When we seek out feedback proactively, we usually go to the same people- our team leader, fellow designers, or maybe even a tech lead. We go to those we trust and feel the most comfortable sharing an imperfect project with. In a design review, however, you will get feedback from people that you would never seek out on your own, widening the range of opinions and solutions.

Increase transparency

Achieving overarching transparency is considered a unicorn in the tech industry and many companies, including ours, are continually trying to find new ways to increase it.

A design review is an excellent tool for serving this purpose. We all tend to work solely on our own tasks, and zooming out to see the bigger picture is not always easy. By forcing people to take a break for an hour and focus on someone else’s problems for a change, the design review allows us to understand other projects and our part in achieving overarching business goals.

Who should attend the meetings?

There is no one answer to this question, and different companies invite different people. Personally, I like to invite the product and design teams to these meetings since at Minute Media, we work in agile teams. Each team has all the relevant talents - Product Manager, Front-End Developer, Back-End Developer, QA Engineer, and of course, a Designer. The team runs together as a perfect unit building and creating their part of the product. However, when you run as a small complete unit, you tend to forget that you’re part of something bigger, and that four other teams with just as essential projects run alongside you. By inviting various teams to these meetings, we open the doors of communication, in turn creating a stronger bond between teams.

Encouraging Designers and Project Managers to join this meeting will make sure the creative juices start flowing. Simple sessions turn into lively discussions about specific features or flows, and we are able to use that inspiration to solve issues outside of the meeting. For instance, a specific solution to a project problem can serve someone else from the group by helping them to finally understand something or because it sparked an idea for something else entirely.

But again, there is no right way to do it. Maybe in your company, it makes more sense to invite the developers and QA members, or maybe it’s the relationship with the stakeholders that needs work - you know best. However, no matter who you choose to invite to the meeting, my suggestion is to limit the group to 6-10 people - any more and you will lose productivity

What is the structure of the meeting?

The meeting must have a clear structure to keep people on track. For our meetings, I like to divide the session into three parts - a short intro, project presentation, and feedback.

As the facilitator of the meeting, I open with a short intro, introducing the speakers - a PM and a designer who work together on the same project - and manage expectations of the group by informing them what stage we are in. For instance, if we’re still in the UX phase, I will ask the group to focus on the user flow rather than the design aspect of the project. If there are any new people sitting in, I will also provide context regarding the meeting’s purpose and what is expected of participants.

After the intro, the presentation starts with the PM giving a general update about the project including answering basic questions such as ‘What are the motives behind this project?’, ‘Where do we stand?’, ‘What are the significant challenges?’ and ‘What blockers are we facing?’. Then, we dive into the user flow at hand, which is presented by the designer. We will usually start with the solution for the ‘happy’ flow, and then show the ‘unhappy’ aspects as well. If we’re debating between two options, we will show both and explain what we like and dislike about each one.

Having both the designer and the PM present, forces them to align and stand behind the project together, while also strengthening their presentation skills.

Once the presentation is finished, we begin the feedback part. There’s a lot to be said about the proper way to give feedback and, without diving into details, the feedback given should be concise and detached from personal taste.

The timing of the meeting is also just as important as the structure. If the sessions are too long, people will lose focus and if they are too short there might not be enough time to cover everything. As a general rule, I always set aside an hour for design review meetings - five minutes for the intro, 25 minutes for presentation, and 30 minutes for feedback.

Oh, and a great way to make these meetings even better, bring cake! Everybody loves cake! Studies have shown that having cake in a meeting is the cause for 100% attendance. In all seriousness, we do have a rotation order so every meeting someone brings a treat for the group to enjoy (store-bought or baked, we are not picky).

End of the meeting

The day after the session, I send a summary email to all participants summarizing the feedback discussed in the meeting. The pair which presented then examines the feedback and decides if and how they want to implement the feedback. Implementing all or some of the feedback is vital to the continuity of the meetings. If I am continually ignoring the feedback people give, they will be less inclined to give their input in the next session.

Once the feedback is implemented, we gather for another meeting, present the progress, receive more feedback, apply it… And so the loop begins until a beautiful and almost perfect product is built.

Final Notes

Adding the design review sessions to your company structure can make a significant difference in the quality of your projects. However, to make sure they are genuinely productive, keep the following in mind:

• Presenting a ‘work in progress’ as opposed to a finished project allows for more meaningful and helpful feedback
• Keep the meeting structure solid and timing within an hour to optimize productivity
• Train participants to give concise feedback before the meeting
• Implement changes based on relevant feedback
• Continue to present the project again, showing progress and evolution, until you reach a finished product