How to Collect Better Client Feedback on Website Mockups
10/8/2026 · 8 minute read · By Swelik
A practical process for focused review questions, useful comments, stable preview links, clear change summaries, and approvals that explain what was agreed.
A review can contain dozens of comments and still leave the designer unsure what to change. “Make it pop,” “the page feels busy,” and “can we try another layout?” describe reactions, but they do not identify a clear next step. A useful feedback process turns those reactions into decisions without dismissing the client’s concerns.
Swelik gives an exported mockup a shareable review destination. The process around that link still matters: define the review scope, ask focused questions, consolidate responses, and explain what changed in the next version. This guide shows how to do that without making every visual adjustment feel like a new project.
The goal is not to eliminate discussion or persuade the client to approve everything. It is to make the discussion specific enough that revisions improve the work and approvals mean something.
Set the scope before sending the design
Tell the client what stage the project has reached. An early concept may be ready for feedback on tone and page structure while photography, copy, and smaller-screen layouts are still provisional. A late-stage review may be focused on final wording and visual details.
Put that scope in the message accompanying the link. For example: “This round covers desktop homepage structure, the opening message, and the service descriptions. Images are placeholders, and mobile layouts will be reviewed separately.” The client can then judge the work against the correct expectations.
Also identify the decision-maker. A project with several stakeholders needs a way to resolve conflicting requests. Ask the client to nominate someone who will consolidate feedback or confirm the final direction. Swelik can hold a shared visual reference, but it cannot decide whose business priorities take precedence.
Ask questions that connect design to a goal
Broad questions often produce broad responses. Instead of asking whether the client likes the homepage, ask whether the opening message accurately describes the service, whether the section order matches common customer questions, and whether the main action is appropriate for the business.
Keep the questions specific without leading the answer. “Does this headline explain your service to a first-time visitor?” invites useful evaluation. “You agree this headline is stronger, right?” puts pressure on the reviewer and may hide concerns that will return later.
Limit each review to the decisions the project is ready to make. Asking the client to judge structure, photography, animations, mobile behavior, and final wording at once can make it difficult to separate strategic concerns from small visual preferences.
Give feedback a usable structure
A helpful comment names the location, describes the concern, and explains the desired outcome. It can include a proposed solution, but the solution is easier to evaluate when the underlying problem is clear. This lets the designer consider alternatives rather than mechanically applying a request that may not solve the issue.
For example, “The services section has three equally prominent buttons, and we want consultation bookings to be the main next step” is more actionable than “Change the buttons.” It gives the designer a hierarchy problem to solve and gives the client a result to check in the revision.
Encourage references to section names, headings, or distinctive content. Where image pins or comments are enabled, use them to locate the issue. PDF and HTML discussions can reference page sections in the message. Do not assume every file format supports identical annotation behavior.
| Vague reaction | Useful clarification |
|---|---|
| The page feels busy | Which section is hardest to scan, and what should stand out first? |
| Make the headline bigger | Is the issue readability, prominence, or the message itself? |
| We do not like this image | Is it inaccurate, off-brand, poorly cropped, or the wrong subject? |
| The button should move | At what point should the visitor be ready to take that action? |
Keep one review destination
Create the preview in Swelik and share its public URL. Save the private management link separately. Include the review deadline, the scope, and the person responsible for consolidating feedback in the same message so those details are easy to find later.
When comments or approval controls are enabled, explain whether you want the client to use them. If the team prefers a project thread or a document, that can work too. The important agreement is where final decisions will be recorded, not how many tools can collect comments.
Avoid treating an informal reaction in a chat as the same thing as a consolidated change request. If feedback arrives in multiple places, bring it into the agreed record before revising. Otherwise, you may implement one person’s preference while missing the client’s final decision.
Sort feedback before opening the design file
Read the whole response before making changes. Group requests into factual corrections, business or content decisions, usability concerns, and visual preferences. This is a working method for the review, not a claim that one category is always more important than another.
Resolve contradictions first. If one stakeholder asks for a shorter homepage and another asks for three additional sections, you need a priority decision. Trying to satisfy both independently can produce a longer page with less clarity and another round of dissatisfaction.
Separate work inside the agreed scope from new requirements. A request for a different headline may be a revision; a request for an entirely new booking experience may need a broader conversation. Explain the impact before implementation instead of allowing the review thread to become an unspoken scope change.
Revise the source, then replace the mockup
Make approved changes in the original design source. Keep a clearly named export of the revision in your own project storage. Open the private Swelik management link and use Replace Mockup on the existing project rather than creating a new project by default.
The public preview URL stays the same through replacement. Once processing finishes, open that public URL and verify the new design. Check the changed areas, but also inspect nearby sections for accidental movement, missing content, or export errors. A successful upload is not the same as a visually correct revision.
Keep an independent record of the source and approved exports. The preview can expire, and downloaded copies will not update themselves when you replace the public mockup. A stable link supports the review process; it does not replace file management.
Send a change summary with each revision
A revision announcement should tell the client what to look at. “Updated” is technically accurate but not very useful. A short summary can connect each important change to the feedback that prompted it.
For example: “The services overview now appears before the case studies. The hero headline has been rewritten to explain the consultation offer. The contact section now includes the expected response time. Please confirm these three items; photography is still provisional.” This keeps the next review focused and preserves the context of the decisions.
Include unresolved questions honestly. If a request could not be completed because copy or an asset is missing, name that dependency. Avoid presenting a partially implemented change as finished merely to close the round quickly.
Record approval with its limits
An approval should identify the version, the date, the person confirming it, and what was approved. It can also list exceptions such as final photography, legal copy, or a mobile layout that has not yet been reviewed. This reduces ambiguity when the project moves into development.
Where Swelik’s approval controls are enabled, they can record a review response. Anonymous review names are supplied by the reviewer, so do not treat them as independently verified identity or a substitute for any formal approval process your project requires.
A visual approval does not establish that the final website is accessible, fast, secure, or functionally complete. Those require their own implementation checks. Keep the distinction clear in the handoff so neither the designer nor the client assumes that a mockup review covered more than it did.
Close the loop after approval
Save the approved export with the project record and provide the implementation team with the source material they need. Include responsive layouts, content decisions, and known exceptions. A single desktop mockup is useful context, but it is not a complete specification for every screen size and interactive state.
Check the preview’s expiration date if the team will continue to reference it. If you delete a preview, people who previously downloaded a copy may still have it. Handle retention according to the project’s requirements rather than assuming that deleting a link recalls every distributed file.
For a first-time setup, read how to share website mockups with Swelik. If the discussion depends on interaction behavior, see Swelik versus Figma for client reviews before choosing the presentation format.
Frequently asked questions
How many questions should I put in a review request?
Use a small set that matches the current milestone. Three focused questions often make a clearer starting point than a long list of unrelated details, but the right number depends on the decisions the project needs.
What if stakeholders disagree?
Ask the designated decision-maker to resolve the priority before implementing contradictory requests. Summarize the options and their implications so the choice is explicit rather than hidden in a design revision.
Should every revision get a new public link?
Not when the goal is to continue reviewing the same project. Replace the mockup through its management link to keep the public URL. Create a separate project when you intentionally need a separate presentation destination.
What if the client only says “looks good”?
Confirm what that response covers. Ask whether the current version is approved for the next stage and note any exceptions. A short clarification now is easier than reconstructing the meaning of an informal message later.
A focused preview, specific questions, and a clear revision summary create a review process people can follow. Start a Swelik preview and pair the link with a decision you actually need the client to make.
Put this into practice with Swelik’s mockup sharing and review tools.