Reviewing Design Work

Over the last few years I’ve been thinking a lot about reviewing design work. Here’s why:

• During a round of 360s with my team, we picked up an undercurrent of “Hey, glad you can tell us how to improve—could you also tell us what we’re doing well?”
• On Twitter, I saw a lot of what Scott Berkun calls “drive-by redesigning” in this tweet. I probably did quite a bit of it myself.
• My team talked about how sometimes they left reviews feeling stink, rather than empowered. We ran a workshop about why that was and a number of great things came out of it.

“Constructive Criticism”

I’m a 1 on the Enneagram. Half of you rolled your eyes, that’s OK. I’m not saying you should get into the Enneagram, but I resonate strongly with Type 1 and if you want to understand me, I’m going to point you there.

Ones are conscientious and ethical, with a strong sense of right and wrong. They are teachers, crusaders, and advocates for change: always striving to improve things, but afraid of making a mistake. Well-organized, orderly, and fastidious, they try to maintain high standards, but can slip into being critical and perfectionistic. They typically have problems with resentment and impatience.

You can see where my team was coming from. My criticism, while trying to “improve”, wasn’t actually constructive. It didn’t add or build—because it didn’t empower. I don’t naturally praise because I’m obsessed with improving and reaching perfection. If something is “right”, that’s how it’s supposed to be. That’s how I am wired, and “praise” doesn’t help improve anything. Or at least so I thought.

I realised that there are some benefits to pointing out what people had done well:

1. They feel empowered. They get some positive energy.
2. The team gets to see examples of what good looks like. They get to strive for that energy.

Praising someone’s work doesn’t need to end with “Good job.” You can say “I think you did really well here because…” and then reinforce the lessons you want the team to pick up.

Stop the drive-by’s

Why do we do this? Well, at the heart of it—drive by’s assume you have all the context the original designer has and more! Why more? Because you see a fatal flaw in their work. Clearly they just don’t get it—they need your help.

To some extent this is true. You have noticed something they didn’t. They have a blind spot for a problem (or a “mountain”) that needs to be considered. And you spot it! However, you probably also have a blind spot—and you don’t know about it. Of course you don’t!

This is how reviews normally go: someone shows you A and you want to go to B.

How does this play out? When presented with “A” you might say: “Great work, but why didn’t you do B?”

Now you are having a conversation about Solution A versus Solution B.

The original designer has very little room to move, their options are: get defensive or drop their position and assume yours.

And oh how we’ve been taught not to get defensive. What an impossible situation we’ve just placed our peer in. Be defensive, or admit defeat and accept Solution B.

The sad thing is: you both see different problems that need to be overcome. That’s why they went to A and you went to B. Two different perspectives that combined could bring a clearer picture for everyone. And yet, what do we end up doing?

Then we end up with a poor compromise in the name of “collaboration”.

We compromise! Assuming that we’re being super collaborative we might want to pick some nice things from A, and some other things from B. Nobody is really happy, but we’ve just collaborated—yay!—and that’s important!

Unfortunately, it’s entirely possible that the problem A solved for, and the problem B solved for has been left unsolved. Or, let’s be really charitable—somehow we picked the right parts and they are solved. But we’re not all aware why these bits are important. The next review, the next trade-off can see us undoing that happy coincidence.

How then do we review? How do we combine our perspectives and get a clearer picture of the landscape, before we design?

It’s not easy. But you have two options:

1. Ask yourself why did you go to B. What problem are you solving for? Can you put that in words? Can you ask the original designer if they’d considered that problem? Maybe they have. Maybe they have insight which suggests it’s not really a problem. Maybe they haven’t—maybe you’ve just helped them see a new consideration that they can pursue. They are now empowered!
2. Ask them why did they go to A. What problem do they see? What trade-offs are they making? Can you understand what your blind-spot might be. Can you improve your understanding of the context?

When, instead, we could combine our diverse perspectives and empower the original designer to find their way to D.

Ideally, we now have a process that looks like this. Where two perspectives are combined. Both problems are clear and in the open. The entire team understands the full context, and together, rather than a compromise of C, you can end up in a new place, D.

This is what Diversity in our teams promise us. We have diverse perspectives and they are combined to deliver a clearer view of the landscape, allowing us to design a better solution. Not so we can end up compromising.

Remember, the key here is now for those doing the review to solve the original problem (that black dot). That is the original designers’ job. Your job as a reviewer is to help that original designer feel empowered, get a clearer understanding of the landscape and thus feel confident to move forward.

Note: (1) is hard. It’s extremely hard for our brains to not jump to solutions. Our brains are fantastic for the speed at which they can do this. I find that a huge part of my team’s design culture is slowing that entire process down and making it public and open so everyone can be involved. If you find this hard—not jumping to solutions—maybe share your solution. And then be clear that you want the team’s help to get to the problem you are trying to solve for. To find words for it so it can be out in the open. So that you can contribute to the open conversation.

The goal is to empower your designers

We are here to give the original designer the tools and insights that enable them to solve the problem. You and everyone else aren’t here to solve the problem by committee during the review.

We have unique perspectives that we’re here to combine, not overrule.

So try these:

• Ask open questions.
• Share what you think is working and describe what isn’t working.
• Explain why. If it doesn’t work or make sense to you, tell them why.
• “What led you to this outcome?”
• “If the goal is ‘x’, this outcome doesn’t really convey that to me, because…”
• “This means ‘x’ to me, was that the intention?”
• “How would this address ‘x’ issue or goal?”

And avoid these:

• Give a compliment sandwich.
• Push your own agenda or solution.
• Confuse your own preferences with customer needs.
• Use subjective absolutes like, “This looks ugly”
• “No one could figure that out”
• “Have you tried…”
• “What if you did…”
• “I think it needs to be like this instead”

I’d like to acknowledge my whole team at Vend who helped work through these ideas with me. Especially Nicola Horlor and Thomas Le Bas who helped bring these ideas together and spread them throughout Vend.