What Good Design Feedback Sounds Like

Alexander Chua
7 min
What Good Design Feedback Sounds Like

The short version

  • A note describes what the reviewer noticed. Useful feedback names the decision behind it, which usually sits upstream of the file.
  • Ask what would have to change for this to be right, and keep asking until the answer leaves the file.
  • Measured on one subject: prompts with no style-reference image produced 2 of 3 on-style, and 3 of 3 with one attached.
  • A note given twice is a rule. Nine standing editorial rules were written at issue 20 of a newsletter, not issue 1.

Good design feedback names the decision that produced the problem rather than the problem. The note that an image reads as a sticker is a symptom. The decision behind it was compositing a product screen onto a generated phone, and changing that took the batch from zero usable images to three of three.

What is wrong with most design feedback?

It reports a symptom and stops there. The layout feels heavy, or the image looks fake. Both can be accurate and neither is usable, because the designer has to reverse-engineer a cause from a description of an effect.

The cause is rarely on the surface. Compositing a product screen onto a generated phone produced zero usable images. The warped screen sat proud of the bezel and the pasted rectangle carried no screen glow or shared grain, so it read as a sticker. All of that is fixable in retouching. The fault was the method.

Five notes from our own work, and the decision sitting behind each one:

The symptomThe decision behind itWhat changedWhat we measured
Reads as a stickerCompositing a screen onto a generated phoneGenerate the screen into the scene in one pass0 usable became 3 of 3
Off-styleNo style-reference image on the promptAttach one reference image2 of 3 on-style became 3 of 3
Steering wheel on the wrong sideFighting a model prior with prompt wordingCompose so the console stays out of frame5 attempts spent before the change
Does not sound like usThe taste had never been written downNine standing editorial rules plus a QA script11 issues shipped through the gate
Reads thinThe content standard was not in the briefPut the standard in the briefAround 595 words against a 1,000 to 1,400 bar

How do you find the decision behind a symptom?

Ask what would have to change for this to be right, and keep asking until the answer leaves the file. Rebuilding the bezel sits inside it. Generating the screen into the scene in one pass sits outside, and that version came back usable three times out of three.

What does feedback sound like when the fix is not in the file?

It names the input. On one generated ad set the input was the reference: prompts with no style-reference image came back 2 of 3 on-style, and the same subject re-run with one reference attached came back 3 of 3. Told only that the images are off-brand, a designer starts adjusting colour. The useful note names the missing file.

Sometimes the input is composition rather than prompt. Forcing right-hand drive into a generated car interior took five attempts, because the model carries a strong left-hand-drive prior. The note that ended it was about framing: keep the console out of shot.

Why does the same note keep coming back?

Because nothing recorded it. A note given in a review lives in a comment thread nobody reopens, so the next piece carries the same fault.

On one newsletter the fix was nine standing editorial rules plus a QA script that runs before an issue is queued. The rules were written at issue 20, not issue 1, because that is when the repetition became obvious. Eleven issues have shipped through that gate, numbers 20 to 30.

The second time you give a note, write it down as a rule. The third time, put it behind something that checks the work before you see it.

What should a design note contain?

What you noticed, which decision you think produced it, and what you want changed. People leave out the middle part, the only one telling a designer whether to work in the file or go back to the brief.

The version that fails hardest skips to a solution. Move the logo left is a decision the reviewer made on the designer’s behalf with no reasoning attached, ruling out a better fix nobody thought to ask for.

The two habits that stop the same review happening twice are turning a repeated note into a rule something can check and why the brief decides the output.

Frequently asked questions

What makes design feedback useful?

Naming the decision that produced the problem rather than the problem. A note that an image looks fake sends a designer into retouching. Naming the composite changes the method, which took zero usable images to three of three.

How do you give design feedback without being vague?

State what you noticed, which decision you think caused it, and what you want changed. People skip the middle part, the only one telling a designer whether to work in the file or go upstream.

Should you tell a designer how to fix something?

Tell them what you want changed rather than how to change it. Move the logo left is a decision made on the designer's behalf with no reasoning attached, ruling out a better fix nobody asked for.

Why does the same design feedback keep coming up?

Because nothing recorded it. A note in a review lives in a comment thread nobody reopens. On one newsletter we replaced repeat notes with nine standing rules and a QA script that eleven issues shipped through.

What does it mean when feedback says something is off-brand?

Usually that an input was missing. On a generated ad set, prompts with no style-reference image came back 2 of 3 on-style. The same subject re-run with one reference attached came back 3 of 3.

How do you know when feedback belongs in the brief instead of the review?

When you could give the same note on the next piece without seeing it. A predictable note is a standing rule and belongs where the work starts, not in a review.

Sources

  • Chua Network delivery data across 8 client accounts (internal fact bank)
  • Chua Network engagement records, anonymized (internal experience bank)
Alexander Chua

Alexander Chua

Co-Founder, PipelineRoad. Building companies and observing the world across 40+ countries. Writing about company building, go-to-market, capital formation, and the lessons in between.

More about Alexander

Newsletter

Chua Network Letter

Occasional essays on company building, global observations, and clear thinking. No spam. No SEO bait.