How do I get clients to give specific feedback instead of vague comments?

Ask a pointed question instead of an open one. "Does the CTA button stand out enough on mobile?" gets a yes/no with context. "What do you think?" gets "it looks good but something feels off." If a client sends vague feedback, reply asking which element they mean before you change anything — fixing the wrong thing costs more time than the follow-up question.

Should my client need an account to leave feedback?

No — and if they do, expect fewer responses. Most clients won't create an account for one round of design review. Tools that require signup get skipped; feedback ends up in email instead. Keep the barrier as low as possible: a link they can open and comment on in under a minute.

How do I avoid endless revision rounds?

Set a revision limit in your contract, and batch feedback by round. Round 1 catches structural issues — layout, content, navigation. Round 2 is copy and polish. Round 3 (if needed) is final sign-off. When each round has a defined scope and deadline, clients stop trickling in notes and you stop context-switching mid-build.

What's wrong with collecting feedback over email?

Email threads get long, out of order, and hard to search. A change mentioned in email four often contradicts something in email nine — and neither is pinned to the element it describes. You end up reconstructing the client's intent instead of executing it. The fix is a single place where every note is attached to the element it describes.

Can multiple stakeholders leave feedback at the same time?

Yes, and they should — but in the same place. If the CEO emails you while the marketing manager comments in a shared tool, you have two feedback streams that may conflict. Ask everyone to use one channel and share one link. Conflicts surface immediately when two people can see each other's notes.

How do I handle feedback I disagree with?

Reply to it — don't just ignore it or implement it blindly. Explain the design decision: "The header is that size because it needs to be readable on mobile at 375px — if we go smaller, the contrast ratio drops below WCAG AA." Clients push back on choices they don't understand. Explain the reason and most disagreements resolve without a revision.

drafty

How to get website feedback from clients

Quick answer

Share a direct link to the live or staging site, ask your client to comment on the specific element they mean (not describe it in email), and collect every note in one place before responding. The biggest mistake is accepting vague feedback — "this doesn't feel right" — without asking which element, on which page, at which screen size.

Step 1

Send a link, not a file

A JPEG or PDF export detaches from the real page. Your client annotates a static snapshot, then you have to figure out which element they meant on the live build. Share a staging URL or a Drafty review link instead — they're looking at the actual site, so their note says "the nav" and you know exactly which nav.

Step 2

Ask for element-level feedback, not impressions

"What do you think?" invites vague responses. "Is there any element on the homepage that feels out of place?" gets you something actionable. Before you send the link, tell your client what to look for — copy, layout, mobile feel — and ask them to reference the specific element when they comment. The phrase "the bit near the top" accounts for roughly half of all revision miscommunication.

Step 3

Set a single feedback deadline and channel

Feedback arrives in waves — email Monday, Slack Wednesday, a voice note Friday. Each wave reopens decisions you thought were closed. Name one place (a shared doc, a review tool, a comment thread) and one date. "Please drop all notes on the staging link by Thursday" is a contract. Collecting everything at once also means you batch the fixes, which is faster than context-switching per message.

Step 4

Consolidate before you act

Before opening your code editor, read every piece of feedback in one go. Group it: copy changes together, layout notes together, "I'm not sure" items for a follow-up call. This stops you making a change based on message three that contradicts message seven. It also shows your client that you read everything — not just the first email.

Step 5

Reply in context, not in a separate thread

Emailing back "fixed the header" means your client has to re-open the site, find the header, and figure out what changed. If your feedback is anchored to the element, so is your reply. Mark each note resolved — or explain why you pushed back — right where the comment lives. A client who can see their note is answered doesn't need a status update call.

The faster way

The process above works with any staging URL — but steps 1–5 collapse into one if your client comments directly on the live page. Drop the URL into Drafty, share the link, and they click any element to leave a pinned note. Every comment is already in one thread, anchored to the exact spot, and you can reply or resolve it in place. No screenshot upload, no "which section did you mean", no separate status email. Clients don't need an account — they open the link and click.

Open a live demo

Questions

How do I get clients to give specific feedback instead of vague comments?: Ask a pointed question instead of an open one. "Does the CTA button stand out enough on mobile?" gets a yes/no with context. "What do you think?" gets "it looks good but something feels off." If a client sends vague feedback, reply asking which element they mean before you change anything — fixing the wrong thing costs more time than the follow-up question.
Should my client need an account to leave feedback?: No — and if they do, expect fewer responses. Most clients won't create an account for one round of design review. Tools that require signup get skipped; feedback ends up in email instead. Keep the barrier as low as possible: a link they can open and comment on in under a minute.
How do I avoid endless revision rounds?: Set a revision limit in your contract, and batch feedback by round. Round 1 catches structural issues — layout, content, navigation. Round 2 is copy and polish. Round 3 (if needed) is final sign-off. When each round has a defined scope and deadline, clients stop trickling in notes and you stop context-switching mid-build.
What's wrong with collecting feedback over email?: Email threads get long, out of order, and hard to search. A change mentioned in email four often contradicts something in email nine — and neither is pinned to the element it describes. You end up reconstructing the client's intent instead of executing it. The fix is a single place where every note is attached to the element it describes.
Can multiple stakeholders leave feedback at the same time?: Yes, and they should — but in the same place. If the CEO emails you while the marketing manager comments in a shared tool, you have two feedback streams that may conflict. Ask everyone to use one channel and share one link. Conflicts surface immediately when two people can see each other's notes.
How do I handle feedback I disagree with?: Reply to it — don't just ignore it or implement it blindly. Explain the design decision: "The header is that size because it needs to be readable on mobile at 375px — if we go smaller, the contrast ratio drops below WCAG AA." Clients push back on choices they don't understand. Explain the reason and most disagreements resolve without a revision.

Keep exploring

Review a website Website feedback tool BugHerd alternative How to annotate a PDF

Stop emailing files back and forth.

Share one link. They comment on the exact spot — no account, always the current version.

Open a live demo