What Sixteen Years of Design Critique Taught Me About Feedback

I have sat in somewhere around a thousand design reviews. A few of them changed the product. Most of them cost everyone an hour. The difference was almost never the quality of the work on the screen.

It was the quality of the feedback.

Feedback is a skill and almost nobody is taught it. You get taught how to design. You get taught how to present. Then you get put in a room where six people look at your screen and say whatever comes into their head, and we all agree to call that a process.

Most feedback is a symptom, not a diagnosis

Users rarely complain about the real problem. They complain about symptoms. The same is true of your colleagues.

Someone says the blue is wrong. The blue is almost never wrong. What they mean is that the button does not feel important enough, or the screen feels crowded, or they cannot tell what they are supposed to do next. The blue was just the first thing their eye landed on and the first word their mouth found.

So when you get a note, your job is not to do what was said. Your job is to work out what made them say it. Ask one more question. What were you expecting to happen there? That single question has saved me more redesigns than any amount of research.

The room decides before anyone speaks

Watch faces, not mouths. In the first ten seconds people have already decided how they feel, and everything after that is them constructing a reason for a feeling they already had.

If four people lean back at the same moment, something is wrong with the screen and none of the comments that follow will tell you what. If one person leans in, that is the person to talk to afterwards, alone, because they saw something the group is about to talk them out of.

Giving feedback well

Three things changed how I do this.

Say what you are reacting to before you say what to change. "The eye goes to the illustration first and I think it should go to the price" is useful. "Make the price bigger" is an instruction that skips the reason, and instructions without reasons produce designers who stop thinking.

Separate taste from function. If you would not defend it to a customer, label it as taste and let the designer decide. Half the friction in design reviews comes from personal preference wearing the costume of a requirement.

Say what is working. Not as encouragement. As information. If nobody tells the designer which parts are load bearing, the next revision will quietly break them.

Receiving feedback well

The hardest part is not the criticism. It is the urge to explain.

Every designer knows the feeling. Someone misreads a screen and you immediately want to describe the reasoning that would have made it obvious. And you are usually right. The reasoning is good. But the user will not have you in the room, so the explanation you just gave is proof that the screen failed, not proof that the critic was careless.

I try to hold one rule now. In the review, I collect. After the review, I decide. Arguing inside the meeting converts information into a negotiation, and you always end up with less of it.

The reviews that actually work

The best reviews I have been in had a stated question at the top. Not "thoughts?" but "I am unsure whether people will understand that this saves automatically, look at that." A narrow question gets you a useful answer. An open question gets you the room's hobby horses.

And they had someone whose job was to write down what was decided. Without that, the same note comes back three weeks later from the same person, and the work goes in a circle that everyone can feel and nobody can point at.

Design does not usually fail because someone drew the wrong rectangle. It fails in the conversations around the rectangle. That is where I would spend the effort.