How to Give Useful Feedback on Website Designs
TL;DR
In this guide
- Review against the brief. Judge how the design supports the audience and task.
- Explain the concern. Name the element, the reason and the intended outcome.
- Consolidate the direction. Resolve contradictions before sending the review.
Useful website design feedback helps the team understand a concern and choose an appropriate response. It should connect the page to its audience, content and business goal. A preference can be part of the review, but it becomes easier to assess when the reason is explained.
The guide at a glance
Three parts of an actionable review
01
Context
Identify the page, element and visitor task.
02
Reason
Explain the communication or usability problem.
03
Outcome
Describe what the revised design should help the visitor understand or do.
Start with the purpose of the page
Revisit the agreed brief before reviewing a design. Who is the page for? What question should it answer? What action should follow? Check whether the content hierarchy supports that task and whether the brand treatment fits the intended audience.
Separate a factual correction from a design preference. Incorrect contact information needs exact replacement wording. A concern about emphasis needs an explanation of which information should be prioritised and why.
Turn a reaction into a useful comment
Reaction: The page feels too busy. Useful feedback: On the service page, the visitor needs to compare the two options before enquiring. The large banner and three competing buttons make that comparison hard to find. Can the service differences be more prominent?
The second comment does not prescribe every design detail. It defines the problem and the intended outcome, giving the team room to suggest a suitable solution. If you have a specific requirement, such as approved brand colours, state it clearly.
Review the content and smaller-screen layout
Read real headings and paragraphs rather than judging empty spaces. A layout may need adjustment when final copy replaces placeholders. Check whether images support the message, whether the next step is clear and whether the mobile sequence still makes sense.
Avoid reviewing isolated elements without their context. A button’s size, position and wording should be assessed in the complete page journey. Animation should also be considered for its purpose and usability, not just its visual effect.
Consolidate stakeholder feedback
Ask the people responsible for approval to review the same version. Gather their concerns, resolve contradictory instructions and send a clear direction. One stakeholder asking for less text while another adds several paragraphs is a content decision that should be settled before the layout is revised.
Mark corrections, important concerns and suggestions so priorities are visible. Identify requests that change the scope, such as a new section or function. Confirm the revised work before approving the relevant stage.
A feedback format to copy
- Page or frame: the current review location.
- Element: the heading, image, section or control.
- Concern: what is difficult to understand or use.
- Reason: the audience need or agreed requirement.
- Desired outcome: the result the change should support.
- Priority: correction, approval issue or suggestion.
For the tool and version workflow, see how to leave project feedback. Keep the reasoning in this format and attach it to the current design or staging page.
Put it into practice
Before sending design feedback
- Confirm the current design version and review purpose
- Read the page against the audience and brief
- Use real content when assessing hierarchy
- Identify the element and explain the concern
- Supply exact wording for copy corrections
- Resolve conflicting stakeholder directions
- Flag changes that may alter the agreed scope
Keep in mind
Describe the outcome before prescribing the solution
“Make the two service options easier to compare” explains a design problem. A specific colour or placement request can then be assessed against that purpose.
Common mistakes to avoid
- Giving a general dislike without a reason
- Reviewing a single element without the page context
- Sending opposing directions from separate stakeholders
- Treating a new function as a minor design correction
A few useful answers
Common questions
Can I say that I do not like a design choice?
Yes. Explain what feels unsuitable and connect it to the brand, audience or task where possible. References with notes can help show the concern.
Should I send a replacement design?
You can share an idea or reference, but explain the problem it solves. The team can then assess it alongside the rest of the page.
When should feedback be considered complete?
After the relevant revised work has been reviewed and the decision recorded. New requirements may need a separate scope discussion.
