How to Give Design Feedback That's Actually Actionable

Design feedback fails for one reason more than any other: it reports a feeling and omits the observation that produced it. “It feels cluttered” is real information about the reviewer’s experience and gives the designer nothing to change. This is a format that fixes that, for both sides of the review.

The Problem

Look at the notes on the last thing you reviewed. Most of them are probably in one of these shapes:

• A feeling without a cause. “Doesn’t feel premium.” True, unactionable.
• A location without a problem. “The header.” What about it?
• A solution without a reason. “Make the button blue.” Why? If blue turns out to be wrong, nothing remains to solve.
• A preference stated as a defect. “Nobody uses carousels.” Sometimes true, often taste.
• A global judgment. “The whole thing feels off.” Nowhere to start.

Each of these costs a round trip, and the round trip is expensive: a clarifying question, a day of waiting, an answer that is often still vague.

The underlying issue is that reviewers are asked to evaluate and to diagnose at the same time, and diagnosis is a skill. Most reviewers can accurately report what they experienced. Fewer can identify what caused it. A format that only asks for the first works far better than one that expects both.

The Format

Three parts. Where, what, why.

Where: the pricing table What: I read the middle column as the cheapest option Why it matters: we want people on the annual plan, and I picked the wrong one

Nobody has to guess anything. The designer knows the location, the observed effect, and the goal it conflicts with — and now has a solvable problem: make the annual plan read as the intended default.

Compare: “the pricing table is confusing.” Same reviewer, same reaction, no information.

Where — location, precisely

If you can point at it, point at it. This is the single biggest reason to review on the live page rather than in an email: a pinned comment carries its location for free, and no prose is required. On Undraft you click the element and type; the location is the pin.

If you cannot point, be surgical in prose: “the third card in the features row,” not “the middle bit.”

What — the observation, not the diagnosis

Report what happened to you, not what you think is technically wrong:

• “I scrolled past the signup form without noticing it” — excellent.
• “The signup form has insufficient contrast” — maybe true, and it is a guess at the cause.

The first is something only you can supply and cannot be argued with. The second is the designer’s job. Do not do their job badly when you can do yours well.

Why it matters — the consequence

This is the part people skip and it is what makes prioritisation possible.

• “…and new visitors are the whole audience for this page” → high priority.
• “…and I would personally have used a lighter grey” → preference, low priority.

Stating the consequence also stops you filing feedback that has none. A surprising share of review comments dissolve when you try to write down why they matter.

Two More Rules

Label preferences as preferences

“I would have used a serif here — preference, not a blocker” is genuinely useful. It shares taste without demanding compliance.

Unlabelled preferences are corrosive. The designer cannot tell which of your thirty notes are requirements, so they treat all of them as requirements, and the design becomes an average of everyone’s taste.

Rank when you have more than five notes

Thirty unranked comments get triaged by the designer’s guess at what matters. Their guess will not match yours.

Three tiers is enough: blocking, should fix, nice to have. Ten seconds of sorting saves an entire round.

For the Person Receiving Feedback

Half the problem is on the receiving side, and two habits fix most of it:

Ask for observations, not verdicts. “Where did you get stuck?” produces better information than “what do you think?” — because it asks for something the reviewer actually has.

Frame the round. “Reviewing layout and copy; images are placeholders; the payment step is stubbed.” This eliminates the off-target comments before they are written, and off-target comments are a large fraction of the total.

Close every note. Resolve or decline, explicitly. Declining is fine and far better than silence — silence is what brings an objection back in a meeting a month later.

Examples

Before

Six comments on a landing page, in an email:

1. “Feels a bit corporate”
2. “The header”
3. “Make the CTA bigger”
4. “Not sure about the images”
5. “Something’s off on mobile”
6. “Overall good direction!”

Five clarifying questions required. Nothing can be started today.

After

The same reactions, in the format, pinned to the page:

1. Hero headline — “I read this three times before I understood what the product does.” Blocking — this is the first thing anyone sees.
2. Nav — “I looked for pricing in the top right and it was not there.” Should fix.
3. CTA — “I did not notice it on the first scroll.” Should fix. Possible cause: it is the same colour as the section behind it — suggestion only.
4. Feature images — “These read as stock photos to me.” Preference.
5. Third section, mobile — “Text overlaps the image at phone width.” Blocking — bug.
6. Overall: direction is right.

Zero clarifying questions. Two blockers, clearly separated from one preference.

Summary

• Use where / what / why for every note — location, what you observed, and the consequence, in that order.
• Rank anything over five notes into blocking, should fix, and nice to have.
• Avoid reporting diagnoses instead of observations — “I scrolled past it” is worth more than your guess at the reason.

Next: the mechanics of putting notes where they belong — comment on a webpage — and how to share an HTML file for review.