How to give website feedback that actually gets done

Most website feedback fails for one reason: the reviewer and the builder are looking at two different things. The reviewer sees a screenshot or a vague note in a doc; the developer has to reverse-engineer which element, on which page, at which breakpoint, in which state the comment refers to — then hope they guessed right. Multiply that by 40 comments across Slack, email, and a spreadsheet, and half of them get misread or lost.

Good feedback isn't about being nicer or more detailed. It's about removing ambiguity. This guide breaks down exactly how to do that: the anatomy of a comment that gets actioned, seven concrete rules with before/after examples, and a checklist you can paste into your review process today.

Why most website feedback breaks down

Before fixing it, it helps to see the specific failure points. Nearly every "feedback got lost" story traces back to one of these:

• No anchor — a comment like "the button feels off" isn't tied to a specific element, so the developer guesses.
• No outcome — the comment names a problem but not the desired result, so the fix is a coin flip.
• Scattered channels — feedback lives in Slack, email, Figma, and a doc, so nothing is the single source of truth.
• No state context — "the menu is broken" — on mobile? when logged in? after scrolling? Missing context means missing repros.
• No status — once a note is written, nobody can tell if it's fixed, in progress, or forgotten, so items quietly reopen after launch.

The anatomy of a comment that gets done

A great piece of feedback answers four questions before the developer has to ask them: where, what, why, and how important. Here's the structure:

• 1WHERE — the exact element and page. The single biggest time-saver. Point at it instead of describing it.
• 2WHAT — the specific change, not a vibe. "Increase to 18px" beats "make it bigger".
• 3WHY (optional but powerful) — the intent. "So it reads as the primary action" helps the developer make the right call if your exact spec isn't feasible.
• 4PRIORITY — is this a blocker, a polish item, or a nice-to-have? This lets the team triage instead of treating everything as equally urgent.

7 rules for feedback that ships

1. Point, don't describe

The fastest feedback is the kind you can point at. Instead of writing "the CTA near the top", click the element directly on the live page and leave the comment there. The note stays anchored to that exact spot — there's nothing to find and nothing to guess.

2. One element, one comment

Bundling five issues into one paragraph guarantees some get missed. Split them. One comment per element keeps each item independently trackable — and resolvable.

3. Say the outcome, not just the problem

Naming the problem leaves the fix ambiguous. Name the result you want.

4. Be specific with numbers and references

Vague adjectives ("more spacing", "a bit darker") invite a second round of feedback. Use concrete values or a reference the team already shares.

5. Show, don't type, for anything complex

If you're explaining a flow, a bug, or an interaction, a 20-second screen recording with your voice beats three paragraphs that still get misread. Record the steps, narrate what you expected versus what happened.

6. Always include state and device

A huge share of "I can't reproduce this" comes from missing context. Note the device (desktop/mobile), the state (logged in, empty form, after submitting), and the breakpoint. Reviewing on the actual responsive frames removes this entirely.

7. Make every comment trackable to done

Feedback isn't finished when it's written — it's finished when it's shipped. Every comment should map to a task with a status (Open → In progress → Resolved) so reviewers can see progress and nothing reopens after launch.

The goal isn't more detailed feedback. It's feedback with zero ambiguity — as precise as pointing at the screen.

The copy-paste feedback checklist

Share this with your team and clients. Before submitting a comment, check:

• Is it pinned to the exact element (not described in words)?
• Does it state the outcome I want, with specific values?
• Is it one issue, not five bundled together?
• Did I note the device and state if relevant?
• For anything complex, did I record it instead of typing?
• Will it become a tracked task with a status?

How UX Peeker removes the ambiguity

UX Peeker is built around this exact framework. You click any element on the live site or web app and the comment anchors to that spot. You can record your screen and voice for complex items, switch between desktop/tablet/phone frames to capture state, and every comment automatically becomes a tracked task. Clients can review through a no-login portal — so the people giving feedback and the people building it are finally looking at the same thing.