#07 Most design feedback teaches the wrong thing.

For most of my career, I gave design feedback the way everyone else did.

Annotated files. Red marks, numbered comments, specific change requests. Move this element here. Reduce the hierarchy here. This label is confusing, try this instead. Detailed, precise, actionable.

The designer would take the feedback, implement the changes, and the work would be better. I would feel productive. The loop closed cleanly.

About eighteen months ago I noticed something uncomfortable about that loop: the designer was getting better at fixing things. They were not getting better at seeing things.

When you tell a designer what to change, you are doing the seeing for them.

The designer learns to execute your corrections. They get faster at implementing feedback. Over time, they internalize your specific preferences and produce work that requires fewer corrections. This looks like growth. It is partly growth. It is also, partly, the designer becoming a better executor of your judgment rather than a better exerciser of their own.

In a world where execution is the scarcest resource, this is fine. Fast, accurate execution is valuable. Feedback that produces it efficiently is doing its job.

In a world where AI can execute almost anything that gets specified precisely enough, the calculus changes. If the designer’s primary skill is executing feedback well, that skill is converging with what the tool does. The feedback loop is producing something that is becoming cheaper.

I started giving one question instead of a list of changes.

Not always. Some feedback is genuinely about execution and the specific correction is the right thing to give. But when the work was off in a way that felt structural rather than surface, I stopped marking it up and asked a single question instead.

The question is usually some version of: what decision does this screen help the user make?

Sometimes: what does the user know when they leave this flow that they did not know when they arrived?

Sometimes: what is this screen for, specifically, at this point in the user’s journey?

These questions do something different than annotations. They require the designer to go back to the thinking that produced the work rather than the work itself. If the thinking was wrong, the screen will change more than any annotation could produce. If the thinking was right and the execution was the problem, the designer can usually see the execution problem themselves once the thinking is confirmed.

The work started coming back different in kind, not just in quality.

When I give annotated feedback, the next version looks like the annotated version. The designer has addressed the marks. When I give a question, the next version sometimes looks completely different. The designer saw something that the annotation would have papered over.

The process got slower. The meetings where we discussed the question took longer than a feedback walkthrough. The designer needed time to think that a correction does not require.

The results were better in a way that was hard to quantify but obvious in the room. The work was coming from somewhere more solid. Not just from fixing what I had marked.

I also noticed something about what I was doing when I gave annotations. I was making micro-decisions continuously. What the hierarchy should be, what the label should say, where the element should sit. These are often judgment calls. I was making them implicitly, embedding them in feedback, and calling the result the designer’s work.

The question puts the judgment call back where it belongs.

A designer who is not yet able to answer the question is a designer who needs different support before the question is useful. The question assumes a certain level of independent thinking. With a junior who is still building that capacity, annotation has a role.

The question also does not work when the brief itself is wrong. A designer cannot answer “what decision does this screen help the user make” if the screen exists because of a bad premise. In that case the question surfaces the bad premise, which is useful, but the feedback conversation has to go somewhere different from there.

Knowing which situation you are in before you open the file is most of the work.

×××