In short
Treat feedback as evidence of a problem rather than as an instruction. When someone says make the logo bigger, something about the hierarchy is not working — the observation is usually valid even when the proposed fix is not. Ask what they were reacting to, address the underlying issue, and explain the reasoning when you solve it differently.
Feedback names solutions, not problems
People describe what they want changed in the vocabulary available to them, which is usually the vocabulary of solutions.
Make the logo bigger. Add more white space. Can we try it in blue? It needs to pop.
Each of these is a proposed fix for something the person noticed. The fix is often wrong. The observation underneath is usually right.
"Make the logo bigger" frequently means the page does not feel like theirs, or the hierarchy sends the eye somewhere unintended. Enlarging the logo may not fix that and may make it worse. Understanding what they reacted to might.
Ask what they were reacting to
The most useful response to solution-shaped feedback is a question.
"What made you notice that?" "What were you looking at first?" "What did you expect to happen there?"
This is not deflection, and it should not sound like resistance. It is trying to find the problem so you can solve it properly — and people generally respond well when the intent is obviously that.
Sometimes the answer reveals the suggestion was right. That happens, and taking it is fine.
Distinguish the three kinds
Observations — "I read the third section before the second." The most valuable, because they describe experience rather than preference. Always act on these somehow.
Preferences — "I don't like that shade." Legitimate, especially from the person paying, and worth weighing against the goal rather than treating as either binding or dismissible.
Constraints — "Legal requires that disclaimer." Not feedback at all. Non-negotiable, and worth identifying early so it is not argued about.
Much friction comes from treating a preference as a constraint, or a constraint as a preference.
When to push back, and how
Push back when the change would undermine the stated goal, break something the client cares about more, or introduce a real problem — accessibility, performance, maintainability.
How matters more than whether:
Agree with the observation first, if it is valid. "You're right that the call to action isn't standing out."
Explain the cost specifically. "Making it larger pushes the pricing below the fold, and that is what most visitors come for."
Offer an alternative that addresses the same problem. This is the important part — pushing back without an alternative reads as refusal.
Defer to them when it is genuinely their call. Brand, business priorities, risk appetite. Being right about a preference is not worth the relationship.
Pick the battles that matter. A designer who argues about everything is not listened to about anything.
Contradictory feedback
Two people want opposite things. Both plausible.
Do not average them. The midpoint usually satisfies neither and weakens the design.
Do not choose silently. The person overruled will notice at the next review, and it becomes a bigger conversation than it needed to be.
Surface it and ask for a decision. "Two of you want the form shorter and one wants the qualifying questions kept. These pull in opposite directions — which matters more?"
That is a project management question dressed as a design one, and putting it back to the client is the correct move. It is also frequently the moment the actual priority becomes clear to everyone, including them — the same dynamic as conflicting stakeholder answers.
Keeping the design coherent
The real risk across many rounds is not any single change. It is accumulation.
Each note is reasonable. Applied one at a time over five rounds, they produce something with no through-line — the design equivalent of a codebase where every change was locally sensible.
Review the whole thing periodically, not only the diff. Does it still do what it was for?
Track what changed and why. When something feels wrong later, the history explains it.
Say when the accumulation is the problem. "Individually these are all fine, but together they have moved the page away from its purpose" is a legitimate and useful observation, and clients generally recognise it when shown.
Managing the process
Say what feedback you want. Early structural work needs different input from final polish. "Ignore the colours, they are placeholder" prevents twenty minutes of the wrong conversation.
Consolidate rather than collecting a stream. Ten separate messages produce ten separate revisions. One round produces one.
Agree the number of rounds in the proposal, which makes the sixth round a conversation about scope rather than an argument.
Write down what was decided after each round, and send it. Memory diverges, and a short summary prevents relitigating.
The mindset that helps
The design is not you, and it is not finished when you present it. Feedback is information about how the work performs with people who did not make it — which is the only test that matters.
The designers who improve fastest are the ones who hear "I don't like it" and get curious rather than defensive. Not because the phrase is useful, but because there is nearly always something real behind it worth finding.
If you are getting feedback you cannot reconcile and the project is drifting, book a call.
Common questions
What does it mean when a client says 'make the logo bigger'?
Usually that something about the hierarchy is not working, or the page does not feel like theirs. The proposed fix is often wrong but the underlying observation is usually valid — so ask what they were reacting to and address that, rather than either complying or dismissing it.
When should a designer push back on feedback?
When the change would undermine the stated goal, break something the client values more, or introduce a real problem with accessibility, performance or maintainability. Agree with the valid observation first, explain the specific cost, and always offer an alternative — pushing back without one reads as refusal.
How do you handle contradictory feedback from stakeholders?
Surface the conflict and ask for a decision rather than averaging the views or choosing silently. Averaging satisfies neither party and weakens the design; choosing quietly means the overruled person raises it later. Putting the priority question back to the client is the correct move.
How do you stop a design degrading over many rounds of feedback?
Review the whole design periodically rather than only the latest changes, since each note can be reasonable while the accumulation moves the page away from its purpose. Track what changed and why, and say explicitly when the accumulation itself has become the problem.
How many rounds of design revisions should a project include?
Agree the number in the proposal, so a sixth round is a scope conversation rather than an argument. Also consolidate feedback into rounds rather than accepting a stream of individual messages, since ten separate notes otherwise produce ten separate revisions.
