Web Design

How to Give Design Feedback That Improves the Work, Not Just the Mood

Your designer just delivered the first round of pages, and what you say next will either buy you a sharper website or burn a revision round on noise. Most operators have never been taught to give design feedback, so they default to reactions, 'make it pop,' 'I don't love the blue', or to art direction they are not qualified to give. Both waste the contract's most limited resource. Feedback is a deliverable with a craft of its own: name the problem, cite the evidence, rank the severity, speak with one voice. This guide gives you the protocol, the taste-versus-judgment filter, and the way to handle pushback.

Joshua Agonya Pi'Rwot

By Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator

Executive summary

Bad feedback is the silent budget-killer of web projects: vague reactions, prescribed fixes, five conflicting voices. Good feedback names the business problem and lets the designer solve it. Here is the protocol.

Section 1

Why feedback is where budgets quietly die

Revision rounds are the most expensive meetings in a web project, and most operators spend them badly. The failure modes are predictable. Vague reactions, 'it's not popping,' 'something feels off', force the designer to guess at the problem behind the words, and each guess costs a round. Prescribed fixes, 'make the logo bigger, move that box up', turn a trained professional into a pixel-pusher executing amateur art direction. And uncollected opinions, the founder, the sales lead, and a spouse each sending separate notes, produce contradictory instructions the designer resolves by averaging, which is how websites end up beige in every sense. Contracts typically include two or three revision rounds; teams that burn them on noise then pay change-order rates for the rounds that actually matter. Feedback is not a reaction. It is a deliverable, and it deserves the same discipline as any other handoff in the project. The thinking here builds on [How to Run a Website Project Without Being a Designer: The Operator's Process](/blog/how-to-run-a-website-project-without-being-a-designer).

Section 2

The feedback protocol, round by round

Run every review round through the same five-step protocol in the table below. The heart of it is translation: your job is to report problems in business terms and leave solution space open. You hold information the designer cannot have, what prospects ask on sales calls, which objections kill deals, what your delivery team can actually promise. The designer holds craft you do not. Feedback works when each side ships what only they know. Before writing anything, reread the page's job in the brief and the approved wireframe; most 'design problems' turn out to be drift from decisions already made, and pointing at the document is faster and less personal than debating taste. Then consolidate: one written document per round, conflicts between stakeholders resolved by the single decision-maker before the designer ever sees the notes.

Section 3

Separating taste from judgment

The hardest discipline in design review is distinguishing 'I don't like it' from 'it doesn't work.' Both feelings arrive identically in your gut; only one belongs in the feedback document. The filter is the brief: if you cannot connect a reaction to the page's job, the audience, or an approved decision, label it honestly as preference and spend it sparingly, you get a few taste cards per project before the designer stops hearing signal in your notes. Vignelli's warning that design without discipline is anarchy cuts both ways here: it indicts sloppy designers and sloppy reviewers alike. When genuinely unsure whether something works, do not debate it in a comment thread, test it. Nielsen Norman Group's five-user research means an afternoon with five strangers settles most arguments for less than the meeting would cost. 'Let's get data' is the most senior sentence an operator can say in a design review. For the step that usually comes next, see [Web Design for IT Services and MSPs: Converting Buyers in Pain](/blog/web-design-for-it-services-and-msps).

Section 4

Receiving pushback like an operator

Good designers push back, and the pushback is part of what you paid for. When yours says the wall of badges you requested will bury the booking CTA, that is craft knowledge colliding with your instinct, treat the collision as information. The productive response pattern: restate the business concern behind your request, hear their reasoning fully, then either defer to craft or override with named commercial logic. 'I hear that it crowds the page; pricing objections kill a third of our deals, so visible pricing wins this one' is an override a professional respects. What corrodes the relationship is silent overruling, taking their delivered work to a cheaper hand for 'small tweaks.' Inside ConvertOS engagements, this protocol is set in the kickoff: written rounds, evidence-backed observations, one decision-maker, pushback expected. Teams adopt it in one project and report fewer rounds, better pages, and vendors who bring their best ideas instead of their safest ones. For a deeper look at this, see [Inbound Lead Generation for Service Businesses: Content That Books Calls, Not Just Clicks](/blog/inbound-lead-generation-service-businesses).

FAQ

Direct answers for operators.

What does good design feedback actually sound like?

It names a business problem, attaches evidence, and stops short of the solution: 'Prospects ask about pricing on every call, and a skimmer can't find it on this page, three people mentioned it last week.' That gives the designer a real constraint to solve. Compare 'make the pricing section bigger and red,' which prescribes an amateur fix and hides the actual information the designer needed.

How do I handle multiple stakeholders with conflicting design opinions?

Never forward raw, conflicting notes to the designer, averaging contradictions is how sites turn beige. Collect all input internally, have the single named decision-maker resolve conflicts against the brief, and ship one consolidated document per round. Stakeholders whose notes lost the internal debate hear why from you, not silence from the vendor. One voice per round is the difference between three rounds and seven.

What if I just don't like the design but can't explain why?

Say exactly that, labeled as preference, 'this is taste, not a defect', and spend such cards sparingly. Then check the reaction against the brief: often discomfort traces to a real drift from the approved wireframe or message, which you can cite instead. If the disagreement matters commercially, test it: five user tests settle in an afternoon what comment threads argue for weeks. Unexplained vetoes, repeated, teach your designer to play safe.

Joshua Agonya Pi'Rwot

Written by

Joshua Agonya Pi'Rwot

Founder, Business Growth Accelerator · Country Director, AVODA Group Uganda · EMBA

Joshua helps service-business operators turn scattered marketing into a clear path from first attention to booked call. He is Founder of Business Growth Accelerator and Country Director of AVODA Group Uganda.