Getting feedback is an essential component of good design. No matter how smart we are, we are going to get too invested in our solutions, and we need the help of knowledgeable outsiders to nudge us in the right direction. The problem is that feedback sessions can get out of hand quickly, because we’re just not very good at providing (or receiving) feedback. We are prone to seeing the negative parts of someone’s ideas first, so we often jump straight into the teardown. This puts the person who is presenting their designs in defensive mode right away, which usually starts a negative spiral into unhelpful arguments and distrust.

There is, however, a better way. In an interview on criticism and judgment, French philosopher Michel Foucault once laid out the purpose of any good critique. In his view, criticism should be focused not on what doesn’t work, but on how one can build on the ideas of others to make it better:

I can’t help but dream about a kind of criticism that would try not to judge but to bring an oeuvre, a book, a sentence, an idea to life; it would fight fires, watch grass grow, listen to the wind, and catch the sea foam in the breeze and scatter it. It would multiply not judgements but signs of existence; it would summon them, drag them from their sleep. Perhaps it would invent them sometimes — all the better. Criticism that hands down sentences sends me to sleep; I’d like a criticism of scintillating leaps of the imagination. It would not be sovereign or dressed in red. It would bear the lightning of possible storms.

Keeping this purpose in mind, I particularly like the process used by Jared Spool and his team at UIE. The team uses this specifically for design critiques, but it can be applied generically to any kind of feedback session. Here’s how the process works:

• The person presenting their idea/work describes the problem they are trying to solve.
  If everyone agrees on the problem, the team moves on. However, if there isn’t agreement on the problem that is being solved, some discussion is needed to clarify. Hopefully this step isn’t needed, though.
• Next, the presenter communicates their idea or shows their work to the team. The goal is not only to show the finished product, but to explain the thought process behind the idea or deliverable. The presenter should remain focused on how the idea will solve the problem that everyone agreed on.
• The first step in the feedback is for the people in the room to point out what they like about the idea. This isn’t a gimmick to set up the “crap sandwich” method (you know — start and end with something positive, eviscerate in the middle). Instead, this step helps to highlight what direction is desirable as a solution to the problem.
• Critique follows as the next step, not as direct attacks or phrases such as “I don’t like…”, but as questions about the idea. Team members ask if a different solution was considered, what the reason was for a particular choice, etc. This gives the presenter a chance to respond if they’ve thought through the issue already, or else, make a note to address the issue for the next iteration.
• At the end of the meeting, the team reviews the notes — especially what everyone liked, and what questions they had. The presenter then goes away to work on the next iteration of the idea.

Let’s not forget that as designers we are responsible for making sure feedback sessions happen, and that they happen in a respectful and useful way. Scott Berkun has a great set of ground rules about critiques that are worth remembering:

• Take control of the feedback process. Feedback is something that you should make happen, because that’s how it happens on your terms and in a way that improves the product. If you just wait for feedback to happen to you, it’s going to happen in meetings where you’re not prepared, you’ll be on the defensive, and the focus will shift off product to politics.
• Pick your partners. Some people are better at giving feedback than others. Find feedback partners who have the relevant experience you need to make the product better.
• Strive to hear it all, informally and early. Don’t wait until the product is nearly finished before you get feedback. Discuss ideas, concepts, and sketches way before you discuss comps and working code.

If we change our approach to provide critique, not criticism, we’ll be able to build on the best ideas of others, and iterate faster to better products. So remember: design like you’re right; listen like you’re wrong.