Website feedback examples: turn vague comments into useful requests

“The page feels off” might be an honest reaction. It just leaves the person receiving it with a second job: working out what you mean.

Useful feedback gives that reaction a location, an explanation and a desired outcome. You don't need design vocabulary or a finished solution. You need enough context for the team to investigate the right thing.

The six examples below are illustrative, rather than reports from customer projects. Use them to make your next review easier to act on.

A feedback formula you can copy

On [page and location], when [device, action or situation], I notice [specific observation]. This matters because [effect on the visitor or agreed goal]. The outcome we need is [expected result]. [Evidence or question, if helpful.]

You won't need every field for every comment. A spelling correction can be short. A checkout problem needs the steps that led to it. The goal is to remove uncertainty, rather than fill in a form for its own sake.

1. Copy: explain what the visitor needs to understand

Before: “Can we make the headline punchier?”

After: “On the services page, the heading ‘A better way forward’ doesn't tell a first-time visitor what we provide. Could the heading explain that we design and build websites for independent retailers? The goal is for someone arriving from search to understand the service without reading the whole page.”

The first comment describes a style preference. The second names the missing information and the audience who needs it. A writer can now propose alternatives against a clear brief.

If you have suggested wording, add it as a suggestion. Distinguish approved facts from possible phrasing: “The service description is correct; the exact wording is open for discussion.”

2. Mobile: include the device and the action

Before: “The mobile version is broken.”

After: “On the contact page in Safari on my iPhone, the cookie banner covers the Send button. I can complete the fields, but I can't see how to submit while the banner is open. Please make the form action reachable in that state. I've attached a screenshot showing the overlap.”

This comment identifies the page, browser, visible problem and expected result. It also describes a state that might disappear after someone dismisses the banner.

Include your device model or viewport size if you know it. If you don't, say what you do know. Avoid guessing at the cause: the developer can investigate whether the issue comes from spacing, positioning or something else.

3. Navigation: connect a label to an actual task

Before: “The menu is confusing.”

After: “From the homepage, I tried to find our maintenance service. I opened ‘Solutions’, then ‘Support’, but neither label made the route clear to me. Can we make website maintenance discoverable from the main navigation? The intended visitor is an existing site owner looking for ongoing help.”

The revised comment gives the team a task to examine. It doesn't assume that adding another menu item is the only answer.

When possible, describe the route you attempted before explaining the change you want. That helps distinguish a wording problem from a missing destination.

4. Visual hierarchy: name the competing elements

Before: “Make the button pop.”

After: “In the homepage introduction, the newsletter signup draws my attention before the project enquiry button. For this page, project enquiries are the agreed priority. Could we give that action greater visual emphasis and make the newsletter secondary?”

This makes the design decision about a shared objective. It leaves room to adjust placement, contrast, size or surrounding content.

If the priority hasn't been agreed, turn the comment into a question first. Two reviewers can reasonably prefer different layouts when they're optimising for different outcomes.

5. Forms: describe expected and actual behaviour

Before: “Fix the form errors.”

After: “On the enquiry form, I left the email field empty and selected Send. The page displayed ‘Something went wrong’ above the form, but didn't identify the missing field. I expected a message beside Email explaining what to enter, with the other completed fields preserved.”

The recipient can reproduce this without asking which field or submission you meant. The expected result also describes the visitor's recovery path.

Use fictional test details when sharing evidence. Crop or redact personal information in screenshots, and avoid including a real customer's submission in a general review thread.

6. Conflicting feedback: surface the decision

Before: “Ignore the earlier comment. We need all the services above the fold.”

After: “There are two requests on the homepage: keep the introduction focused on one service, and show the full service range immediately. These support different priorities. Could the project owner confirm whether the main audience is new visitors choosing a service or visitors arriving for our flagship offer? We can then assess the layout against that decision.”

This stops a disagreement from becoming an unexplained design instruction. Record who owns the decision, the chosen priority and which earlier comments it resolves.

Before you send the review

Read each comment once from the recipient's perspective. Can they locate the issue? Can they understand what you observed? Is the requested outcome clear? Keep separate issues in separate comments so each can be discussed and resolved independently.

For a broader review, use the website review checklist. To organise the invitation, review round and final decisions, follow our client website review guide.

Clear feedback doesn't remove discussion. It gives the discussion somewhere useful to start.