Defend the Decision, Not the Drawing

You show your work. Someone says: "Hmm, I don't like the blue."

Your chest tightens. You explain the blue — the reasoning, the contrast ratio, the brand. Someone else joins in on the blue. Ten minutes later three people are debating shades, and the flow you actually needed a decision on never came up at all.

Two failures happened, and only one of them belongs to the person who mentioned blue. The other is yours: you showed work without saying what you needed, and then defended a pixel instead of extracting a fact.

Why it feels like an attack

Design work is unusually exposed. Code is judged by whether it runs; a design is judged by everyone the moment it appears, in a form anyone feels qualified to react to.

Add the IKEA effect from the prototyping article — you value what you built above its objective worth — and criticism lands on something you're already over-attached to. This isn't weakness or vanity. It's the default, and it means separating yourself from your work is a skill to practise, not a temperament you either have or lack.

The practice is mechanical, and it starts with what you say before anyone else speaks.

Frame before you show

Most bad critique is caused by the presenter. If you put a screen on a wall and say "so, thoughts?", you've invited free association and you'll get it.

Say four things instead, in under a minute:

The problem. "People lose their reference number between steps three and four; six of eight kept it in a notepad."
The constraints. "Can't change the backend this quarter. Must work on mobile."
What I want feedback on. "Specifically whether step two is understandable without the email. Not the visuals — those are placeholder."
What's already decided and why. "We're keeping four steps; we tested three and people missed the confirmation."

That last point is what saves the meeting from relitigating settled ground. And the third redirects the reflex to comment on colour.

Receiving: extract the observation

People almost always give you a prescription — "make it blue," "move it to the top," "add a tooltip." A prescription is a solution someone invented for a problem they noticed but didn't state.

Your job is to recover the problem: "what made you say that?" or "what were you looking at when you noticed?"

"Make it blue" often turns out to mean "I couldn't tell it was clickable," which is a real finding with several fixes, none of them necessarily blue. The prescription was noise; the observation underneath was gold.

Three kinds of input, worth sorting as you hear them:

A reaction — "feels heavy." Data about a first impression. Real, unactionable as stated. Dig.
A preference — "I'd have used cards." A different taste, no problem attached. Politely park it.
A reasoned objection — "someone arriving from an email won't have this in context." This is the valuable one, and it's usually the quietest.

Two disciplines while receiving. Don't defend in the moment — write it down, ask questions, decide later, alone, when the adrenaline has left. And don't explain how it works. If a screen needs your narration in a review, it will need it in production, where you won't be standing there.

Giving: analyse against the goal

Adam Connor and Aaron Irizarry's central point in Discussing Design is that critique is not reaction — it's analysis of whether a design achieves its stated objective. Which means you can't critique work whose goal you don't know. Ask first.

A usable shape for every comment:

Point at the element → name what you observe → connect it to the goal.

"The primary button is the smallest thing on the screen — for a person coming here to finish a purchase, that's the one thing that should be findable in a glance."

Three rules that keep a critique session useful:

No solution without a problem. If you want to suggest something, state what's wrong first. Otherwise you're contributing taste.

Be located and specific. "This feels off" is a feeling. "Steps two and three both call this a different name" is a finding.

Separate "this is broken" from "I'd have done it differently." Say which one you're doing. Half the pain of design critique comes from preferences delivered in the voice of defects.

And critique the work, never the person. "This screen doesn't say what happens next" — never "you always forget the empty states."

Who decides

A critique with no named decider turns into a negotiation, and negotiations are won by whoever is most senior or most stubborn.

Before the session, everyone should know who makes the call and who is advising. Feedback and instruction are different things arriving in the same tone of voice, and a designer who can't tell them apart either ignores their manager or obeys an intern.

The other half is recording the outcome. Keep a short decision log: what was decided, why, what was rejected, and what evidence exists. Three months later nobody remembers why the flow has four steps, and without the log you'll relitigate it — or worse, "simplify" it back into the thing you already tested and rejected.

Arguing with the person who outranks you

Sooner or later a senior person will state a preference as a requirement. Some moves that work better than being right loudly:

Bring the user's words. A verbatim quote — "I thought this button would delete my whole file" — outperforms any argument you can construct. A thirty-second clip of someone failing ends discussions that slides can't.

Convert opinion into a question. "What would we need to see to know either way?" This moves the room from whose taste wins to what's true, and it's very hard to refuse.

Offer the cheap test. "Give me two days and five people." Most disagreements aren't worth a study; the ones people fight about are.

Make it reversible. Big irreversible decisions attract fear and politics. "Let's ship it behind a flag for a week" lowers the stakes enough for a real decision.

Then commit. Sometimes you lose. Note the decision and your objection in the log, implement it properly, and don't sabotage it with a half-hearted execution. If it turns out badly, the log — not an argument — is what changes the next decision.

Your job isn't to win the room. It's to make the decision checkable.

In practice

Write your framing before every review. Four lines: problem, constraints, what I need feedback on, what's already decided.

Ask "what made you say that?" once per session. It's the single highest-yield question in this article.

Keep a decision log. One line per decision, with the reason. A text file is enough, and it will save you an argument within a month.

Sort feedback into three piles afterwards: reaction, preference, reasoned objection. Act on the third, mine the first, park the second.

Bring one user quote to your next disagreement. Not a summary — the words.

Practise on someone else's work. Critique a product you don't own, out loud, using the point–observe–connect structure. It's much easier to learn the form when your ego isn't in it.

Check yourself

Close the article and answer in your own words:

Why does design criticism feel personal, and what does that imply about how to handle it?
What four things should you say before showing work?
What's the difference between a prescription and an observation, and how do you get from one to the other?
Name the three kinds of feedback and what to do with each.
What's the shape of a useful critique comment?
Why must the decider be named before a critique session?
Name three moves for disagreeing with someone more senior than you.

In short

Critique feels like attack because design is exposed and you're over-attached to what you built. Separating self from work is a skill, not a trait.
Frame before showing: the problem, the constraints, what you want feedback on, what's already decided.
People give prescriptions; you extract the observation underneath with "what made you say that?"
Sort input into reactions, preferences and reasoned objections, and treat each differently.
Give critique as point → observe → connect to the goal. No solutions without a stated problem; separate defects from preferences.
Name the decider in advance and keep a decision log; without it, settled questions come back.
Disagree with seniority using user quotes, "what would convince us?", a cheap test and reversibility — then commit either way.