Critiquing Design - Handbook
The thing about most critique advice is that it lives as just that — a bunch of advice that you should try to remember and somehow work into the conversation the next time you’re knee-deep in a critique session.
I’ve been working with my colleagues on the Firefox UX team on an approach, adapted from a process created by choreographer Liz Lerman, that completely upends traditional design feedback. It works by embedding all the things we strive for in a critique into a deceptively simple, step-by-step process. It puts the designer in control of their own feedback and it gives us a way to talk to each other about our work that’s respectful and inclusive. This process will leave you inspired by the smart, creative people you work with.
The basic process works like this:
- The facilitator goes over the process/explains how it works/reminds everyone of the steps.
- The presenter then sets the stage—providing the relevant context that the audience needs to appreciate the work before presenting it. After the presentation the audience spends a few minutes on their own with the design or idea.
- Then the facilitator guides the audience and presenter through the five step critique process:
- Step 1 Clarifying questions: Audience members can ask the presenter for more context or for more details about how something works.
- Step 2 What's working: Audience members talk about the parts of the design or solution that work well.
- Step 3 Presenter asks questions: The presenter asks the questions they came to critique to get answered.
- Step 4 Audience can ask neutral questions: The audience now gets to ask neutral questions, i.e., questions that don't have opinions couched in them.
- Step 5 Opinions: With the presenter's permission, audience members can express opinions about the design.
The facilitator is responsible for setting the tone, assuring that everyone understands the guidelines and guiding the process. Depending on the group and the situation, they may be very hands-off or may play more active roles like coach or referee.
The presenter is the person (or people) who developed the work or solution being shown and will be using the feedback in future iterations.
Typically the audience are the presenter's design peers but the process actually allows for a wide range of stakeholders. The audience can be comprised of people with roles from engineers to executives.
Presenting the work
It helps to have the facilitator explain the purpose, rules and steps of the process. This can be brief for an experienced group that does this often or more of a mini-demonstration for a group that is completely new. It’s also important to stress that the overall purpose is to help the presenter make their best work. It’s not to make the work for them or to explain how you wish they’d make the work.
Because what’s being presented is a work in progress and often not an actual piece of software, some context for the Audience is needed. Some things the presenter might want to address:
- What are the user problems/needs/goals that you are working on?
- What are the business goals?
- What are your constraints - time, scope, engineering?
- What are the ethical or social implications of this work?
- What design values do you consider most important here?
- At what stage is this work - Are you in a diverging or converging stage? Is this a series of early, low-fi explorations? A clickable prototype for testing? A near final spec?
It’s usually best for the presenter to share their screen as they demonstrate or explain the work. It’s also good to provide a way for each member of the audience to experience the work for themselves. This could be an image, Google doc, clickable prototype, installable extension, etc.
If possible, the facilitator should give everyone a few moments (or minutes) to experience the work on their own and jot down any notes or questions they may have before starting the actual feedback section.
Step 1: Clarifying Questions
The facilitator asks if anyone has factual questions about how the presented work operates. The goal here is just to understand the presentation, not to begin the critique.
Step 2: What's Working
Audience members talk about the parts of the design or solution that work well. If possible, it’s helpful to include the reason why and to steer clear of personal opinions (that’s step 5) by connecting it to a user problem, business goal or design value.
If they occur to you later, you can continue to mention things that work after we’ve left this step.
Critique sessions can have a tendency to focus on things that need work and are not always good about talking about the pieces that are actually working well. We don’t want the presenter to change things that are working well in the next iteration simply because they weren’t called out as such in critique. Also, this is an important part of creating an environment where someone can produce their best work.
Step 3: Presenter Asks Questions
The presenter asks the questions they have about the work. Generally these questions should be the ones that brought you to the critique process and will probably depend on the stage the work is in. In general, avoid leading questions and approach the extremes of the general-to-specific spectrum with caution. “What do you think?” can quickly steer the session into hot takes while “What color should I use here?” can lead to bikeshedding. It might help the presenter to work with someone (like the facilitator) before the critique session to distinguish and refine these questions.
In answering, the audience should stay on topic with the question but may express opinions in direct response to a question by the presenter.
Step 4: The Audience Asks Neutral Questions
The audience now gets to ask neutral questions, i.e., questions that don't have opinions couched in them.
This step can be one where the facilitator needs to take an active role as forming neutral questions can be difficult for people the first time. It’s often helpful to lead the group in practicing how to form neutral questions. To do this, the facilitator might use a hypothetical work as an example:
- Imagine we just looked at a message that will be presented to a user in response to them canceling an action. And let’s say someone in the Audience asks, “Why did you use such a formal tone in that dialog?” Can you suggest a neutral way to phrase that question? Maybe, “What kind of tone were you aiming for with that message?”
Some other examples:
- Instead of, “Why did you do it this way?” try “What solutions did you explore?”
- Can you say more about ______?
- What things did you eliminate?
- What was the runner up to this idea?
Step 5: Opinions
For a group that has a working relationship and has built trust with each other, hearing opinions are a thing that the presenter has control over. So, for example, the facilitator will ask if people have opinions to share. If someone has an opinion, they should say, “I have an opinion about _____. Would you like to hear it?” The presenter can then choose to hear the opinion or not. This may seem formal but often the formality makes it safe for people to get into a challenging dialog.
Sometimes, given the audience, it might feel inappropriate for the presenter to decline to hear someone's opinion (like the CEO's for example). In a situation like this the presenter and facilitator should decide before the critique session to skip step 5 and then the facilitator will make that clear at the very beginning.
This process is adapted from the one created by Liz Lerman. Steve Bailey and Jump-Start Performance Co. introduced me to it many, many years ago. Sharon Bautista, Tiffanie Shakespeare, and Jen Simmons encouraged and supported me in adapting and bringing this to our work at Mozilla where the Firefox UX team has embraced and shaped it.