Key Takeaways — brief reading, less than 30 seconds
- Three failure modes: too vague (no signal), too prescriptive (skips the problem), too late (requires rebuild).
- "Describe the problem, not the solution." Designers solve problems; locking in a solution closes out their craft.
- A working structure: where on the asset, what is wrong, why it matters, optional reference. Three to five items max, ranked by importance.
- The venue matters. Comments on the file beat doc beats meeting beats Slack thread.
- The two cases where silence is the right move: "I would have done it differently" and "feedback that becomes a rebrief."
- Stakeholders feel useful when they leave comments; the work does not care about that feeling. Approving clean work without commenting is a senior skill.
Glossary8 terms
- Brief: The written contract for the work — audience, message, deliverable shape, constraints, success criteria. Feedback that contradicts the brief is a rebrief, not feedback.
- Revision round: One pass through draft, feedback, and rework. Most projects budget two or three. Each extra round costs days and morale, so the feedback that opens a round needs to earn it.
- Specificity: Naming the exact element on the canvas (the hero headline, the third bullet) rather than “the layout.” Specificity is what lets the designer act without guessing.
- Subjective vs objective feedback: Objective: ties to a brief criterion or measurable goal (“the CTA is below the fold on mobile”). Subjective: personal taste (“I’d have used a serif”). Both are allowed, but they should be labelled so the designer knows which to weigh.
- Sandwich method: The compliment-criticism-compliment structure taught in 1990s management books. Designers see through it instantly and it dilutes the actionable signal. Skip it; lead with the problem and the why.
- “Make it pop”: The archetypal vague feedback. Translates a feeling (the work isn’t grabbing the stakeholder) into a non-actionable verb. Replace with: which element feels weak, what reaction the work needs to produce, what reaction it produces now.
- Divergent vs convergent feedback: Divergent: feedback that opens the solution space (“try two more directions”). Convergent: feedback that closes it (“commit to direction B and refine”). Mixing them in the same round produces work that’s neither exploratory nor finished.
- Rebrief: Feedback that changes what the work IS — audience, message, deliverable. Honest move: stop, write a new brief, take the timeline hit. Pretending it’s feedback wastes a revision round and burns the designer’s trust.
Editor's note: This article is for the people giving feedback — brand leads, PMs, marketing managers, executives. The designers reading it will recognise the patterns. The non-designers reading it have a chance to stop producing them.
Most of what gets called feedback on creative work is something else wearing the word. “Make it pop” is a reaction. “Change the headline to red” is a preference dressed as an instruction. Neither tells the designer what the work needs to do, which is the only thing feedback is for. Feedback, properly, is direction — a clear account of what the asset isn’t yet doing, handed to the person whose job is to fix it.
Giving that kind of direction is a craft of its own, separate from the craft of making the work, and most people who give feedback have never been taught it. We wrote about the broader review and approval process; this article is about the feedback craft inside it.
Why Most Creative Feedback Fails#
Three failure modes account for most of the feedback that produces no signal. The fixes are different for each.
- Too vague. “Make it pop.” “It’s missing something.” “Can you push it further?” The designer hears these and has no information to act on. The feedback is a feeling translated into a sentence; the translation lost the feeling. The fix is to name the feeling specifically: which element feels weak, what the work needs to do for the audience, what reaction the current draft produces and what reaction the campaign needs.
- Too prescriptive. “Change the headline to red.” “Move the CTA two pixels to the left.” The feedback skips the problem and jumps to a solution — usually the first solution that crossed the stakeholder’s mind. The designer either implements the prescribed change (often making the work worse) or pushes back (which produces a politics conversation instead of a craft conversation). The fix is to describe the problem the prescription was trying to solve.
- Too late. Feedback after the asset has been built is feedback that requires rebuild. The two-paragraph copy direction that arrives after the layout is locked, the brand-tone change that arrives after the photo shoot wrapped — these are not feedback, they’re scope changes. The fix is to give feedback at the stage where it can be acted on cheaply: structure feedback at wireframe, tone feedback at copy, colour feedback at design.
All three failures share a root cause: the person giving feedback hasn’t separated their reaction from their analysis. The reaction is data; the analysis is craft. Feedback that ships only the reaction (“it’s not working”) wastes the designer’s time. Feedback that ships only the analysis (“move the CTA to the left”) wastes the designer’s judgement.
Describe the Problem, Not the Solution#
The most-quoted principle in creative feedback. “The CTA is hard to find” is feedback. “Make the CTA red” is a design decision dressed as feedback. The first lets the designer solve the problem five different ways; the second locks in the first idea that crossed the stakeholder’s mind, which is rarely the best one.
Designers solve problems for a living. When the feedback names the problem, the designer brings their craft to the solution — weight, contrast, position, motion, white space, type hierarchy. Any one of these can fix “the CTA is hard to find” and the designer is better placed than the stakeholder to know which is right for this brand and this layout. When the feedback prescribes the solution, the designer’s craft is locked out of the conversation. The work gets worse.
The exception: when the prescription is the brief constraint. “The CTA must be red because the brand guidelines require red primary CTAs” isn’t feedback — it’s a constraint. Constraints belong in the brief, not in the feedback round. If the constraint is showing up for the first time at feedback time, the brief was incomplete, which is a different problem than feedback.
A Structure That Works in One Round#
For each piece of feedback, four parts in order:
- Where on the asset. Specific element, not “the layout” or “the design.” The hero headline, the third bullet in the feature list, the spacing between the logo and the photograph. The designer needs to know where the comment lands on the canvas.
- What’s wrong. The problem in one sentence. Use plain language; avoid words that mean different things to different roles (“balance,” “rhythm,” “hierarchy”) unless you’re sure your designer hears them the same way you do.
- Why it matters. The underlying goal the problem prevents. “The CTA is hard to find, which means scrolling visitors miss the conversion event the campaign is for.” The why connects the problem to the brief.
- Optional: an example of what would solve it. Reference images, a competitor’s solution, a sketch. This is suggestion, not direction; the designer is free to take it or leave it. Mark it explicitly as a reference, not a deliverable.
Three to five items, ranked by importance. Twenty-seven bullet points across four pages is a way of giving zero feedback while feeling like you gave a lot. Designers triaging twenty-seven items have to guess which three matter; the wrong three get fixed, the right three don’t, round two arrives looking like round one.
Where the feedback lives matters too. Comments on the file beat written feedback in a doc beats meeting feedback beats a Slack thread. Comments on the file are anchored to the specific element; doc feedback requires the designer to map sentences to canvas regions; meeting feedback requires the designer to take notes; Slack-thread feedback evaporates the next time the channel scrolls. We wrote about why Slack is the wrong place for approval; the same logic applies to feedback. Use the right venue for the right artefact.
A Gallery of Bad Feedback (and What to Say Instead)#
The bad-feedback patterns recur across teams and industries. The fixes also recur. Each row pairs the common pattern with the specific change that turns it into actionable signal.
| What stakeholders say | What to say instead |
|---|---|
| "Make it pop." | The headline doesn’t grab the eye in scrolling preview. Can the visual hierarchy push it forward? |
| "Can you try a few different versions?" | I want to see two more variations on the layout — one with the image right, one without the supporting paragraph. |
| "I’ll know it when I see it." | I don’t know yet. Let me look at competitors X and Y over the weekend and come back with three reference images Tuesday. |
| "My CEO wants a different shade of blue." | The CEO reviewed and asked for a darker blue closer to our brand-primary value. Can you try [hex] or one shade darker? |
| "27 comments scattered across 4 pages." | These are my top 5 in priority order. The rest can wait for round 2 or come up in retro. |
| "Can you make it more modern?" | The card style and the type pairing read like 2018. Reference these three sites that feel current to me; I’m looking for that level of restraint. |
| "It needs more energy." | The hero composition feels static — the eye doesn’t move through it. Can we try a layout with more diagonal motion? |
The bad versions skip one or more of these: the specific element, the problem in a sentence, the context for the designer to bring their craft to the fix. The good versions make the designer’s next step obvious.
When Not to Give Feedback#
Sometimes the right move is silence. If the work meets the brief and you’re just nudging it toward your taste, you’re burning a revision round on personal preference. The brief is the contract. If the work meets the contract, approve it.
Two cases where silence is the better move.
The “I would have done it differently” case. The work is good and meets the brief. You wouldn’t have made the same choice. That’s fine. The designer wasn’t hired to do what you’d have done; they were hired to bring craft you don’t have. Asking them to redo work you’d have done differently produces a worse final asset and trains the designer to second-guess their own craft. Silence is the move.
The “feedback that becomes a rebrief” case. Your feedback would change what the work IS. Different audience, different message, different deliverable shape. That’s not feedback — it’s rebriefing. Stop, write a new brief, start the next round properly. The brief is the contract; if the original brief didn’t say red, asking for red is a rebrief, not feedback. The honest move is to acknowledge the rebrief, take the timeline hit, and let the designer start from a clear position rather than chase a moving target.
The discipline of not giving feedback is harder than the discipline of giving good feedback. Stakeholders feel useful when they leave comments; the work doesn’t care about their feeling useful. The senior people who learn to approve clean work without volunteering improvements are the people designers want to work with for years; the senior people who can’t resist a comment on every round are the people designers learn to route around.
Frequently Asked Questions #
How do you give feedback when you can’t articulate what’s wrong?
Is “make it pop” ever ok?
How many revisions is too many?
Should leadership review the final round or every round?
Feedback by Slack thread, doc, or in person?
How do you push back on bad feedback from a senior person?
