Four people crowd around a 27-inch monitor, peering at a design mockup.
First developer: “Are you nuts? We can’t build all that for the next release.”
Second developer: “Have some vision, man! This is for next year. Uh… right?”
Product manager: “We should use those thin little icons, like on my iPad. Here, look at my iPad. See? Great icons, right?”
Designer: (Shakes with rage and/or sobs.)
Design critiques–the process whereby a team gets together and reviews a design or a product prototype–can be painful. When people aren’t on the same page about goals and context, critiques can take a long time, they can lead to inefficient or unclear outcomes, and, let’s be honest, they can hurt feelings. But they don’t have to be that way. Here are my favorite rules to make them efficient, focused, and worthwhile.
The owner is usually the designer working on the project. After the meeting is over, they will be the one on the hook to solve any problems that get identified. Write their name on the board. Remind everyone “so-and-so is the designer. Not you. Our job today is to help her.”
Don’t expect the meeting to run itself. Pick somebody whose job is to follow these 9 rules and move things along quickly and efficiently. It might be the designer, but it doesn’t have to be. Ideally, it should be someone a little bossy. Write their name on the board, too.
The design owner should–very briefly!–remind everyone of the goals of this project. This should be something like one to five bullet points, and hopefully at least one of the goals is measurable (for example: increase task success by 50%).
Referring to the project goals will help the team make informed judgments, not just gut reactions. And yes, write these goals on the board.
Do you want feedback on the high-level user flow, or on nitty-gritty visual polish? Be specific and you’ll keep the critique focused and useful.
Also–you guessed it–you should write the meeting goals on the board as well. It might sound kind of silly, but writing all this stuff on the board really helps people craft the right kind of feedback. They’ll appreciate the constraints.
Starting your meeting with a long explanation of every screen from the designer is a bad idea for two reasons. First, it’s a poor use of time – designers, myself included, can get long-winded when talking about their work.
Second, it robs everyone in the room of their fresh eyes. Some of the most useful feedback a designer can get is “I don’t understand this” or “I didn’t see that.” If you explain and point out how everything works upfront, you’ve just given everyone a monster spoiler, and you’re much less likely to spot comprehension problems.
After you’ve identified the owner and written down their goals, it’s a good idea to spend a short time (say, five to ten minutes) with everyone silently reviewing the design work and taking down notes. This silent work time lets everyone think about the design a bit more deeply, and experience it by themselves–which happens to be the way you experience design in the real world.
The added benefit is short-circuiting groupthink. When everyone has to commit their opinions to paper before they share they become a lot less likely to all pile on to the same opinion.
Of course, you want to encourage constructive criticism. Finding flaws at the mock-up stage is obviously far more efficient than patting your designer on the back. You don’t want to protect people’s feelings and end up launching a suck bomb product.
But you also want to make note of the good stuff. Most likely, at the end of your meeting the design owner will have a list of problems to address. If you don’t also give them a list of things that are already working well, they might accidentally throw the baby out with the bathwater.
While it’s OK to suggest an alternate approach occasionally, don’t use your design critique to solve big problems. Design work–as with other kinds of critical thinking–is best done by an individual. Identify problems, but leave it up to the owner to figure out the answer.
The facilitator keeps things moving by converting discussion into tasks. Once a problem has been converted into a task (“Frobazz widget doesn’t make sense. Explore alternate designs.”), you shouldn’t keep talking about it. Write the task on the board. Once there are no more new tasks to capture, you should end the meeting.
If you keep your design critique on these rails, you’ll typically get through it a lot faster, and everyone–the designer included–will feel a lot better about the outcome. Treating critiques seriously means you’re taking design seriously. That’s good for your team and good for your product.
Interested in reading more on this topic? Scott Berkun wrote a great post on design critiques 10 years ago that’s still super useful today. Do you have design critique rules that work well for your team? I’d love to hear them!