Blog Post

How to Give Website Feedback That Actually Gets Fixed

Most website feedback never gets acted on. Not because developers ignore it — because it lacks the context they need. Learn how to give feedback for websites that includes screenshots, element details, and technical context so issues get fixed the first time.

Why Most Website Feedback Gets Ignored

Here is how most website feedback looks in practice: a Slack message that says "the button looks weird on mobile," a screenshot of half the page with no annotation, or a comment in a Google Doc referencing "that section near the top." Developers receive this feedback, squint at it, and then spend 20 minutes trying to reproduce what the reporter saw. Half the time they cannot. The issue sits unresolved for days. This is not a people problem. It is a format problem. Website feedback fails when it lacks specificity — the exact element, the browser, the viewport, the CSS values, what it should look like versus what it actually looks like.

What Good Website Feedback Includes

Every piece of website feedback that gets fixed shares the same six traits: a screenshot of the specific element, the exact URL and browser environment, a description of what is wrong versus what was expected, the CSS or styling values that are incorrect, the severity level, and steps to reproduce. When feedback for websites includes these details, developers skip the investigation phase entirely and go straight to fixing. The difference between "this looks off" and "the CTA button has 8px padding instead of 12px on Chrome 120 at 1440px" is the difference between a bug that sits in the backlog and one that gets resolved in the next sprint.

Five Types of Website Feedback

Not all website feedback is the same. Categorizing feedback before reporting helps teams prioritize and route issues to the right person.

• Visual and design feedback — Spacing, typography, color, and layout issues. Caught by comparing the live site against the design spec.
• Functional feedback — Broken interactions, failed form submissions, dead links. Requires steps to reproduce.
• Content feedback — Typos, outdated copy, missing images, incorrect data.
• Performance feedback — Slow page loads, janky scrolling, delayed interactions.
• Accessibility feedback — Missing alt text, poor contrast, keyboard navigation failures, missing ARIA labels.

Visual and design feedback is the hardest to communicate because it requires technical specifics. Telling a developer "the spacing is wrong" is not actionable. Telling them "padding-top is 16px, spec says 24px, on the hero section CTA" gives them everything they need.

How to Give Feedback at Each Stage

Design review stage

During design review in Figma, feedback is contextual — both parties see the same file. Leave comments anchored to specific frames and include the intended values for any properties you reference.

Staging and pre-launch

Staging is where most website feedback should happen. Compare the live build against the design spec. Capture element-level details: padding, margin, font size, color values. Use a website feedback tool that extracts CSS automatically so developers do not have to inspect elements themselves.

Production

Production feedback for websites needs urgency context. Include the severity, the user impact, and whether the issue is a regression. Attach browser and viewport details since production bugs are often environment-specific.

Website Feedback Tools Compared

The right website feedback tool depends on what type of feedback you are collecting and who is giving it.

• General user feedback tools (Hotjar, FullStory) — Collect heatmaps, session recordings, and user surveys. Best for understanding user behavior, not for reporting specific UI issues.
• Visual bug reporting tools (BugHerd, Usersnap) — Let users pin comments on live pages and capture screenshots. Good for client feedback on marketing sites.
• Design QA tools (OverlayQA, BugHerd) — Built specifically for comparing implementations against design specs. Captures CSS values, element metadata, and screenshots automatically. Exports structured issues to Jira or Linear with full technical context. Best for product teams doing systematic design QA on staging and production.

If your team gives feedback for websites regularly — not just one-off client reviews but ongoing QA as part of every sprint — you need a tool that captures technical context automatically. Manual screenshots and Slack threads do not scale.

The Website Feedback Template

Use this template every time you report a visual issue on a website. It works whether you paste it into Jira, Linear, Slack, or an email.

• URL: the exact page where the issue appears
• Element: which element is affected (button, heading, card, image)
• What is wrong: describe the discrepancy in one sentence
• Expected: what the element should look like (reference the design spec)
• Actual values: the CSS values you see (padding, color, font-size)
• Screenshot: annotated screenshot showing the specific element
• Environment: browser, viewport width, operating system
• Severity: critical, high, medium, or low