How to Give Good Website Feedback

Why Most Website Feedback Fails

You've been there. A client emails you: "The site feels off. Can you fix it?" You stare at the message, wondering which of the 47 pages they're talking about, what "off" means, and whether it's a layout problem. According to the Nielsen Norman Group, specific and actionable feedback is the cornerstone of effective design iteration, a colour choice, or something else entirely.

Vague feedback is the single largest source of wasted time in web projects. A 2023 survey of freelance developers found that over 60% of revision cycles stem from unclear client communication, not from actual mistakes in the build. The fix isn't to ask clients to "be more specific" — it's to give them a framework for specificity.

This guide breaks down exactly how to give website feedback that developers can act on immediately, whether you're a client reviewing a staging site, a project manager coordinating a launch, or a designer handing off notes to an engineering team.

1. Always Reference a Specific Page and Section

The most common feedback mistake is talking about "the website" as a single thing. A modern site might have dozens of pages, each with distinct sections. When you say "the header looks wrong," a developer has to guess which page you mean — and they will often guess wrong.

What to do instead

• Tools like givefeedback.dev automatically capture the current page — but you still need to name the specific component or section you mean
• Say "the hero banner," "the pricing table," or "the footer newsletter signup" rather than just "the top" or "that bit on the right"
• If you're unsure what a section is called, describe its position: "the three-column area roughly halfway down the page"

Example of unhelpful feedback

"The images are too big."

Example of actionable feedback

"On the /services page, the team photo grid below the intro paragraph — each image is taking up the full width on mobile instead of showing two per row."

The difference is night and day. The second version tells the developer exactly where to look, what device to test on, and what the expected behaviour should be.

2. Describe the Problem and the Expected Outcome Separately

Good feedback contains two parts: what you see now (the problem) and what you expected to see (the desired state). Many reviewers only communicate one half, leaving the developer to infer the rest.

Structure your feedback like this

• What I see: "The 'Contact Us' button on the pricing page is the same grey as the background, so it's almost invisible."
• What I expected: "The button should stand out — maybe the same purple used on the home page CTA."

This pattern works for everything from visual design to functionality. It eliminates ambiguity because the developer can verify both the current state and the target state without a follow-up conversation.

When you're reviewing a staging site, resist the urge to combine multiple issues into one comment. Each observation should be its own note. A single feedback thread that says "the colours are wrong, the form doesn't work, and the text is too small" forces a developer to parse, separate, and prioritise three unrelated issues from one message.

3. Be Precise About Visual Issues

Visual feedback is where specificity matters most, and where most reviewers fall short. "It doesn't look right" is not a visual note — it's a feeling. Developers need concrete details to make pixel-level corrections.

Spacing and layout

• Describe which elements are too close together or too far apart
• Reference a direction: "There's too much space between the headline and the subheading" is far better than "the spacing is off"
• If possible, note the approximate amount: "roughly double the gap that's on the About page"

Colour and typography

• Use words like lighter, darker, bolder, thinner, or compare to another element on the site: "This heading should match the weight of the one on the home page"
• If you have specific hex codes or brand guidelines, include them
• Note whether the issue appears in light mode, dark mode, or both

Alignment

• Specify what should align with what: "The left edge of the body text should line up with the left edge of the heading above it"
• Mention the breakpoint if it only occurs at certain screen sizes: "On tablet (roughly iPad-width), the card grid breaks into a single column too early"

Images and media

• Note whether the image is too large in file size (slow to load) or too large visually (takes up too much space)
• If an image appears blurry, mention the device and screen you're viewing it on — it may be a resolution issue specific to high-density displays

4. Record the Steps That Reveal the Problem

Many issues only appear during interaction. A button that doesn't work, a form that shows the wrong error, or a hover state that flickers — these all require context about what you did to encounter the problem.

What to include

• What you clicked or tapped before the issue appeared
• What you typed into any form fields (use fake data, but note the format — e.g., "I entered a UK phone number with a +44 prefix")
• Whether the issue is consistent or intermittent
• Your browser and device: "Chrome on Windows 11" or "Safari on iPhone 15"

Interaction issues are where voice-based feedback tools have a major advantage over written notes. When you narrate your experience while navigating, you naturally capture the sequence of actions, the timing, and the emotional reaction — all of which help a developer reproduce and understand the bug.

5. Separate Opinions From Issues

There's an important difference between a bug and a preference. Both are valid, but developers need to know which category your feedback falls into so they can prioritise correctly.

An issue is something objectively wrong

• A link that goes to a 404 page
• Text that's cut off on certain screen sizes
• A form that accepts invalid email addresses
• Content that doesn't match the approved copy

A preference is a subjective reaction

• "I'd prefer the font to feel more modern"
• "The animation is a bit too fast for my taste"
• "Could we try a warmer colour palette?"

Both kinds of feedback are useful, but labelling them differently helps teams triage. Issues need to be fixed before launch — our website QA checklist can help you catch them systematically. Preferences can be discussed, iterated on, and sometimes deferred to a future phase.

A simple convention like starting preference-based feedback with "Suggestion:" or "Nice-to-have:" goes a long way.

6. Use Screenshots and Annotations — or Better, Screen Recordings

A screenshot with a red circle around the problem area is worth paragraphs of description. It eliminates the "which element do you mean?" back-and-forth entirely.

But static screenshots have limits. They can't show:

• How a page behaves during scrolling
• What happens when you interact with a menu or form
• Performance issues like slow loading or janky animations
• The sequence of steps that lead to a bug

This is where screen recordings shine. For a comparison of voice and text-based approaches, see our voice vs. text feedback guide. A 30-second video of you navigating the page while explaining the issue out loud gives a developer everything they need: the visual context, the interaction flow, and your spoken commentary about what feels wrong.

Tools like givefeedback.dev take this a step further by capturing your voice, your clicks, and your scroll behaviour in a single session — then using AI to extract specific, timestamped tasks from the recording. The developer gets a replay of exactly what you saw, along with structured action items they can work from immediately.

7. Prioritise Your Feedback

If you're reviewing a full site and have fifteen things to flag, resist the urge to send them in a single unordered list. Instead, group and rank them:

1. Blockers — things that prevent the site from functioning (broken links, crashed pages, data loss)
2. Must-fix before launch — issues that affect usability or brand perception (layout breaks, wrong content, accessibility failures)
3. Should-fix — noticeable polish items (minor spacing, animation tweaks)
4. Nice-to-have — preferences and enhancements for a future iteration

This prioritisation tells the development team where to spend their time first, which is especially critical when working against a deadline.

Putting It All Together

Great website feedback follows a simple pattern:

1. Where: the specific page URL and section
2. What: the current behaviour or appearance
3. Expected: the desired behaviour or appearance
4. How: the steps to reproduce (for interaction issues)
5. Priority: whether it's a blocker, a bug, or a suggestion

You don't need a template or a project management tool to follow this structure — though they help. What matters is the habit of pausing before you hit send and asking yourself: "If I were the developer reading this, would I know exactly what to do?"

If the answer is yes, you've just saved both of you a round trip. And in a world where revision cycles eat up more budget than the build itself, that specificity is the most valuable thing you can contribute to the project. Ready to streamline your feedback workflow? Try givefeedback.dev free — or read about how to reduce revision cycles next.