How to Collect Actionable Client Feedback on a Website Design

“Make it feel more modern” is a real reaction, but it is not yet a useful design instruction. It does not say which page is causing trouble, what a visitor is trying to do, or what should improve. Good web design client feedback starts with those details. It gives the client a clear way to review the work and gives the design team enough evidence to decide what to change.

Set the review goal before sharing the design

Send the review goal with the design, not after the first round of comments. State which pages and decisions are open for feedback. Then name the visitor tasks the design should support. For a service website, those might be understanding the offer, finding evidence that the service is relevant, and locating the enquiry route. For an online shop, they might be comparing products and understanding the next step before purchase.

Keep the task list short enough for a reviewer to use. “Review the website” invites comments on everything at once. “On the service page, can a first-time visitor tell who this is for and find the next step?” gives the client something observable to assess. The Nielsen Norman Group’s critique guide recommends defining the scope in advance and relating feedback to a persona, scenario, use case, or goal. That is a useful standard for a client review, even when the client is reviewing alone rather than in a meeting.

Tell reviewers what they are looking at: an early direction, a revised page, or a version awaiting approval. Mark unfinished copy and interactions plainly. If a mobile view is ready but a particular interaction is still being worked through, say so. This prevents a placeholder from becoming a lengthy debate and helps the client focus on decisions that can be made now.

Ask clients to follow tasks, not just inspect screens

A screenshot is easy to react to as a composition. A website also has to help someone move from a question to an answer. Give reviewers a few prompts that follow that journey: “Where would you go to compare these options?” “What would you expect to happen after selecting this button?” “Which sentence tells you whether this service fits your situation?” Ask them to note where they hesitated, what they expected, and what they found instead.

Include the page and viewport in the review instructions. A comment about a crowded navigation needs to say whether it appeared on a narrow phone screen or a wide desktop view. If the design is interactive, ask reviewers to use the shared version and report the step where the issue occurred. If they are reviewing static screens, ask them to describe the expected next step without treating an unbuilt interaction as a defect.

Review the words as carefully as the layout. Can a visitor understand a heading without reading the paragraph beneath it? Does a button describe the action it starts? Is a link meaningful out of context? The GOV.UK guidance on writing for user interfaces calls for short, direct copy, descriptive headings, and link text whose purpose is clear when read on its own. Those principles turn “the copy feels unclear” into questions a reviewer can answer on the page.

Give every comment the same small form

Clients should not need specialist design vocabulary to give useful feedback. A short, repeatable form captures the context a designer needs without asking the client to diagnose the solution:

Page: Which page, section, or step were you reviewing?
Viewport: Were you using a phone, tablet, or desktop view? Include the approximate width or device if it matters.
Observed issue: What did you see, read, or try to do?
User impact: What might a visitor misunderstand or be unable to complete?
Proposed priority: Does this block the review goal, make a task harder, or simply merit consideration? Say why.

A screenshot or precise location can help, but it should support the description rather than replace it. “Button is wrong” leaves the team guessing. “On the phone view of the service page, I reached the end without seeing how to enquire; a new visitor may think there is no next step; proposed priority: high” points to an issue the team can assess. The client may suggest adding a button, but the observation and impact remain useful even if the best solution turns out to be different.

Use a client review script

A simple script keeps a live review focused and also works as instructions for an asynchronous review. Adapt the page names and tasks to the project:

Open with the goal. “In this session we are reviewing whether a first-time visitor can understand the service, decide whether it is relevant, and find how to enquire. We will review the home and service pages on desktop and phone.”
Set the status. “This version is ready for feedback on content, hierarchy, and the main route through the pages. Items marked as placeholders are still in progress.”
Walk through a task. “Imagine you have arrived from a search result and know little about the business. What would you read first? Where would you go next?” Let the reviewer answer before explaining the design.
Probe a reaction. If the client says, “This section feels busy,” ask, “Which choice becomes harder to make?” If they request a larger heading, ask what information the heading needs to make easier to find.
Capture the issue. Record the page, viewport, observation, likely visitor impact, and proposed priority. Repeat the concern back to check that the log reflects what the client meant.
Close with decisions. Confirm which comments need a change, which need investigation, and which are preferences to consider against the review goal. Name who will decide each open item.

Keep an issue log that leads to decisions

Put feedback in one shared issue log rather than leaving it across emails, comments, and meeting notes. Give each issue an identifier and preserve the client’s original observation. Add the team’s assessment beside it, so a later design decision does not quietly overwrite what was raised.

For each issue, record the page and viewport, the related visitor task, the observation, the proposed priority, an owner, and a status. Useful statuses include open, needs clarification, accepted, deferred, and declined. Add a short reason when an issue is deferred or declined. This makes it possible to disagree with a suggested solution while still acknowledging the underlying concern.

Consider a comment that the home page needs a longer introduction. The log might show that the client is worried visitors will not understand the range of services. The team may accept that concern but decide to make the service choices clearer rather than add a paragraph. Recording both the concern and the decision prevents the next review from reopening the same conversation as though it had never happened.

Close the loop with one acceptance check per change

Once the team has reviewed the log, send the client a concise decision record. For every issue, state what was heard, what will happen, why, and what remains open. The Nielsen Norman Group’s guidance on following up after a critique recommends explaining both what changed and what did not, including the reasons. A new design version alone cannot tell a reviewer whether their concern was resolved or merely moved.

Give each accepted change one acceptance check tied to the original issue. If the concern was that phone visitors could not find the enquiry route, the check might be: “On the phone view, a reviewer can locate the enquiry action from the service page without returning to the home page.” If the concern was unclear wording, the check might ask the reviewer to identify who the service is for from the heading and opening copy.

Before asking for approval, share the updated design with the decision log and the acceptance checks. Identify any unresolved items and the person responsible for deciding them. Ask the client to confirm the agreed design decisions, not to approve an undefined collection of screens. That gives both sides a clear stopping point: the important visitor tasks have been reviewed, the feedback has a recorded outcome, and accepted changes have been checked. The design can then move to development handoff with its client decisions settled.