How to Give Website Feedback a Team Can Act On

Separate the observation, interpretation, and suggestion

These are three different things. An observation is what you saw: the page shows an error after submission. An interpretation is what you think it means: visitors may believe their request failed. A suggestion is one possible response: show a confirmation state and preserve the submitted details. Keep them distinct so a teammate can check the evidence before committing to a solution.

This distinction is especially useful when reviewers have different levels of product knowledge. A developer may know that a request succeeded even though the interface showed an error. The underlying problem is still real, but the correction might be clearer status messaging rather than changing the request itself.

Rewrite a vague comment using a concrete scenario

Imagine reviewing a fictional appointment form on a phone. A comment like ‘The booking flow is bad’ gives no reproducible starting point. A more useful note would be: ‘On the appointment request page at a narrow viewport, after I choose Saturday and submit without entering an email address, the error appears at the top of the form. I did not see which field needed attention until I scrolled back. I expected the email field to be identified near the error. This makes it harder to correct the request.’

That note names the page, state, action, observed result, expectation, and consequence. It does not claim that all visitors will fail or dictate the implementation. The scenario is illustrative; replace it with what you actually observed in your own review.

Include the context that changes the result

A useful report gives another person a way to see the same problem. Add only the details that matter to reproduction: the exact URL or page, viewport or device, account state, test data, prior actions, and whether the issue repeats. If the page contains private information, redact the capture before sharing it.

• Use a short screen recording when timing or movement matters; use a screenshot when the issue is static.
• Point to the affected control or text, rather than attaching a full-page capture with no explanation.
• Say whether the issue is consistent or happened once; do not turn one observation into a frequency claim.
• Include the exact wording of an error when the wording itself is the problem.

Describe impact without pretending to know more than you do

Connect the issue to a user task: it blocks completion, makes the next step hard to find, increases the chance of an incorrect entry, or adds an unnecessary step. If you did not observe a user or review analytics, phrase the impact as a risk or hypothesis and say what evidence would confirm it.

Avoid statements such as ‘everyone will miss this’ unless you have evidence from a representative study. ‘I could not find the action in this pass’ is a truthful observation. ‘In four moderated sessions, three participants overlooked it’ is a finding with scope. The wording should match the evidence.

A reusable feedback note

Page/state: [where and in what state]. Starting point: [what was already selected or entered]. Action: [what I did]. Observed: [what happened]. Expected: [what I thought would happen]. Impact: [which task became harder or impossible]. Evidence: [capture, link, or steps]. Possible fix: [optional, clearly labeled as a suggestion].

After the team changes the page, repeat the same action and check the original expectation. A closed comment is not proof that the experience improved; the task is the thing to recheck.