Website feedback without the endless email thread

"The thing at the top looks weird on my phone" is not a bug report, but it is what most website feedback looks like. You can fix the process instead of decoding every email.

By the VeoRec team · Oct 3, 2026 · 11 min read

Every web project reaches the review stage, and every review stage produces the same email. It has a subject like "Few thoughts!!", eleven bullet points, two screenshots cropped so tightly you cannot tell which page they are from, and a line that says "also the menu thing from Tuesday". Then a colleague of the sender replies-all with three contradicting notes. Collecting website feedback this way is slow for everyone and fragile: notes get lost, fixed twice or argued about long after they should have closed.

A better inbox will not save you. What works is a process with four parts: one place for notes, notes attached to the thing they are about, enough context to reproduce what the reviewer saw, and a visible status for every note. It holds for an agency chasing a client's sign-off and for an in-house team reviewing its own pricing page.

Why website feedback turns into a thread

Websites are harder to give feedback on than most design work, for reasons that are not anyone's fault.

• Location is ambiguous. "The banner" could be on any of forty pages, and "at the top" depends on how far you scrolled.
• Everyone sees a different site. A different screen width, browser, zoom level, logged-in state or cached version can show a different layout.
• Pages move. Interactions, hover menus, forms and animations cannot be shown in a screenshot.
• Many reviewers, no owner. Marketing, legal, the founder and the client's sales lead each review separately and nobody consolidates.
• No status. Email has no "done". Nobody knows which of the eleven bullets were fixed, which were declined and which were missed.

Each point below removes one of those problems. You will not need all of them for a five-page brochure site, but the bigger the site and the more reviewers, the more each one pays back.

Decide what kind of feedback you want, and when

Asking for "any feedback on the site" in one go invites everything at once: typos next to strategy next to a broken form. Split the review into rounds with a clear focus, and tell reviewers what is in scope this time.

Rounds do not have to be long. What matters is that each one has a start, a deadline and a scope. "Please review the design of the home, pricing and contact pages on desktop and your phone by Thursday; copy is still placeholder" is a request people can respond to well. Our post on a client feedback process covers rounds and sign-off for agency work in more detail.

Be clear about which version people are reviewing. A staging site, a preview link and the live site can all differ by a day of work, and a note left on the wrong one wastes time on both sides. Put the exact URL in the request, say whether the content is real, and if the site needs a password, send it separately from the review link. For a redesign of a live site, tell reviewers not to comment on the current live pages unless you have asked them to.

Do your own pass before anyone else looks

A surprising amount of client feedback is about things the team could have caught: a broken link, a lorem ipsum paragraph, a form that sends to nobody. Each one costs the reviewer's attention and your credibility, and it crowds out the feedback you actually need. Spend half an hour on your own pass before you send the review link.

• Click every link in the navigation and the footer, and every button on the pages in scope.
• Submit every form, with valid and invalid data, and check the submission arrives where it should.
• Look at each page at phone width and at a common laptop width, and scroll to the bottom.
• Search the pages for placeholder text, test prices and "TODO".
• Open the site logged out, in a private window, so you see what a new visitor sees.
• Check that images load at a sensible size and that nothing obvious is slow.

Fix what you find, then send the link. The reviewers' notes will be about the design and the content, which is what you asked them for, instead of about things you already knew were unfinished.

Choose one place for every note

This is the single highest-value change. Pick one place where all website feedback lives for the project and say so in every review request. It might be a feedback tool, a review link on a recording, a shared board or your issue tracker. Which tool matters less than the fact that there is only one.

Then hold the line, politely. When a note arrives by email or chat, copy it into the shared place yourself and reply with the link: "Added this here so it's tracked with the rest." After a round or two, most reviewers start using the shared place directly, because that is where they can see what happened to their notes.

When you pick the place, a few criteria matter more than feature lists. Can a reviewer leave a note without an account? Does the note keep its location on the page? Can people reply in a thread rather than starting new notes? Is there a clear open and resolved status? Can the developer get from a note to the exact page and state in one click? A spreadsheet fails most of these, which is why spreadsheets of feedback tend to go stale by the second round.

Pin each note to the element, not to a description

"The second button in the pricing section" requires interpretation. A note attached to the button does not. The best website feedback is attached directly to the element it refers to, so that whoever fixes it lands on exactly the right spot.

There is a subtlety with responsive sites. A note pinned to a fixed position on a screenshot, say 60 percent across and 30 percent down, points at the right thing only at the width it was taken. Resize the window and the layout reflows, but the pin stays where it was, now pointing at something else. A note attached to the element itself follows it. Try switching the layout in the demo below to see the difference.

In VeoRec, when a web page is recorded as a Chrome tab, notes can stay attached to the page elements in exactly this way, and every comment also carries its time in the recording. For the many cases where a picture is enough, the screenshot tools capture the visible area, the full scrolling page or a selected area, which avoids the tightly cropped mystery screenshot.

Capture the context with every note

Much of the back-and-forth on website feedback is about reproduction: "I can't see it, what browser are you on?" Every note should carry enough context for someone else to see what the reviewer saw. Some feedback tools capture this automatically. If yours does not, ask for it in the review request.

• The page URL, including anything after a question mark or hash, which can change what is shown.
• The browser and its version. In Chrome, typing chrome://version in the address bar shows it.
• The device and screen width, or simply "laptop", "phone", "tablet" if the reviewer is not technical.
• The state: logged in or out, what was in the cart, which filter was on, which step of the form.
• When it happened, especially for anything intermittent, like a slow page or a form that failed once.

When you are reproducing a note on your own machine, the device toolbar in Chrome DevTools can approximate other screen sizes. Google's Device Mode documentation is clear that it is a first-order approximation rather than a real phone, so confirm anything device-specific on actual hardware before you mark it fixed.

Show interactions instead of describing them

A screenshot is perfect for static problems: a typo, a misaligned image, the wrong photo. It cannot show a menu that flickers on hover, a form that clears itself after an error, an animation that stutters, or a page that jumps as fonts load. For anything that moves or happens over time, a short screen recording with the reviewer's voice is far clearer than a paragraph.

Keep these recordings short and focused: one issue, or one page, per recording. Ask reviewers to say out loud what they expected and what happened, and to repeat the action once so the problem is visible twice. A recording made on the page itself gives the developer the exact sequence; the video bug reports post covers what to show in the first ten seconds.

One caution for recordings and screenshots of real sites: they capture whatever is on screen. If the reviewer is logged into an admin area, or the page shows real customer names, orders or email addresses, that ends up in the feedback too. Ask reviewers to use a test account where possible, and blur anything sensitive before the note is shared more widely. In VeoRec you can draw blur boxes over secrets in the editor and render to apply them.

Give reviewers a short brief

A lot of poor feedback starts with a poor request. A reviewer who knows what to look at, where to leave notes, what format helps and when the round closes will give you better notes than one who received "site's live on staging, let me know!"

If your reviewers are colleagues rather than clients, it is still worth sharing the note format. Our guide on how to give design feedback explains the reasoning: location, effect and a question beat a reaction every time.

Triage before you start fixing

When the round closes, resist fixing notes in the order they arrived. Read everything once, merge duplicates, and sort. A five-minute triage prevents the classic mistake of spending a morning on a colour tweak while the contact form is broken.

A round-two triage, worked through

Say round two of a dental clinic's site closes with nine notes from three reviewers. Read once, they sort quickly. The booking form sends to an old inbox, the Saturday opening hours are wrong, and a dentist's surname is misspelled: fix now, all before lunch. Two notes about the hero photo being too dark are one note, so merge them into a single fix. The practice manager wants the team page above the services page while the owner asked for services first in the brief: that goes to discuss, with the owner deciding. A request for an online shop is a new piece of work: later, flagged as a possible scope change. "Can the font be friendlier?" turns out, after one question, to mean the body text feels small on a phone, which is a real readability issue, so it moves to fix now. The last note asks for pale grey text on the footer, which would fail contrast: decline, with the reason.

Nine notes became five fixes, one decision for the owner, one later item and one decline with an explanation. Fixing them in arrival order would have started with the footer colour.

Conflicting notes are normal when several people review. The client's marketing lead wants the hero video bigger; their head of sales wants the pricing above the fold. Do not pick a winner silently. Put both notes side by side, explain the trade-off, and ask the person named as decision owner to choose. Then record the decision where both reviewers can see it.

Resolve notes where the reviewer can see it

Closing the loop is what makes reviewers trust the process. When a note is fixed, mark it resolved in the same place it was left, ideally with a one-line comment ("Fixed: message text is now kept after an error"). When a note is declined, say why. Silence teaches reviewers that the shared place is a black hole, and they will go back to email.

Resolved threads also make the next round easier. Reviewers can see at a glance what changed, and you can ask them to check only the resolved items rather than reviewing everything again. In VeoRec, threads on a recording can be marked resolved, and a folder review link lets a client see all the recordings for a project in one place, either view-only or with comments allowed.

End the last round with an explicit sign-off rather than a fading thread. List what was fixed, what was declined and why, and what moved to the post-launch list, then ask the decision owner to confirm in writing that the site can go live. It takes five minutes and prevents the "I thought we were still changing the header" conversation the day after launch.

Handle late, vague and out-of-scope notes

Even a good process gets some awkward feedback. Having a stock response for each keeps you consistent and saves arguments.

• Late notes. Thank them and add them to the next round, as you said in the brief. If something is genuinely urgent (the phone number is wrong), fix it; that is what judgment is for.
• Vague notes. Reply with one specific question rather than a guess: "Which page were you on, and was this on your phone or computer?" Guessing creates a second round of the same note.
• Out of scope. "Can we add a blog?" is not feedback on the current round. Log it on the later list and, for client work, flag it as a possible change to the scope rather than quietly absorbing it.
• Taste disguised as a bug. "The font is wrong" might mean it is broken or might mean they dislike it. Ask which before you change anything.

For agencies, these cases are where revision rounds multiply. The post on how to reduce revision rounds covers the commercial side: what to put in the contract and how to present work so fewer rounds are needed.

What to do next

Before your next website review, pick one place for notes and put the link in the review request. Use the brief template: what to review, what not to, how to leave notes, the deadline and who decides. When the round closes, triage into fix, discuss, later and decline, then resolve every note where the reviewer will see it. Two rounds run this way will usually convince even the most email-loyal client.

After launch, keep the same habits for the feedback that keeps arriving: from customers, from support, from the sales team noticing an outdated price. One place, a location and context for every note, triage, and a visible resolution. A site is never finished, but its feedback can still be under control.