Website design feedback from clients works when the client knows in advance how many review rounds there are, who collects comments and by when. Without that agreement, comments arrive by email, in chat and in call notes, often contradicting each other and spread over weeks. The team changes one element three times and nobody can say whether the round is over.
This guide follows one round from the rules to the close: how to collect comments, how to turn them into tasks with decisions and how to record approval. It does not replace your contract or the task acceptance criteria you should agree earlier. The examples involve a fictional studio designing a site for a fictional language school.
Set the round rules before the client sees the design
A review round is one closed cycle: the client reviews a defined stage, sends a complete set of comments, the team assesses them and implements the accepted ones, and the client confirms the result. Agree the number of rounds before you show the first version, not after the third email. Two rounds per stage is only an example, not an industry norm; both sides simply need to know the limit and what happens after it.
Scroll the table sideways to see all columns.
| Rule | Example agreement | Why it helps |
|---|---|---|
| Number of rounds | Two rounds on the visual design, one on the built version | The client knows to gather everything at once |
| Feedback owner | The school manager sends a single list | The client resolves conflicting comments, not the team |
| Feedback deadline | Five working days after the version is shared | The round does not run forever |
| Review scope | Home page and course page | Comments relate to the stage shown |
| Extra round | A separate decision with its impact recorded | No argument about one more small change |
The values in the table are an example, not a recommendation. Binding terms, such as how extra rounds are billed, belong in your contract; this text is not legal advice.
One person on the client side collects and reconciles feedback
When five people send comments, the team has to guess which version counts. The school owner wants a bigger logo, a teacher asks for a smaller one and marketing questions the whole headline. Ask the client to name one person who gathers opinions internally, settles conflicts and sends one list. Others comment to that person, not to the designers.
"We have shared the design for the home page and the course page. This is the first of two agreed rounds. Please send one list of comments from Anna by Friday. For each comment, name the page, the element and the change you expect. If your team disagrees on something, please settle it before sending the list."
A comment that arrives after the deadline or through another channel is not lost. Log it and reply that it will go into the next round unless it blocks current work.
Every comment names the page, the element and the expected change
"I don't like the top of the page" cannot be implemented or assessed. The same thought becomes useful once it has three parts: where, what it concerns and what the result should be. "Home page, headline above the photo: we want it to mention corporate courses straight away" lets the designer propose a solution without another email exchange. If the client knows the reason, ask for it; the reason often points to a better change than the one requested.
One comment means one change. Split a paragraph with four requests into four items, because each may get a different decision. A marked-up screenshot helps, but it does not replace a description of the expected result. If a comment is unclear, ask one specific question.
Turn the list into tasks with an owner and a decision
The client's list is input, not a work plan. Before anyone opens the design file, work through it in a few steps. Each comment should end up as one task with a responsible person and a recorded decision.
- Receive the full set.Confirm that the list arrived and note the date feedback collection closed. From then on, new requests wait for the next round.
- Split and name.Record each change separately with the page and element in the title, for example "Courses: price table, dates column".
- Assign an owner.Name one person who assesses and makes the change. Shared responsibility tends to mean nobody does it.
- Record the decision.Accepted, rejected with a reason, or needs clarification with a question for the client. Without a decision the task does not enter production.
- Reply in one message.Send the client a summary of decisions before work starts.
"We are not reducing the menu font size, because it would become unreadable on phones; we suggest shorter labels instead" is a decision with a reason and an alternative.
Separate revisions from new requirements before work starts
A revision brings the stage you showed in line with the agreed result. A request for a new sign-up form, another language version or an extra page is a new requirement, even if it sits on the same list. Flag it separately when you assess the list, not halfway through implementation. How to describe its impact and record a decision is covered in the guide to handling a client's change to the project scope.
On the built version you will also face the question of whether something is a defect or a new capability. That classification has its own guide on telling a bug from a feature request. Within a round, it is enough that such items do not enter production without a decision.
The revisions policy of Grumo Media, an animated explainer video studio, moves to the next stage only after written approval of the current one and bills changes to an approved stage separately. This is one video company's policy, not a website standard or contract template: Grumo Media, Revisions Policy.
Close the round in writing and count extra rounds
Once the accepted changes are in, ask the feedback owner to confirm that the round is closed. The confirmation covers the list from this round, not the whole website. Signing off the finished site before launch is a separate step, described in the guide to a website acceptance checklist.
"We have implemented 11 of the 13 comments from the first round. We rejected two for the reasons given in the summary of 14 October. Please confirm that the round is closed. We will take further comments in the second and final agreed round."
If the client wants another round after the limit is used, record it as an extra round with its date, scope and billing decision.
The round list in Meetlead Projects
In Meetlead Projects each comment can be a task with an owner, priority, status and comments where you record the decision. You can run a round as a sprint: a site has one active sprint, and when you close it you move open tasks to the backlog or the next sprint. If a comment came in through a ticket, link the ticket to the task, as described in the guide on going from ticket to task.
Projects has no screenshot annotation tool and no portal where the client approves a round themselves. Send the decision summary through the agreed channel and note the outcome on the task. You need an account, a site with the Projects app installed and a plan that includes access.
- The number of rounds, the deadline and the feedback owner are agreed before the first review.
- Every comment names the page, the element and the expected change.
- One comment is one task with an owner.
- Every task has a decision: accepted, rejected or needs clarification.
- New requirements are flagged before work starts.
- The round closure and any extra round are recorded.
Marker.io recommends one place where all feedback is logged and keeping each discussion tied to a single issue. The guide comes from a vendor of feedback tools and does not prove that any particular number of rounds works best: Marker.io, website design feedback.
Questions about review rounds
What if the client sends comments in bits and pieces? Acknowledge each message in one sentence, but assess the full set only after the deadline. If a single comment blocks work, for example an approved text is missing, handle it separately and say why.
Does fixing the designer's own mistake use up a round? Usually it should not. If a version does not meet what was already agreed, bringing it in line is part of your work, not client feedback. Agree this at the start.
