A better process for design reviews
Short feedback loops are essential to build great products –and to keep growing as designers.
This post tackles how we approach design reviews, how we’ve integrated them with our product sprint flow, and how we implemented Abstract.
When we redesigned our development tracks, we also sought to improve and standardise our design reviews and hammer out a few kinks.
So, let’s start from the beginning:
What is the goal of a design review?
Mainly and plainly, it’s to get feedback on what’s working and what isn’t, and gather ideas on how to improve.
To optimise that feedback, we decided that design reviews needed a fixed set of participants, and fixed time slots. No more ad-hoc meetings with only a few of the necessary participants.
Each design review now includes a UI, and UX Designer, a PM, and our Chief Design. And because the meetings are scheduled, the designers can (and are expected to) prepare themselves properly.
Because we work in two-week sprints, with client demos on Fridays, we scheduled our design reviews accordingly: 2 slots a week, on Tuesday and Thursday, 30 mins each.
We intentionally chose to keep design reviews short: as designers, we can continue to discuss whether we want the divider to be #f6f6f6 or #f4f4f4, but that’s not necessarily the best use of time ;)
With the planning in place, we set out to improve our design reviewing workflow. For the past 6+ months, we’ve been using Abstract, and when Collections were introduced, it became our tool of choice to facilitate design reviews.
PROPER PREPARATION SETS THE TONE
Preparation is key — an unprepared design review is time wasted.
As a designer, it’s important to know exactly what you’re going to present, and be ready to take everyone else through your thought process.
That’s where Abstract comes in. For each review, the designer creates a collection in Abstract with all the screens for that specific design review. In the collection description, (s)he adds:
- A recap of the feedback of the previous design review
- The items that will be reviewed
- The questions (s)he wants to see answered
Writing everything down really helps to present more coherently and efficiently.
GET THE REVIEW STARTED
We start with a quick recap of the previous design review and go over the points to be reviewed this time. This quickly aligns everyone on the basics, before getting down to the meat of the review.
Then, the designer presents their design. The focus is on a few questions: What priorities, assumptions and constraints did they take into account? What have they learned from previous reviews, and what was the feedback from previous reviews?
The next step is to show what has actually been done. What was their thought process, and how have they solved the problems?
The goal is not only to show the final design, but to show the thinking behind it.
As a side note, we feel it’s crucial to stay on topic. A design review isn’t a status meeting or a place to discover new requirements. It’s normal that people drift off topic, but it’s important to address these topics outside of the design review.
Before ending the design review, the designer makes a quick recap:
- What should be reworked and what has to be done?
- Which questions should be answered by the client or other people not in the meeting?
WRAPPING THINGS UP
After each design review, the responsible PM sends a recap in the project Slack channel, with a link to the Abstract collection. We definitely recommend putting a strict naming guideline in place — ours makes it very easy to search for a specific design review.
In Abstract, screens will never be updated, and this is a feature we particularly love. When people return to the collection, they still see the screens that were presented on that exact date. You can switch to the latest version of a specific screen if you like, but a snapshot of the discussed situation is always available.
This also enables us to have an overview, in retrospect, of every design review we’ve ever held on a project.
We can see exactly which screens were presented at that specific time and what the feedback was. Unfortunately, it’s not currently possible to do any kind of sorting or structuring collections. So 🤞 for future updates.
A FEW NOTES ON GOOD FEEDBACK
As we all know (or should know), giving good feedback is an art.
To make sure we teach ourselves to do it well, we have a few guidelines in place for giving, receiving and capturing feedback during design reviews.
So, how do you give good feedback to the designer presenting his work?
Firstly, it’s important not to give feedback immediately, in the moment. First, let the talking designer take you through the full story. Your questions or remarks might be answered later on.
To set the tone, start by mentioning something that’s working well. Then move on to what you feel isn’t. Ask questions first, to clarify and get any assumptions out of the way. Then make sure to link your feedback to the project goals or relevant best practices — it should be about more than just personal taste.
Finally, avoid directive feedback. It’s possible that you had a different view in your head, but don’t give feedback like “make it red and put it at the bottom”. The point of feedback is to let the designer know what the problem is you’re trying to solve.
When the other participants give feedback following this template, it becomes easier for the designer to receive feedback well.
When listening to feedback, it’s important not to go into defence mode. Just listen and let it sink in for a few seconds — then you can discuss further. Immediately becoming defensive makes you look insecure, and doesn’t open the window to positive communication and improvements.
Some more in-depth articles about giving and receiving feedback:
- The art of receiving and giving design feedback — David de Léon
- 8 ways to give better feedback to creatives — Dropbox
- Don’t take design critique as an insult — UX Collective
Finally, it’s crucial to capture feedback correctly. While an individual designer can, of course, take notes or sketches if they like, we use Abstract and Slack to make sure that there’s a final, digital source of truth available.
Like many firms, we used to rely on good old post-it notes. But that way, things can get lost — literally or in translation!
And there you have it: a better way to organise your design reviews!
Obviously, these meetings aren’t the only time a designer should ask for feedback. But they are very useful, structured moments that will help keep your project on track.
If you found this post helpful, click the 👏👏👏 button or share the article, so your friends can benefit from it too!
Want to read more on how we implemented Abstract at our company?
Head over to our blog: “Our experience with Abstract — version control for designers”.
