How to Share a Prototype With a Client for Feedback
Prototype review with a client fails in a consistent way: you send something, you get impressions back, and you spend two more rounds turning impressions into decisions. The fix is mostly process, not tooling. This is a five-step version that works whatever you built the prototype in.
The Problem
“Can you make it pop?” is the joke version. The real version is more mundane and more expensive.
Clients give vague feedback for structural reasons, not because they are being difficult:
- They were not told what to look at. So they review everything, including your placeholder images and your fake customer names.
- They cannot indicate location. An email cannot point at a pixel, so they describe position in prose, and prose is ambiguous.
- They are reviewing a static image. Half of what is wrong with a prototype only appears when you click it.
- They are reviewing on the wrong device. You sent a desktop screenshot. Their customers are on phones.
- There is no record. So decisions get reopened, and disagreements about what was agreed have no evidence in them.
Every one of those is fixable in the message you send with the link.
The Process
1. State the question the prototype answers
One sentence, before anything else:
This tests whether splitting checkout into three steps feels faster than the current single page.
This is the highest-leverage sentence in the project. It tells the client what to look at and — more usefully — what to ignore. Without it you will receive a comment about the placeholder logo, and you will have to respond to it.
2. Send a live link, not an image
Host the prototype and send a URL. The client opens it on their own device, in their own browser, and clicks things.
This matters for a reason that is easy to underrate: interaction is where the problems are. The form that does not validate, the button that does nothing, the headline that wraps to four lines on a phone. None of that is visible in a screenshot, and all of it will come up eventually — better now than after build.
Keep it off the client’s production domain, and served noindex, so an unapproved draft never competes with the real page in search results.
3. Frame the round
Say what is real and what is scaffolding:
Interactive — please click through, and open it on your phone too. Reviewing flow and copy this round. Images are placeholders and the payment step is stubbed.
Four sentences that pre-empt roughly six comments.
4. Let the client mark up the page itself
This is the step that collapses rounds. If the client can click an element and comment on it, “the top feels busy” arrives attached to the section that is busy — nothing to interpret, nothing to confirm.
There is a second effect that matters as much: the format changes the feedback. Asked to comment on a thing, people produce specifics. Asked to comment on a page, people produce impressions. On Undraft, the pinned comment is the default interaction, so specifics are the path of least resistance.
5. Close every comment before the next round
Resolve it or decline it, explicitly. “Not doing this — out of scope for this phase” is a complete and legitimate answer.
Silence is what causes an objection to return in a meeting three weeks later, usually in front of someone senior.
Asking Questions That Have Answers
If you want specifics, ask specific questions. Bad and good, side by side:
| Instead of | Ask |
|---|---|
| ”What do you think?" | "Is the three-step flow clearer than the current one?" |
| "Any feedback on the design?" | "Does the headline say the right thing to a first-time visitor?" |
| "Does this work for you?" | "Would you click this button? If not, what would make you?” |
“What do you think?” invites an impression, and an impression is what you get. Narrow the question and the answer narrows with it.
Examples
Before
- Email a PDF of three screens.
- Client replies: “Nice work. Feels a bit corporate. Also the second page looked odd on my phone.”
- You ask what felt corporate and what looked odd.
- Reply arrives two days later, still vague.
- You change six things and resend.
- Client says it is better but the second page is still odd.
Two weeks, one unresolved item, no record.
After
- Host the prototype, send one link with the stated question and the round frame.
- Client opens it on desktop and phone that afternoon.
- Five pinned comments: two on copy, one on button size, one on a mobile layout break, one question.
- You answer the question in-thread, fix the four, re-upload to the same link.
- Client reopens and resolves all five.
Two days, five specific notes, and a version history to point at.
Summary
- Lead with the question the prototype answers — one sentence that tells the client what to review and what to ignore.
- Count clarifying questions per round — that number measures how much your feedback channel is costing you.
- Avoid open-ended asks like “what do you think?” — vague questions reliably produce vague answers.
Next: see how clients comment on a webpage directly, and how to share an HTML file as a live link.
Frequently Asked Questions
What is the best way to share a prototype with a client?
A live link they can open in their own browser, with one sentence stating what to review and what is placeholder. Interaction catches what static images hide, and the framing sentence prevents most off-target feedback.
How do you get specific feedback instead of 'make it pop'?
Give the client a way to point at things, and ask questions narrow enough to have answers. Vague feedback is usually a symptom of a vague request plus a channel that cannot indicate location.
How many people should review a prototype?
Two or three named reviewers with stated roles. Larger groups produce contradictory notes that you then have to arbitrate, which is slower than a small review and worse.
Should you present a prototype live or send it?
Both, in that order, when the stakes are high. A short walkthrough sets context and the async link is where considered feedback actually gets written down.
How do you stop clients reopening settled decisions?
Keep a record: versions of the prototype plus the comments that drove each change. When 'we never agreed to this' has a retrievable answer, the conversation ends in a minute.
More on this topic: Feedback and Review
Founder at Undraft · Product manager
Built Undraft after watching prototype review break down into screenshots and ZIP attachments one too many times. Writes from direct experience running the product.