How to collect feedback on a website mockup — precise homepage comments

You send a homepage mockup at 10:12 PM and then wait. What arrives at 10:30 is usually: “Looks good, but can we make it pop more?” That sentence costs you time. It sparks guesses and three rounds of back-and-forth.

This post is about how to collect feedback on a website mockup so that those replies stop being guesses and start resolving work. You’ll get templates, scripts, and the exact prompts to use on homepages — the one page where vague praise or vague objections do the most damage.

Why homepage feedback needs stricter rules

The homepage is half billboard, half funnel control. A tiny header tweak can tank click-through rates. Yet clients often comment on the wrong thing: “This doesn’t feel premium.” That’s emotion, not instruction.

If you want useful comments, you have to make the act of commenting slightly harder — in a good way. Make them say where, on which device, how it should function, and what metric or user reaction they expect.

Vague praise is noise. Specific critique is a brief you can work with.

how to collect feedback on a website mockup (exactly what to ask)

Start every review with context. In your brief or review email, include these four items up top, no exceptions:

• The device and breakpoint to review (desktop 1440, tablet 768, mobile 375).
• The user goal for this page (subscribe, buy, apply, learn).
• The baseline: what’s currently live and the conversion number if you have it.
• The deadline and how you’ll sign off changes.

Then give clients three simple prompts that force specificity. Don’t accept anything else.

1) "What works?" Tell me the exact section and why. (E.g., "Hero CTA text is clear — encourages click because it states value.")

2) "What’s broken or confusing?" Pin the element, state the device, and describe the expected behavior. (E.g., "On mobile hero the CTA sits below the fold on 375px; expected click target above the fold.")

3) "What would you change and why?" Offer one suggested outcome, not a directionless feeling. (E.g., "Shorten headline to 6 words to increase scannability for new visitors.")

Those three prompts cut vague replies like “make it pop” down to actionable notes 80% of the time.

File prep: give them the right thing to comment on

Don't send a 30-layer Figma file with five variants. Package one artboard per review.

• Export a high-res PNG of the current view for quick visual pins.
• Attach a link to the working file (Figma) and the prototype flow for interaction context.
• If clients hate Figma, send a review link where they can pin, draw, and record screen feedback. Clients who can’t open files will open a share link.

If you want annotated, timestamped feedback, tools like ClientMarkup make it painless: clients open a link, drop pins or draw, and even record a short screen explanation — no account.

Scripts you can copy (use them verbatim)

Email subject: Review: Homepage mockup v2 — quick 15-min feedback

Body:

Hi [Name],

Attached is the homepage mockup for review. Please open the review link and leave feedback directly on the design before Thursday 4 PM. Use these three prompts for each comment:

• What works? (section + why)
• What’s confusing or broken? (pin, device, expected behavior)
• What would you change and why? (one suggested outcome)

If you want to explain verbally, press record and give a 60–90s screen comment. That’s helpful for context. Thank you — I’ll consolidate feedback and post changes by Friday.

This short script reduces “gut” replies and gives you a clean list to act on.

How to manage internal reviewers — don’t let four people edit the same canvas

Internal stakeholders amplify indecision. Use a single reviewer per discipline: product, marketing, and legal. Ask them to coordinate and forward one consolidated feedback document.

If you must have multiple eyes, do this:

• Phase reviews. Marketing and product first. Legal last.
• Use a shared spreadsheet (one row per issue) with columns: ID, screen, element, device, suggested fix, priority.
• Assign an owner to convert comments into tickets.

A single owner turns scattered annotations into deliverables.

Turn comments into tickets the moment you read them

When feedback lands, don’t reply with “Noted.” Map it to a task immediately. Your ticket should contain:

• Screenshot with the pinned comment.
• Exact quote from the reviewer.
• Acceptance criteria (what you’ll check when it’s done).
• Priority: Must / Should / Nice-to-have.

You will lose time debating what “should” means. Define acceptance criteria up front.

Quick Figma vs. PDF vs. review link decision guide

Figma: best for interactivity and teams who are comfortable in the file.

PDF: ok for execs or formal sign-off, but comments are less precise and often siloed.

Review link (ClientMarkup or similar): best for external clients who need pin-and-draw and for capturing short screen-recorded explanations.

Pick the path that matches the audience, not the one you prefer.

A few redlines that actually help

• Force a device note for every comment. If someone says ‘move the button,’ you need to know whether that’s desktop, tablet, or mobile.
• Ask for a reason tied to user outcome or metric. If they can’t provide one, push back: “How will this change help a new user?”
• Require at least one proposed wording change for copy issues instead of vague “make it snappier.”

These small rules change the tone of feedback from taste-based to objective.

Closing the loop and getting sign-off

After you implement changes, bundle them with a short cover note: a list of issues closed, unresolved items, and any tradeoffs you made. Send that package back through the same review link and request a single-line approval: “Approve version X — [name] — date.”

If you collect feedback on multiple pages, keep a running changelog. It’s small overhead and it ends endless revision threads.

You don’t need magic. You need structure. Start every review with device + goal + baseline. Force three specific prompts. Give them one visual link to drop pins. Convert every comment into a ticket with acceptance criteria. Make sign-off a one-line action.

Do that and the next time you hit send at 10:12 PM, you’ll get something useful back by 10:30.