Critique vs Feedback: Knowing the difference Might Just Save Your Life™

When I took over the Open Web Apps Ecosystem UX team at Mozilla, my team had lots of feedback and no critique. It lead to a lot of conversations with designers who felt like they were trying to serve too many masters. Feedback is often contradictory and they were awash in it mostly alone. After a few of these kinds of conversations with my team I made a very conscious decision early on to turn one of our two weekly feedback meetings into a closed door critique session.

As designers working in technology we seem to have a hard time knowing the difference between Feedback and Critique. I have no hard evidence for why this is, but I suspect it's because so many people came into this work from all over the place, and the curriculum at All Over The Place University is not very structured. I've watched my own students have the "a ha" moment when we go over the difference in class. I also watched my design team at Mozilla start to benefit quickly after making this distinction clear among ourselves and our larger, cross-functional product group. They felt more confident about their work and got more out of the remaining feedback session we had on the calendar each week.

I Am Feedback and So Can You

Feedback - noun - Outside thoughts and opinions about something. Usually the feedback providers know something the feedback receivers do not but are not directly involved with the process or object they are giving feedback on.

Tech is now in a period where we are obsessed with feedback, and that's a good thing. Feedback is important because it's a very useful guidepost on the road to making useful things people want. It is such a great guidepost because feedback is external, it's focused on outsiders telling us what they think about what we've done. These outsiders might be customers, users, Bob from marketing, they might even be the whole company dog-fooding what you're making. These are the obvious outsiders, people outside the direct process of making the thing you're making. There is another group of outsiders though, a group that we largely ignore when we're talking about feedback, the people involved in making the thing but outside the design process.

Understanding that feedback comes from outsiders is important. It helps us remember solutions do not come fully-formed from feedback. We can't simply "do what the feedback says" and be successful, in most cases. Forgetting this is what causes the confusion and feelings of being pulled in too many directions my team was experiencing. Critique helped us remove both feelings from the process.

Critique: More than just a bunch of people being mean

Critique - noun - a working session among peers who share a specialty to explore ideas, discover blind-spots, and improve a piece of work.

The first thing you have to understand about critique is that when it's done well no one is being mean. Critique is the most potent act of love I can think of (that is HR friendly) between coworkers. It's an attempt to make the work better by combining your expertise. Critique is about the work, period.

The second thing you need to understand about critique is that it isn't a firing squad the same way feedback sessions often are, it's a conversation.

What I mean by that is:

In feedback sessions you are often acknowledging feedback and thanking the giver for their input without really challenging any of it (or at least you should be.) You direct the feedback giver to tell you about the things you really have questions on. You stand there and take it, use what you can use and leave the rest in your notes.

In critique you are working with others who do the same work you do to collaboratively make the work-piece better. It's a back and forth, a debate among practitioners. You will disagree and you will have to back up your positions. You aren't dealing in thoughts and feelings about the work, you are dealing in concrete changes to it.

Earlier I said I cut a meeting out of my Mozilla team's week. I did. Critique isn't a meeting, critique is a work session. This is why it's so critical that critique happen between the members of the team doing the design work because a critique isn't just about hearing what someone thinks, it's about working with them to change the piece for the better.

To outsiders, most critiques look like the designers arguing (respectfully) with each other, because in a lot of cases that's what it is. The design needs these arguments to get better but outsiders usually don't know that, because why would they??! I witnessed very early on at Mozilla the end result of having anyone outside the design team attend a critique session: they become afraid to give you feedback later.

Critique vs Feedback: Side by Side

The same kind of concern raised in feedback and critique:

Feedback:

Stakeholder: I'm afraid that organizing information on this page this way will be confusing to our customers. We always hear our customers talk about this information in a very particular way."

Designer: Interesting. We'll definitely look into that. If you have any examples you could provide us of the particular way customers talk about this information that would help us out a lot…

Critique:

Designer A: I think the way this page's information is organized is confusing. We saw in the research that people actually think about this a certain way. We've also seen on other projects that when we organize the information around the way we think of it our users complain they can't find things. What if we build the page around that user mental model, moving some of these things off the page, adding these things to it over here…

Designer B: In testing people had a harder time finding the things we're trying to emphasize when we had these things off the page. What do you think if we just moved them down a bit, de-emphasize them? I think that might solve both problems?…

Critique is the simplest workshop you can set up, here's what you need:

• Ground rules that everyone knows and agrees on (suggestions include: it's about the work!, every decision has to have an explanation, one suggestion at a time)
• A schedule to make sure everyone is sharing work regularly
• A room with a door.
• Bonus points for: candy, snacks, or something that makes the whole thing feel more relaxed.

"Isn't everyone part of the design process?" or "A preemptive explanation to the accusations that this is all very 'waterfally' and won't work in Lean Agile 10x Super Ninja teams."

I genuinely believe product managers and developers should be considered part of the design team. Their work has a huge impact on the design of what eventually gets build and they should be participating in the design process to figure out what we should make. They should be designing alongside us, not just acting as our client and our build team.

HOWEVER, very few software development teams are structured that way and until they are we have to be pragmatic about our processes. Most tech companies have Product Managers giving problems to Designers to be solved, and then those solutions go to Engineers to be built. I can hear you all screaming, "That's sooooo waterfall!" but even in the leanest and most agile teams I've worked on the process tends to return to this linear production model with compressed timelines. This is the reality of the production work designers and developers have to do that can't easily be shared. What I'm describing here is the 90% case, but critique can be done with anyone, as long as they are thinking about the process the same way.

With this attempt to address the internet shouters finished, let's wrap up.

The real value of critique

Critique is a kind of stress testing, and it's the main way designs and designers improve. Critique is key to the growth of designers and to the delivery of good design. What I saw on my team at Mozilla, and what I see regularly in my students, is the same thing I feel whenever I get to have my work critiqued. Insecurity and uncertainty about the work disappears when you see how strong, or weak, your explanation of it is. The rush of seeing how other designers think and hearing how they got to those thoughts is indescribable, it's the rush of learning how to do your job better. The work always walks away better than it entered, even if it's torn to shreds, because you have a new direction to take it in.

Real critique, combined with feedback, will certainly make your designs better. It's the iterative part of the design process that so often goes missing in an attempt to "get it out and test it with users." It makes those tests more valuable because you know you're testing something solid. It also makes us better as designers, giving us a chance to learn from each other and get better at our craft. Best of all, critique isn't hard to set up in your team. I saw vast improvements in the work of my team when we started critiquing it as a group. More importantly I saw my designers being more confident when they were standing in that Feedback Firing Line, confident that they had explored the solution in enough depth to be asking better questions of the feedback givers.

A huge thank you to Ibai and Silvia for reading the early draft of this piece.

Update: After hearing some very helpful feedback and getting a great suggestion from @birdsong I've added in the "Feedback vs Critique" section to give an example.