October 27th, 2011
We’re really good at criticizing things. We can spot the flaws instantly.
But that’s different than a critical exploration of what we’re trying to do. Where we learn what it takes to make a great design. Where we explore both the problem space and the possible design solutions.
I ask teams whether they do critiques. “Oh, yes. All the time,” they tell me.
However, when I ask them what it is they do, it’s basically a meeting where someone’s work is criticized for what it’s missing. It’s a meeting where people who haven’t given the design problem or solution much thought, until that moment, rip apart the work of someone who has.
These critical design reviews are miserable experiences. Everyone completely dreads them. The experience makes them feel like crap. And then it’s time to schedule another one.
I’ve been working with teams to change that. We’ve taken the traditional studio critique process and brought it into the modern world.
What makes a critique different from a critical design review is we are not there to find flaws. We’re there to learn from the design and to explore where it works well and where it could be improved.
In a well-run critique, we explicitly separate out the discussion of “What are we trying to do with this design?” from the discussion of “Does this rendition accomplish it?” By separating out these two pieces, we avoid digging into the designer’s work just because they unaware of a critical requirement or need.
The critique technique we use has a structure. First, we start each session with a brief introduction to the technique, for all those folks who are participating for the first time.
Then the designer describes what they were trying to accomplish with their design. What was the problem? What were the priorities they took under consideration? What did they bring from what they learned in previous critiques?
If everyone in the room agrees, we can move on. However, if someone thinks we’re solving the wrong problem or that we didn’t take the right priorities into account, now’s the time to speak up and discuss it. (Ideally, we would’ve discussed these things before the designer put the hard work into the design iteration.)
Then the designer shows us what they’ve done. They specifically talk to what the design is trying to do, telling us what they were thinking and how they solved the important problems. The goal is to not only show us the final design product, but to give us the thinking behind it, opening up their rationale.
After the designer has shown everyone what they did and why they did it, everyone starts with what they liked. After all, there’s something to like in any designer’s work.
Pointing out the likes isn’t just an exercise to be nice and respectful. It helps everyone understand the qualities that are desirable. (This is one place where criticism-focused design reviews often fail miserably.)
The audience also now can explore the design. Often this is done, not with critical commentary, but with exploratory questions. “Have you thought about how users will share the photos with their friends?” “Have you considered how the application works when there’s no network connectivity?”
By posing their thoughts as questions, the designer can say whether they’d thought about that issue or not. If they have, it gives them a nice chance to talk about their thinking. If they haven’t, well, they just say, “No, hadn’t thought about that yet.”
Of course, we record all the things that come up — what people liked and what questions they had. At the end of the session, we review them, to make sure we’ve captured everyone’s thoughts.
While we avoid group design in these sessions, we do encourage conversation that helps us explore what we’re trying to do. The designer takes what they heard and integrates it into their next iteration, presenting it at the next critique.
Team using this process tell us they get a ton more out of each session, enjoying the process of learning about their designs. It also doesn’t hurt that the designs they’re producing show a marked improvement.Tweet