Every revision round costs time and money, and most extra rounds come from feedback that's hard to act on: "it doesn't pop", "make it more modern", "something's not right about the top bit". Designers want your input. Here's how to give it so each round moves the design forward.
Describe problems, not solutions
The most useful feedback explains what isn't working and why, and leaves the designer to solve it.
| Less useful | More useful |
|---|---|
| "Make the button red." | "I'm worried visitors won't notice the booking button." |
| "Make it more modern." | "It feels a bit corporate; our customers are young creatives." |
| "Make the logo bigger." | "Our brand doesn't feel prominent enough on the homepage." |
| "I don't like it." | "The hero photo doesn't show what we actually do." |
Be specific about where
Point at the exact element: "the second paragraph under Services", not "the middle section". Screenshots with arrows help; so does annotating directly on the page.
Tie feedback to goals and users
Refer back to the brief. "Our main goal is bookings, and the booking button is below the fold on mobile" is hard to argue with. "My partner prefers blue" is easy to argue with. If you want a refresher on what the brief should contain, see how to write a website brief.
A simple feedback format
For each point, give:
- Where: the page and element
- What: what you noticed
- Why: the goal or concern behind it
- Priority: must-fix, should-fix or nice-to-have
For example: "Homepage hero, headline / It describes us, not the customer's problem / Visitors may not see why we're relevant / Must-fix."
Consolidate before you send
If several people review, collect their comments, resolve contradictions and send one list. Two stakeholders asking for opposite changes forces the designer to guess, or to do both, which costs a round.
Separate taste from function
Taste matters, but say which is which. "This colour feels cold to me (taste)" and "this text is hard to read on grey (function)" need different responses. For readability issues, check colour contrast against accessibility guidelines.
Review at the right level
- Early concepts: look at overall direction, layout and feel. Don't nitpick copy or exact colours yet.
- Detailed designs: content, hierarchy, states and edge cases.
- Built pages: real devices, real content, typos and links.
Example: rewriting a round of vague feedback
Before:
Not sure about the homepage. It doesn't really pop and feels a bit off. Can we try something more modern? Also the colours.
After:
- Homepage hero, headline / must-fix: it describes our company, not the customer's problem. Visitors may not see why we're relevant. Could it lead with the outcome we deliver?
- Homepage, booking button / must-fix: it's below the fold on my phone. Bookings are our main goal.
- Overall feel / should-fix: it reads more corporate than our audience (young creatives). Could the photography and type feel more relaxed?
- Colours / nice-to-have: the grey background feels cold to me personally. Happy to be talked out of it if it tests well.
Same opinions, but now the designer knows exactly what to change and why.
Feedback by design stage
| Stage | Focus on | Avoid |
|---|---|---|
| Moodboards and direction | Feel, tone, audience fit | Exact colours, copy |
| Wireframes | Structure, content order, user journeys | Visual styling |
| Visual designs | Hierarchy, brand, imagery, key screens | Rewriting copy line by line |
| Built pages | Real content, devices, interactions, typos | Changing direction |
Giving the right feedback at the right stage avoids costly rework later.
Tools that make feedback precise
- Annotated screenshots with arrows and numbers
- Comment tools in the design file or staging site, pinned to elements
- Screen recordings with voice for flows and interactions
- One shared list where every comment has a status: open, in progress, done, won't do
Whatever you use, keep everything in one place. Feedback split across email, chat and calls gets lost.
Feedback mistakes that cost extra rounds
- Feedback trickling in over days instead of in one batch
- Rewriting copy inside design feedback instead of sending copy separately
- Asking for "options" without saying what's wrong with the current one
- Approving, then changing direction later; see handling new ideas fairly
- Leaving designs unreviewed for a week; slow feedback has a cost of delay
Phrases that help (and phrases that don't)
| Instead of | Try |
|---|---|
| "Make it pop" | "The call to action gets lost next to the photo; it needs more contrast" |
| "I don't like it" | "This feels too formal for our audience of young parents" |
| "Can you try a few options?" | "The headline is too long on mobile; can it fit on two lines?" |
| "It's too busy" | "There are three different messages above the fold; we only need the first" |
| "Use our brand colours more" | "The green here isn't our brand green; ours is in the brand guidelines" |
Giving feedback as a group
When several people review a design:
- Name one decision-maker who has the final say.
- Collect everyone's comments separately first, so the loudest voice doesn't shape the rest.
- Merge them into one list, removing duplicates and settling contradictions before they reach the designer.
- Mark each item as must-have, nice-to-have or question.
- Send it once, with a date for the next round.
Point at it and say it
The fastest feedback is pointing at the thing and saying what you want. Zelvorm's Speak-to-Pin lets clients do exactly that on their staging site: point at any element, say the change, see a live preview, and the AI turns it into a precise developer ticket with a screenshot. No more "the thing near the top".
The short version
Describe problems and goals rather than prescribing solutions, point at exact elements, tie comments to the brief, mark priorities, consolidate feedback from several people into one list and review at the right level for each stage.
