Most design feedback makes the work worse. Not because the people giving it lack taste, but because they describe symptoms, prescribe fixes, and skip the part that actually helps: what the design is failing to do. A designer can act on a clear problem. A designer cannot do much with “make it pop.”
Feedback is a skill, and it is one of the highest-leverage skills a client or a stakeholder can develop. Get it right and you compress weeks of revision into a couple of focused cycles. Get it wrong and you watch a strong concept get sanded down to something safe and forgettable.
Why “I don’t like it” stalls the work
When you react instead of diagnose, you hand the designer a guessing game. “I don’t like the header” could mean the hierarchy is wrong, the color feels off-brand, the copy is too long, or the whole thing reminds you of a competitor. The designer now has to reverse-engineer your reaction, and each wrong guess is another round.
The deeper issue is authority. Taste-based feedback (“I’d go bigger,” “try blue”) quietly puts the stakeholder in the designer’s chair. You are no longer briefing a specialist. You are art-directing them by remote control, using less information than they have. The work suffers because the person with the craft is now executing the opinions of the person without it.
Good feedback describes the problem and protects the designer’s authority to solve it.
There is a cleaner division of labor. You own the goals, the business context, and whether the work is hitting the mark. The designer owns how to get there. Keep feedback on your side of that line and the collaboration holds.
A simple structure: observe, impact, ask
The most reliable feedback I give follows three moves, in order.
Observe what you actually see. State the concrete thing, not your verdict on it. “The eye lands on the illustration first, then the headline” is an observation. “The hierarchy is wrong” is a verdict dressed up as one. Observations give the designer a shared starting point; verdicts skip straight to a conclusion they may not share.
Name the impact against the goal. This is the move almost everyone drops, and it is the one that matters. Tie what you saw to what the work is supposed to do. “Because the illustration wins, a first-time visitor reads the brand as playful before they understand what we sell, and we agreed this page has to qualify enterprise buyers.” Now the feedback has weight. It is anchored to something you both already decided.
Ask, don’t prescribe. Resist handing over the solution. “Can we get the value proposition to land first?” leaves room for the designer’s craft. “Make the headline 48px and move the illustration down” forecloses it, and your spec is rarely better than what a good designer would reach for once they understand the problem. If you genuinely have a constraint (legal needs the disclaimer above the fold), say so as a constraint, not as a design instruction.
Run those three together and a single note sounds like this: “I notice the illustration pulls focus before the headline. For an enterprise visitor that reads as playful before they know what we do, which fights the qualifying job this page has. Is there a way to make the proposition land first?” That is something a designer can build on.
Separate the layers before you open your mouth
Half of bad feedback is feedback aimed at the wrong layer. Before you speak, sort your reaction into one of three buckets.
- Direction. Is this the right concept at all? Direction notes belong early, on routes and wireframes, never on a polished comp. Questioning the concept after a week of refinement is expensive and demoralizing, and it usually means the earlier review was rushed.
- Execution. The concept is right; the craft needs work. Spacing, type, contrast, the strength of the hierarchy. This is the bulk of healthy feedback on a mature design.
- Preference. You would have done it differently, but the work meets the goal. Preference is the bucket to hold your tongue on. If you cannot tie a note to a goal or a constraint, it is probably preference, and forcing it in is how distinctive work dies.
Saying which layer you are in does half the designer’s triage for them. “This is a direction question, not an execution one” tells them whether you are about to question the foundation or polish the surface. That single sentence prevents a lot of defensiveness.
The right moment matters as much as the right layer. Pushing a concept question late, or polishing pixels on a wireframe, both waste the work. The phase of the project tells you which notes are useful right now. If you are still deciding between approaches, you are in wireframing and prototyping territory, and fidelity-level nitpicks are noise.
Practical rules that keep cycles tight
A few habits separate teams that get great work from teams that exhaust their designers.
Consolidate. Send one structured set of notes, not a trickle of messages across two days. Drip feedback forces constant context-switching and contradicts itself as your thoughts evolve. Sit with the work, gather everything, then send it once.
Resolve internal disagreement before it reaches the designer. Conflicting notes from three stakeholders are not the designer’s problem to referee. Decide internally what you are asking for. If you genuinely disagree, say so openly and name who has the final call, rather than shipping the designer a contradiction.
Lead with what works. This is not about being nice. When you tell a designer which parts are landing, you protect those parts from getting changed in the next round and you signal what “good” looks like for this project. Specific praise is information, the same as a specific critique.
Cap the rounds. Agree up front on how many feedback cycles a deliverable gets. Two substantive rounds is plenty for most work. Open-ended revision is where projects go to die, and a round limit forces everyone to make their notes count. If you are formalizing how the whole engagement runs, settle this alongside the rest of the working agreement when you first work with a designer.
Ask before you assert. When something feels off but you cannot name why, ask the designer to walk you through the decision. Often the choice was deliberate and answers a constraint you forgot. Sometimes it surfaces a real gap. Either way you learn more than you would by issuing a correction.
How Strynal approaches design feedback
We treat critique as part of the craft, not an interruption to it. Inside the studio, feedback is structured: we separate direction from execution, we tie every note to the brief, and we time concept-level questions to the phase where they are cheap to answer. The same discipline runs through our UI/UX work, where the loop between making and reviewing is where a design actually gets good. We bring that rhythm to client reviews too, often inside a focused design sprint, so the conversation stays anchored to what the work has to accomplish rather than drifting into taste.
Because the team that scopes the work also builds it, the people receiving your feedback are the ones who understood the problem from day one. Nothing gets lost handing notes down a chain. If you want a collaboration where your feedback makes the work sharper instead of safer, start a conversation with us.