Website feedback

A survey is prompted: the team writes the question, decides who sees it and when, and receives structured answers it can count. Website feedback is unprompted: the reporter decides what to raise and where, and the answer is a description of a problem on a specific page. Surveys measure how people feel; feedback tells the team what is broken.

Three groups, with different needs. Internal reviewers and testers before launch, who need to be precise and fast. Clients and stakeholders during review, who need to point at things without knowing the vocabulary. Visitors after launch, who report a problem only if doing so costs less than leaving. One collection point serves all three if it asks for nothing the browser already knows.

A bug report is one kind of website feedback: a claim that the site behaves differently from how it was built to behave, with steps to reproduce and the browser it happened in. Website feedback also covers what is not a defect in the code, such as an outdated hero image or a policy page that contradicts the checkout, and those go to a content owner or a designer rather than to a developer.

On the page where the problem is, through a control that lets the reporter mark the spot and describe it, and that records the URL, viewport, browser and any console errors on the reporter's behalf. Before launch the control is a review link shared with clients and testers; after launch it is a visible button for visitors. Email, chat and shared documents collect feedback too, at the cost of a reply asking where and on what.

The page it concerns, the spot on the page, what the reporter expected and what they saw, and the conditions: browser, device, viewport and the time. A reporter should have to supply only the expectation and the observation; the rest is known to the browser and is best captured for them, since a reporter asked for their user agent string sends nothing at all.