By Mehdi HassanMany extra revision rounds aren't caused by bad design. They're caused by feedback the designer has to guess at: "make it pop", "it feels off", "can we try something more modern". Each vague comment produces a guess, the guess misses, and another round starts. The fix is a simple structure for every comment.
How should you give website design feedback?
Give website design feedback by stating what you see, explaining why it matters to a goal and describing the outcome you want, without dictating the solution. Designers are good at solving problems and bad at reading minds. A comment that names the problem lets them solve it; a comment that names a fix ties their hands and may not solve the real issue.
Feedback works best when there's something to measure it against. In a well-run website design process, that's the brief written during the discovery phase: the audience, the goal and the core message. If a comment can't be linked to something in the brief, ask yourself whether it's a real problem or a preference.
What does a good design feedback template look like?
A good design feedback template has four parts: where, what you see, why it matters and what you want to happen. Writing comments in this shape takes a little longer, but each one can be acted on in a single pass.
In this section, I notice this, which matters because of this goal. Could we find a way to achieve this outcome?
Use the template for problems. For things you like, a short note is enough, as long as it's specific: "The pricing table is clear, keep this structure" protects that part of the design from being changed in the next round.
What are examples of good and bad design feedback?
Bad design feedback is vague or prescriptive; good feedback is specific about the problem and open about the fix. The table below rewrites common comments using the template.
Vague or prescriptive | Goal-linked rewrite |
|---|---|
Make the logo bigger. | On mobile, the brand gets lost next to the menu. Our buyers need to recognize us from the ad they clicked. |
It doesn't pop. | The hero reads as quiet next to competitor sites. We want the main claim to be the first thing people notice. |
Use blue instead. | The red call to action reads like a warning to me. Can we test whether it feels inviting to our audience? |
Add more content here. | Buyers ask about security on every call, and this page doesn't answer it. Where could that fit? |
I don't like the font. | The headline type feels playful, and our buyers are compliance teams. Can it feel more serious without losing warmth? |
Can we make it like this other site? | I like how this reference shows the product early. Our visitors also need to see the product fast. |
How do you give website revision feedback step by step?
Review a design in a fixed order: structure, then copy, then visuals, then details, and send one consolidated list. Reviewing out of order wastes rounds. Polishing button colors on a page whose structure will change is effort thrown away.
Re-read the brief
Spend two minutes on the brief before opening the design. Note the audience, the goal and the one action the page must drive.
Review on the right device
Look at the design at real size, on desktop and on a phone. A Figma frame zoomed out on a large monitor hides problems with legibility and spacing.
Check structure first
Does the page answer the visitor's questions in the right order? Is anything missing or in the way? Structural issues come before anything else.
Then copy and message
Does the headline say what the product is and who it's for? Are claims accurate and approved? Copy problems often look like design problems.
Then visuals and details
Only now look at type, color, imagery, spacing and interactions. Use the template for anything that doesn't serve the goal.
Consolidate and prioritize
Merge comments from everyone into one list, resolve conflicts internally and mark each item as must-fix or nice-to-have.
Who should give feedback on a website design?
One named approver should give the final feedback on a website design, with input gathered from a small group beforehand. More reviewers doesn't mean better feedback. Each extra voice adds preferences, and every preference that reaches the designer becomes a revision.
A good setup is a founder or marketing lead as the approver, plus one or two people who talk to customers, such as sales or support. They bring real objections and questions, which make the most useful comments. Investors, friends and family can be useful for a gut check, but their comments should be filtered through the approver, not passed on directly.
For example: turning a messy review into one list
For example, suppose a founder, a head of sales and an advisor all review a homepage. The founder wants a bolder headline, sales wants the security section moved higher, and the advisor dislikes the illustration style. Rather than forwarding three emails, the founder checks each comment against the brief.
The security request links to a real buyer objection, so it becomes a must-fix. The headline comment becomes a goal-linked request: buyers should understand the product in one read. The illustration comment has no link to the brief, so the founder notes it as a nice-to-have and asks the designer for their view. The designer receives three clear items instead of a debate.
How do you give feedback on a live staging site?
On a staging site, give feedback directly on the page with screenshots or comments pinned to elements, and include the device and browser you used. Once the design is built, many comments become about behavior: how something animates, how a form responds, how a section collapses on a phone. These are hard to describe without context.
- Include the device and browser, since a bug on one phone may not exist on another.
- Screenshot or record it, especially for animations and micro-interactions.
- Separate bugs from changes. A broken form is a bug; a different headline is a change, and it may affect scope.
- Check accessibility basics too. Contrast and focus states are easy to notice on a live page; our accessible design basics list what to look for.
Most teams review builds on a staging environment or preview link before launch. Keep feedback there, in one thread or tool, rather than scattered across email and chat.
