Design revisions go wrong for a predictable reason: feedback describes a feeling and the designer has to guess at a cause. A small change in how you phrase things turns three rounds into one.
Useful design feedback describes the problem, not the solution. Say this does not feel trustworthy enough for our audience rather than make the logo bigger. Tie every comment to a goal or an audience, consolidate feedback into one voice before sending it, and separate subjective preference from a business requirement.
Describe the problem, not the fix
When you propose a solution, the designer implements it and the underlying problem often survives. When you describe the problem, they can apply the right fix, which may be nothing like what you would have suggested.
| Instead of | Say |
|---|---|
| Make the logo bigger | It does not feel like our brand owns this page |
| Use a different blue | This feels colder than we want for a family audience |
| Move this up | Buyers ask about price early and it is hard to find |
| I do not like it | Something here feels off. Walk me through the reasoning |
| Add more white space | It feels crowded and I am not sure where to look first |
Consolidate before you send
The most damaging pattern is six people emailing conflicting comments directly to the designer. They cancel out, the designer picks a path, and everyone is unhappy.
Collect all feedback, resolve the contradictions internally, and send one consolidated set from one named decision-maker. If two stakeholders disagree, settle it before the designer hears about it.
Separate preference from requirement
- Requirement: our compliance team needs this disclaimer visible. Non-negotiable, and should have been in the brief.
- Evidence: our customers consistently ask about delivery, so it needs to be prominent. Strong.
- Preference: I prefer the other font. Valid, and should be labelled as taste rather than dressed up as strategy.
Labelling which is which lets a designer push back on preference where it conflicts with evidence, which is what you are paying them for.
Running the review
- Ask for the reasoning before giving reactions. Most objections dissolve once the intent is explained.
- Review against the brief, not against the last site you liked.
- Give feedback in one session rather than a trickle over days.
- Agree how many rounds are included so both sides know where the boundary is.
- Sign off in writing at each stage so scope does not reopen later.
Frequently asked questions
Why do design revisions take so long?
Usually because feedback describes solutions rather than problems, or arrives from several people with contradictory views. Both make the designer guess. Consolidated feedback that explains what is wrong rather than what to change converges much faster.
How many design revision rounds are normal?
Two to three for a typical project. More than that usually signals a brief problem rather than a design problem: either the goals were never agreed or too many people have veto power without agreed priority.
What if I genuinely just do not like it?
Say so, then work backwards with the designer to find out why. Dislike is real data, it is simply not actionable until the cause is identified. A good designer will help you unpick it rather than take offence.
Should the client or the designer decide?
The client decides on business requirements and audience knowledge. The designer decides on craft: hierarchy, spacing, typography, accessibility. Problems arise when clients direct craft and designers overrule business knowledge.
How do I handle conflicting internal feedback?
Resolve it before it reaches the designer, and appoint one person with final say. Contradictory feedback sent straight through guarantees revisions that satisfy nobody and burns rounds you have paid for.