Website Design Client Presentation Checklist: From Mockup to Decision

A website design presentation works best when the client understands what they are looking at and what decision comes next. A polished mockup helps, but a polished mockup without context can still produce a scattered conversation about colors, missing functionality and preferences that were never part of the brief.

Use this website design client presentation checklist to prepare the material, structure the walkthrough and leave the meeting with a useful next step. The process works for a live call or an asynchronous review. It is especially useful for freelancers and small agencies presenting a homepage or landing-page direction before development begins.

Start with one decision

Before exporting anything, finish this sentence: “After this presentation, we need the client to decide whether…” A good answer might be whether the proposed homepage structure supports the agreed service priorities. Another might be whether the visual direction feels appropriate for the target audience.

“Give us feedback on everything” is not a decision. It mixes strategy, copy, visual design and implementation into one request. If every topic is open at the same time, a discussion about the hero image can derail a necessary decision about the page's primary action.

Write the decision at the top of your own presentation notes. Use it to choose which screens to include and which questions to defer. This is not about preventing useful feedback. It is about giving people enough structure to contribute at the right level.

Check the mockup before the client sees it

Review the design from top to bottom at a realistic viewing size. Look for clipped text, inconsistent button labels, missing images, awkward line breaks and footer information carried over from a template. Make sure the primary navigation labels match the page structure you are presenting.

Replace placeholder copy wherever the content affects the layout or message. A service headline, price, testimonial or call to action changes how the client interprets the design. If final content is unavailable, label the uncertainty in your notes and explain which layout decisions may change when that content arrives.

Check the review file itself after export. A correct source frame can still produce an export with the wrong crop, background or dimensions. Open the file outside the design tool. If the client will receive a browser preview, check the browser preview as well. The deliverable they see is the artifact you need to inspect.

Prepare a short presentation sequence

Begin with the audience and objective, then show the overall page, then discuss the few design decisions that matter most. Finish with the questions you need answered. That sequence lets the client understand the design as a response to a problem rather than a collection of unrelated styling choices.

For example, a consulting homepage might have three presentation points: a clear statement of who the service helps, a short explanation of the engagement process and a visible consultation action. You can walk through the sections in that order even if the page contains additional supporting material.

You do not need to explain every spacing value or icon. Select the decisions that connect the design to the brief. If you removed a section, explain what became easier for the visitor. If you changed the hierarchy, explain what the visitor should notice first. Keep the explanation tied to observable design choices.

Make the preview easy to open

Create a browser-based preview rather than relying on an enormous attachment that the client must download and open in another application. With Swelik, you can upload the prepared mockup and share the public preview URL. Test the link before the meeting or review email goes out.

Open it on a desktop and a phone. Confirm that the full page is present and that the client can scroll to the bottom. A static desktop mockup will scale down on a narrow screen; it will not become a separate mobile layout. If mobile decisions are in scope, include a dedicated mobile design or clearly explain what is being reviewed.

Keep the private management link out of the client message. Save it in your project notes so you can replace the mockup later. Check the expiration window too. If a stakeholder is away for several weeks, plan the review around the preview's availability rather than assuming the link is permanent.

A practical pre-presentation checklist

Scope: The page and review stage are clearly named. The expected decision is written down. The recipient knows whether the review concerns structure, visual direction, copy or implementation.

Content: Important headings and calls to action are realistic. Draft material is identified. Images are appropriate to share. There are no private notes, unrelated client details or accidental source-file links in the export.

Presentation: The public URL opens without your account session. The page is not cropped. Small text is readable at the intended scale. The full page can be scrolled. Desktop and mobile viewing have both been checked.

Follow-through: The management link is saved privately. The feedback deadline is reasonable. One person owns consolidated client feedback. The next revision or handoff step is explained.

This checklist is intentionally short enough to use on every review. A larger process that nobody completes is less useful than a consistent five-minute check before sending a link.

Open the conversation with a useful script

Try an introduction like this: “Today we are reviewing the desktop homepage structure and visual direction. The goal is to make our main service clear and give visitors an obvious next step. I will walk through the page, then we can discuss the headline, section order and overall tone. Form behavior and the mobile layout are separate review items.”

This introduction establishes what is included without sounding defensive. It also prevents a static preview from being mistaken for the finished website. A client who clicks a decorative button during the presentation should understand that they are looking at a mockup, not encountering a broken production feature.

For asynchronous review, use the same structure in a short email or project message. Add the public link and a numbered set of questions. Keep those questions in the message itself so the client does not need to remember instructions from a previous call.

Ask questions that lead to decisions

“What do you think?” often produces a list of impressions. More focused questions help people relate their response to the page's job. Ask whether the first section explains the service accurately, whether important information is missing, and whether the main action matches the intended customer journey.

Separate factual corrections from preference changes. An incorrect address can usually be fixed immediately. A request to change the entire page structure may require a conversation about the brief and priorities. Treat both respectfully, but do not assume they have the same impact on the project.

When feedback is vague, ask for the effect rather than demanding a solution. If the client says the page feels crowded, ask which section is difficult to scan and what they expected to notice first. They can describe the problem in their own words while you retain responsibility for proposing a design response.

Present alternatives carefully

Only show alternatives that you are prepared to discuss and potentially develop. Three nearly identical versions can make the client feel that choosing a button color is the central strategic decision. A single well-supported direction may be easier to review than a gallery of unfinished possibilities.

If alternatives are necessary, explain the tradeoff for each. One direction might emphasize a detailed service explanation; another might prioritize a short path to an inquiry. Avoid framing one option as obviously correct while asking the client to pretend they have a meaningful choice.

Keep versions clearly labeled. A client should not have to infer which image is current from the order of attachments in a message thread. If you replace a preview at the same public URL, tell them what changed so they know they are reviewing the latest work.

Close with a written next step

Before ending the call, repeat the decisions made and identify anything still unresolved. Write down who will provide missing copy, who will confirm factual details and when the consolidated response is due. This small record helps prevent a friendly conversation from being interpreted as approval of work that was never actually discussed.

After the call, send a concise recap with the same public preview link. List the agreed changes and any items explicitly outside the current revision. Keep your own exports and source milestones separately; a replaceable preview is useful for ongoing review, but it should not be your only historical record.

For a more detailed feedback workflow, read website mockup feedback and revisions. If you are deciding whether to use a source-file prototype or a separate preview, see Swelik vs Figma for client reviews.

Common presentation questions

Should I present the mobile design at the same time?

Include it when mobile behavior is part of the current decision and the design is ready to discuss. If it is not ready, say so clearly. A scaled desktop screenshot does not demonstrate responsive layout decisions, even when it fits inside a phone screen.

Is a live call required?

No. A clear preview link, a short explanation and a focused set of questions can support an asynchronous review. A call is helpful when the project has unresolved assumptions or several stakeholders who need to discuss competing priorities together.

How many screens should I show?

Show the screens necessary for the decision. A homepage review may need one complete page and a relevant mobile frame. A multi-step interaction requires the connected states. There is no universal screen count that makes a presentation effective.

What should I do immediately before sending the link?

Open it as a recipient, inspect the whole page and read your request once more. If the client can identify the page, understand the review scope and know how to respond, the presentation is ready to send.