Learning the Art of Critique

Thus begins Discussing Design, the new book from O’Reilly Media that shows us all how to provide feedback in a constructive way. In the book, Connor and Irizarry review three types of feedback, and why we struggle with it as designers.

“The issue with feedback lies in how nonspecific it is. Feedback itself is nothing more than a reaction or response,” they explain. Reaction-based feedback is just that—an immediate reaction without context. Direction-based feedback jumps too quickly to problem solving. But critique compares a design to the objectives it was attempting to accomplish.

We’ve had the opportunity to discuss design, critique, and collaboration with the two authors.

Why do you think people have such a difficult time critiquing design specifically? Is it a problem in design more so than other fields?

Aaron: Receiving feedback on something you have said, done, poured yourself into can be intimidating; no one likes to be criticized. Critiquing and getting feedback is definitely something that happens outside of design, but I think it is more visible to those who work in design since it is such a crucial part of the process.

Adam: Right. And actually, lots of fields design things. They might not go through as formal a process or call it design, but people are constantly identifying problems, identifying objectives for addressing them, and then creating some form of “solution.”

The challenges people have when critiquing often comes back to two things:

1. We often have difficulty clarifying and articulating exactly what our objectives are. It can be so hard that very often individuals and teams don’t do it, defaulting to more of an “I’ll know it when I see it” behavior. It’s also difficult because it can be scary. The act of defining what your solution is might mean you don’t achieve it, or that you might miss something and leave out an objective that proves very important later.
2. Second is our tendency to jump to solutions. When confronted with something we don’t think is quite right, our brains often begin to identify what we think the solution should be, and we tend to verbalize that rather than commenting on what we see. Compound that with some people’s desire to see their ideas pursued over others and you get a recipe for less than useful critique.

In the first chapter you identify 3 types of feedback (reactive, directive, and critique). Are there situations where reactive or directive feedback are valuable?

Adam: Yes, and no. Reactive feedback can tell you the effect the design is having on the viewer, but they don’t tell you much about what you to do with that information. None of us want users (or even our team members) to gag when seeing our new product/app/website/whatever for the first time. But what does that gag tell us? We need to focus our conversation on understanding its cause and how pertinent that cause is to the design reaching its objectives. This goes for situations when the people seeing our design cheer and applaud as well (don’t you love it when that happens?). Cheers don’t tell us much about how or why our design is meeting our objectives; we need to go deeper. Yes, we want people to be excited about what we design, but that excitement needs to come from the value our designs bring when people actually use them.

Directive feedback is a bit trickier. Some directive feedback is just that, direction, “Change X to Y.” Some will tell you a little more about why the change is being suggested. As such, there can be two kinds of issues with directive feedback. The first is just like reactive feedback, it doesn’t tell us anything about how our design is (or isn’t) meeting its objective. Why is it that Y would be better than X?

The second is that, even if the critic does supply a rationale, directive feedback jumps to problem solving a bit too soon in some cases. There may be numerous ways of improving “X,” so shouldn’t we take some time to think of a few possibilities before settling on one?

Reactive and directive feedback are bound to happen though; we do it instinctively. The value they bring to a feedback discussion lies in their ability to help the facilitator or recipient know where they might want to focus their conversation.

Aaron: Exactly. While reactive and directive feedback aren’t ideal, if we remain objective when looking at the feedback then we have a chance to derive some value from it, even if it is presented in the wrong way.

There are so many ways to begin a critique (asking questions, asking for more information, reviewing the goals, etc); how does the personality of the designer impact the best way to critique their work?

Aaron: Taking the personality of the designer into consideration is really important. If you know how they tend to communicate or react then you can try to approach how you communicate with them in a way that lends to their being more receptive. The same way we try to understand the people we design for, we should try to better understand the people we communicate with.

Adam: In Discussing Design we talk about some specific extra measures you might take if you know the recipient of the critique is particularly sensitive to feedback, but really, no matter who the recipient is, you want to make sure you understand what it is your analyzing (the design) and what you’re analyzing against (objectives). Reviewing goals, asking questions, all of these are ways of doing just that.

Where the recipient’s personality comes into play is largely in the language you chose and your choice of tone. Personality traits or even just moods like timidness, aggression, defensiveness, etc. will all play a role in how you talk to someone. Just like talking with friends and family, it’s not a change in what should be communicated, just how.

That’s true, and it explains why accepting critique can be difficult too. In the book you also speak a bit about the problems that come up when those giving the critique are negative (sometimes because of politics or their own issues). How do you recommend people handle critiques when they see many problems that need to be addressed, without making the designer afraid to ask for future critiques?

Aaron: One way to handle this is to compare the problems in light of the project’s goals. Focus on what the problems mean for the product, rather than worrying about who created these problems. By focusing on the product and not the individual, things become less personal and the designer can feel more comfortable receiving feedback.

Adam: Another thing to think about is your wording and framing. It’s easy to talk about feedback and critique as identifying what isn’t working and what is. Many of us get that and are ok with it. Some of us aren’t. Some of us equate “not working” to “failure” and that hurts. In these cases it can sometimes be useful to frame things as improvement. There is always the possibility of improving things, so asking questions like “how could we improve this toward our objective of X?” can get people to think more critically about their own work, but in a way that doesn’t tell them their work isn’t good enough. This, of course, can lead to brainstorming and problem solving, which as we point out in the book can be a challenge, but if you’re focused enough and a good facilitator, you can balance the two.

The book discusses the importance of a shared vocabulary, but seems to be geared more towards teams, rather than team-to-client interactions. What are some good techniques to facilitate a shared vocabulary, early in the process, with clients who are unfamiliar with the “design process?”

Adam: Shared vocabularies are built through conversation, immersion, and adoption. The reason critique helps build a shared vocabulary amongst team members is that it exposes how people think about what’s being created. That exposure creates a kind of immersion. It forces people to try to articulate their thoughts, and in doing so they use terms and labels. When those terms are unknown, some people will ask about them, and others will discern meaning as the terms are used repeatedly over time.

The best way to build a shared vocabulary with people who aren’t familiar with a process you use is to bring them into it. As you talk about and explain it to them, they’ll try to use your terms and they’ll use terms you aren’t familiar with, which you may start using in turn.

That speaks also to the importance of collaboration. Encouraging in an agency setting where everyone has to bill their time somewhere, can be hard to sell to an organization. Do you have some talking points that could help encourage non-billable collaboration within an organization?

Aaron: I think this depends on the organization and how much they want to commit to collaboration. Personally I see collaboration as a way to accomplish client work, or otherwise as something that should be billable hours. I wouldn’t encourage non-billable collaboration as an approach to tak, unless of course teams members want to collaborate outside of work.

Making collaborative exercises a part of the design process can definitely help ease concerns about billable hours. This is something can be established early on in setting up a team’s process. Another approach is to include clients in collaborative activities. This can have numerous benefits, but will also make billing for collaborative exercises a more easily accepted approach.

Adam: There’s also the potential to bring in people from outside the project from time to time to get their thoughts on things, and maybe have them participate in a critique or help in an ideation session. I think that’s very, valuable and we do it all the time at Mad*Pow. We estimate projects based on the types of activities we know we’re going to engage in and the relative amount of hours we think (using past experiences) we’ll need to do them. While the bulk of those hours will all be used by the project team, it’s really just a pool of hours that can be used and billed to by anyone. So if we bring in someone to sit in on a critique, they bill that hour to the project. It also helps that most of us have a pretty open working relationship with one another. For the most part we expect to be asked to help out on others projects when it makes sense.

Thank you so much for speaking with us today. Before we go, what first step would you suggest to individuals hoping to improve their team’s feedback and critique processes?

Aaron: Dive in! Just like anything else you get better with practice, figure out the approach you want to take and start small. Include a couple of colleagues that you feel comfortable with and have the same goals and get comfortable with taking about design and giving and receiving feedback.

Critique is a continuous, living process, the more you work on improving the conversations you are having surrounding design, the more you will learn and improve.

Thanks again to Adam Connor and Aaron Irizarry for sharing their thoughts with us. To learn more about improving design feedback, buy their book Discussing Design from O’Reilly Media, or Tweet your biggest feedback pet peeve to UX Booth, with #discussingdesign!