Design Review versus Design Critique: Take Control!

I don’t know about you, but I hate design reviews. I finish up a bit of work and then I have to present it to the project team. “Wouldn’t that be better if you moved that down there?” “I don’t like that.”  "It should be just like _______." (Several of us call this JLO or "jello".) And of course we have the occasional business owner who thinks they’re a designer. I have grown a very thick skin.

Add on top of it that in Agile, you have very, very little time to get design done. There is no backlog of completed design work. We’re lucky if we have a couple days to get requirements and design before dev is ready to work. So any rework is a major issue. As the sole designer I’m holding up the team or worse the developers will start without me.

So getting design right without rework is a major issue. But then once you’re pretty sure about your work, the last thing you want is someone to walk into a design review and blow up your work so that you have to completely start over. And design reviews, they’re a free for all. If you have eyes, then you’re supposed to be able to make any comments to the designer.

It’s stopping that free for all that I want to get to. And Adam Connor at Mad*Pow is my hero on this. I attended his workshop at ConveyUX in 2015 on design critiques and it has completely changed how I handle a design review. First, I know longer call it a design review—a subtle hint that the free-for-all doesn’t happen at this meeting. It’s a design critique. And his techniques keep me in charge of the design.

So how do you control the meeting? While you may never have thought about it, at a design review you get 3 kinds of feedback: gut reaction, solutionizing and the critique that you really want. To get there you have to lay out ground rules up front before you present your design. I have a set of guidelines that I send out, especially if we’re looking at a new page, the day before if a morning meeting or the day of if an afternoon meeting. I always send a copy to new team members.

In a nutshell you want a set of guidelines that are easy to follow and makes sure everyone is treated fairly within the meeting. But most importantly you want to explain that you want people to critique your work. That means not expressing their immediate emotional reaction to your work, but taking time to understand and express the reason for their immediate reaction. It also means that if they are jumping to solutionizing, they need to take a step back to identify the problem for which they’re proposing problems.

Once your team understands the guidelines, then you need to give them a basis to critique your work. What are they comparing it to? What goal is it supposed to meet? Make sure to outline the scenario or task your work is supposed to support and make any reminders about who your users are and/or goals that your work is trying to meet. For example, perhaps your user needs to complete the task within the page within a given time frame. (Remember we’re talking enterprise design and not consumer design here.) This helps frame the discussion.

Adam recommends that you don’t do any big reveals in this meeting and to send out your design beforehand so people have a chance to look at it. But in other cases I’ve heard you shouldn’t send your work out beforehand so no conversations happen outside your meeting. In my situation I’ve found that people usually have no time to review anything before a meeting and most have been watching design develop on my mock-up/prototype. I also want to be able to explain how and why the design is what it is: what are the red lines through the design, what psychological/physiological design principles am I using, what standard design patterns am I using. In the environment in which I work UX has struggled for years to educate and establish credibility. And when you seem to have it down, political changes reorganize the players and you have to start all over.

Now here is the important thing. You have to prepare yourself for this meeting. When you show your work, you need to follow the same rules as everyone else. That’s where the thick skin comes in. You want your team to leave out the gut reaction and solutionizing, but you need to do the same for their critiques.

I really recommend that you ready Adam’s (and Aaron Irizarry’s) book, Discussing Design for the nuts and bolts of turning your design reviews into design critiques.