My Design Review Manifesto
A design review is a fundamental part of any designer or developers daily work life. You work on something, you get it reviewed, you make some changes, repeat, repeat, repeat. There are times that you probably spend more time in some sort of review than you do actually building things.
So, when was the last time you and your team worked on this review process to make it better? Think about how much time we spend reading tutorials, watching conference talks, experimenting and learning with our toolset — and compare that to how much time we spend hacking our design review process to make it better.
This process is critical to getting the best thing out the door, it’s how we make the best products, so we need to focus on it just like we would any tool we used throughout the day.
Note: I’m bad at receiving critique. I struggle with receiving it gracefully. That’s why I focus on it. These are some rules and guides I use to make it easier.
In other words, be constantly reviewing everything. This is how we write code, and we should apply it to how we design things. Smaller changes are easier to digest for stakeholders, there’s less risk in the changes, less to decipher and consider. It means there are always tiny bits of movement forward on a project and it’s not going to stall out under the weight of big changes.
It’s easier to be wrong if the changes are smaller. If I work tirelessly on something for a week and show it to stakeholders and they hate it, I become defensive because I’m so invested. Not because I’m right or my logic is sound, but just because of the time investment. That’s not a valid reason to be defensive. Whereas if the stakeholders have seen the process come along and were able to voice their opinions early on then we wouldn’t have made it to this point and we would be in a better place.
Now don’t worry, this does not mean you need to design things with someone sitting at your side, telling you to move an object from the right side of the screen to the left. Let us also admit though that there are some walls we put up to guard our work while we work on it. Maybe you don’t trust your boss to understand what the final product will look like based on the mockups you have now, or it’s just scary to get a team’s feedback before something can be nicely placed into a presentation. Let’s worry less about getting a perfectly finished project to review and trust that our reviewers can work with you to understand where this is headed. If you don’t trust them to look at things the same way as you then you need to work with them to enable them and yourself to look at a project similarly.
Make it easy
You don’t have to put together a slide deck with charts and pretty graphics for every review. Pull up a chair next to someone and ask them to look at your work. Grab a couple people and a conference room for ten minutes. This is how you ship constantly, by making getting feedback easy, but also making it easy for those stakeholders to give their feedback.
Be Better at Critique
A few years ago I attended a talk which changed my whole perspective on critique as a designer. Here’s a similar talk from the same guys: “Discussing Design Without Losing Your Mind” . I encourage you to read more at their website or watch the video but since seeing that talk and using those lessons, I’ve come up with my own modified sort of list of rules to use when doing design reviews:
- Be open to critique. It is valuable. You do not know everything and did not think of everything when you worked on this design. If you’re not open to this and know it is a valuable process it’s not going to be a good time.
- Ask why? When a stakeholder dislikes something there could be a number of reasons for the real reason they dislike it — dig into that, don’t assume you know the answer. “I don’t like the red background” could be because the text is hard to read — or just that it’s a competitors color, but there’s a big difference in the changes you will make based off the reasoning.
- Encourage problems to be stated rather than fixes. This ties in with Ask why? but it’s a good rule to lay down before starting a review. You need to understand the underlying problem with something, otherwise you’re going to continue to repeat the same mistake. It’s much more helpful to hear “that callout box should be the primary action on the page but it’s not the first thing I read” rather than “make that callout box yellow”. So if you encourage problem statements as opposed to solutions you’re getting to the “Why?” even faster.
- ___ Don’t give a critique without being asked.___ If you do it’s likely to be received defensively. There should be a time and place for critique where you are asked to give feedback. This one is hard to enact on a team but I think it’s vital, if someone walks by my office and starts giving feedback I politely ask them to wait until I’m at a good point. The only way to make it work is to allow critique often as a designer, and then the stakeholders won’t feel the need to get involved when you don’t need them.
- Find what ways work for your team. There’s a number of ways to do critiquing (many discussed in the discussing design link above) and it’s good to vary things up. Should there be a short presentation before to initiate the review? should you just jump in with questions? should everyone be forced to use the product for the first time right there — it all depends on the product and your team, but try new ways if you’re stuck in a negative, unproductive design review process.
- Point to business goals to lead the way. When you define the goals for a project before hand everyone in the critique should be on the same page with them, and you point to them to lead the way. This way what you “like” is less important than what achieves a goal.
- Critique your own design without bias. This might be the hardest one but when you present something to be critiqued try to disconnect yourself from that time commitment you’ve made to the project, that work you’ve put in, this is your chance to take a breath, take a step back and look at how this will be received. This helps you take the critique better as well, you’re not going to be as defensive or have your feelings hurt.
- Be good at meetings. I personally believe, that while we all hate meetings, having the 3–6 stakeholders that have to be there in the room at the same time is the fastest way to get a project review done. So conduct them well. Set a goal. Set a timelimit. Do not break from them. Shipping constantly means 10 minute meetings daily not 2 hour meetings weekly. The discussing design guys say it in their talk that critique is hard but it is a lifelong skill, it’s not only a design skill, so spend a little bit of time to think about the process to make it better for you and your team.
Stop. Sending. Emails.
This is a personal rule I’ve recently come around to, but design review via email is inefficient and ineffective. We all do it, we send a mockup to our team with a sentence or two about the week of work you spent on it , and then get frustrated when not everyone understands your intentions. Email inhibits all the things about critique we talked about before, it doesn’t make it impossible, just harder.
Stakeholders can’t easily ask you what you were thinking when you did this You can’t ask them why they think a certain way about something You are not able to build off each other’s ideas. Instead you’ll probably get a bunch of replies with the same comment repeated over and over again etc… etc… It’s also a giant waste of time. Every email you send requires more time to read and respond to than just talking out the problem face-to-face, via skype, whatever method you use to communicate with someone.
Examine Your Process
Here is the whole point of this reading. Look at the design review process. Does it work for you? Does it work for your team? It’s a vital part of how your team works together and feels about eachother so if it’s not an easy process the results aren’t going to be what you want and it’s going to be painful to get there.
Tyler Lee is a UI Designer / Frontend Developer for OrgSync that tries to do his darndest to make OrgSync more intuitive and easier to use.Follow me on Twitter
comments powered by Disqus