Critique is an important part of any design process, whether you work within a diverse team or independently. The feedback you get through a formal critique can help get you outside your own head in order to make better decisions, overcome obstacles, and strengthen your craft.
Yet, when I first joined Facebook I was worried the weekly, two hour block we had scheduled for critique was time that would be wasted, time we could otherwise spend producing work. The reason for my worry was that critique often fell into two negative patterns at my previous jobs:
The team was too afraid of being brutally criticized to show what they were working on
The team didn't have a clear understanding of the goal for the critique and ended up wasting time debating or ranting endlessly
In my experience at Facebook, critiques have played out a bit differently. The meetings are much more centralized around authentic critique and less about providing criticism or pushing an agenda.
Many of the methods we've incorporated for critiques come primarily from Jared M. Spool's Moving from Critical Review to Critique. What Spool writes about critique has made a tremendous impact on my understanding of what makes a critique worthwhile, particularly at Facebook. As a result, I've come to embrace the notion that dedicating a few hours every week for a meeting can undoubtedly prove itself to be valuable for everyone who attends.
Here's how my team at Facebook does it.
1. Establish clear roles
Everyone in a critique has a role they must play. The three roles we rely on are: presenter, audience, and facilitator.
The presenter is the individual sharing work, their role is to:
- Succinctly describe the problem being solved (or ideas being explored)
- Present design or content solutions they have come up with
The presenter's job is not to present a slideshow of ideas, or to sell the team on their work. Presenters are each given a 15–30 minute block of time they can establish a day in advance with the critique facilitator (more on that role in a second).
The audience is anyone not presenting in any given block of time. Their role is to:
- Understand the problem statement and context
- Ask a lot of questions
The most powerful toolset for the audience are the questions they ask, either to uncover relevant thoughts or help guide decisions.
Getting the right questions out is vastly more effective than trying to find the right answer to a particular, pre-established question. Questioning the original problem scope, for example, can help the presenter (and team) prioritize, while questioning more minute decisions can align the team's visual language and propel innovative design decisions forward for the whole team.
The facilitator's job is to:
- Create a schedule for each critique in advance (who will be presenting what, and at precisely what time?)
- Ensure that everyone in the group stays on the agenda
- Take notes during critique to help those presenting
- Ask the presenter: “What are the next key steps you'll take to move the work forward?” and document the response
The most important aspect of a facilitator's role is to keep everyone within their confined roles for each presentation. That means the audience is there primarily to ask questions, while the presenter is there to clearly outline their problem or challenge while presenting solution work.
On my team, we often have an established facilitator that manages the critique each week. If you don't have someone to fill the facilitator position (like a product manager or program manager), anyone attending can take on the role of facilitator. Feel free to rotate who acts as a facilitator at each meeting as well.
2. Ensure everyone understands (and agrees on) the problem
It's immensely helpful to reiterate the problem being solved before showing any work in a critique.
Vocalizing the problem and context for the work—and why it's a problem or idea worth tackling in the first place—helps establish a foundation from which productive feedback can be given. The problem statement format could simply be:
- I am showing [early/mid/late] work
- Around [the problem]
- Because [why it's a problem]
- And am looking for feedback around [specific focus for feedback]
The presenter should explicitly state what he or she is not focused on exploring during the critique just as much as what he or she is focused in getting feedback on. For example: “I'm not looking at resolving the detailed aesthetic of the project just yet, but I am looking for feedback on how I should create a more cohesive experience through animated transitions.”
Once the problem statement is made, it's important to ensure everyone understands it. The presenter or facilitator should ask the critique group questions for clarity:
“Does this sound like a valid problem, is the problem statement confusing, is there anything that may have been overlooked? Do we agree that this is the problem that we should be solving?”
Once everyone agrees on the problem statement, it's time to share the design solutions or explorations.
3. Focus on feedback, not criticism
It's important to know the difference between helpful feedback and unhelpful criticism.
In addition to Jared Spool's work on what makes a critique valuable, my design team has gained a lot of insight on critique from writer and teacher Judy Reeves, who shares valuable insights in her book Writing Alone, Writing Together; A Guide for Writers and Writing Groups. Designer Greg Lindley often paraphrases a prominent point from the book for our team:
“Posing thoughts as questions allows the designer to express their reasoning instead of being defensive. If they hadn't considered a particular angle, they can make a note and address it in the next iteration.”
In addition to focusing feedback in the form of questions, we also encourage the critique group to open any feedback with something positive that they liked about the design solution. “I liked how you addressed this part of the design, how do you plan to scale this other part?” for example.
To really ensure feedback is kept helpful —truly in the form of critique and not criticism — Reeves gives us an outline for developing a clear distinction between the two:
- Criticism passes judgement — Critique poses questions
- Criticism finds fault — Critique uncovers opportunity
- Criticism is personal — Critique is objective
- Criticism is vague — Critique is concrete
- Criticism tears down — Critique builds up
- Criticism is ego-centric — Critique is altruistic
- Criticism is adversarial — Critique is cooperative
- Criticism belittles the designer — Critique improves the design
If the goal of critique is to help move solutions forward and empower the team, feedback should primarily be presented in the form of exploratory and guiding questions, with an intent of building up and improving the work, and with the mindset of working together as opposed to criticizing the presenter.
Critique should not serve the purpose of boosting the ego or agenda of anyone in the meeting.
There's just one additional rule for our critiques here at Facebook that is worth mentioning…
4. Laptops (and phones) stay closed
The point of a critique is to explore problems, nurture ideas, and grow the team, primarily through listening and asking questions. You can't accomplish this goal if you're constantly checking your phone or working on your computer (or checking Facebook).
There are only two exceptions to this rule: the first is that the facilitator, who should be actively taking notes for the group, can have their laptop open in order to do so. The second exception goes to the person presenting (of course, how else are they going to share their work?)
Everyone else should have their phones away and laptops closed.
Criticism passes judgement, critique poses questions.
To sum up, here are seven questions to ask yourself and your team about your critique sessions. The answers will help you identify opportunities for making critique more valuable and effective:
- Is there a set agenda for work being shown?
- Are there clearly defined roles in each session?
- Has the facilitator done a good job of keeping the conversation focused?
- Have presenters accurately shared the scope of their problem?
- Did everyone in the room understand the problem framework, enough where each person felt equipped to ask questions?
- Was feedback provided in the form of questions or criticism?
- Did the critique feel like a cooperated effort to improve either a design, problem outline, or individual process?
Critique is a team effort, not a one person show. Critique truly becomes valuable when we come together with the intent of understanding, identifying opportunity, exploring, and building up those we work with.
