How to Present Mockups to Clients: A 6-Step Meeting Script That Gets Approval Faster
Most mockup presentations do not fail because the design is bad. They fail because the designer opens Figma, shares a screen, and says “So, what do you think?”. That single question invites personal taste, and personal taste is the fastest route to three rounds of revisions on a button color.
This is the exact walkthrough I use as a freelance UX designer to run mockup presentations: how I set context before anyone sees a screen, how I explain design decisions, how I frame feedback questions so clients respond with useful input, and the scripts I use when someone says “I don’t like the blue”. Steal all of it.
Before You Read the 6 Steps: The One Rule That Changes Everything
A mockup presentation is not a reveal. It is a decision meeting. Your job is not to impress the client, it is to get a documented yes (or a documented, actionable list of changes) before the call ends.
Everything below is built around that goal. If you keep it in mind, you will stop presenting and start facilitating, and your approval cycles will shrink dramatically.
Quick Answer: How to Present Mockups to Clients
- Prepare and send context 24 hours before (agenda, goals, what you need from them)
- Open the meeting by restating the brief, not the design
- Walk the user journey, screen by screen, in the order a real user would see it
- Explain each design decision using the “goal, decision, reason” formula
- Ask structured feedback questions instead of “what do you think?”
- Close with a written recap and a clear next step within 2 hours
Now the detail, with the scripts.
Step 1: Prepare the Room Before Anyone Sees a Pixel
The most common mistake is emailing a Figma link on Monday and hoping for feedback by Friday. What you actually get is a forwarded link, three stakeholders you never met, and a comment thread arguing about a stock photo.
Send the mockup shortly before the call, not days before
Send the file 10 to 15 minutes before a scheduled call, or do not send it at all until you present. This is deliberate. Unguided viewing produces gut reactions. Guided viewing produces decisions.
What you do send 24 hours ahead is a short context email:
Subject: Tomorrow’s design review, 30 min, what we’re deciding
Hi [Name],
Quick note before tomorrow’s session so we use the time well.
What we’re reviewing: the homepage and the pricing page, desktop and mobile.
Goal of these screens: increase demo requests from organic traffic (the target we agreed on in the kickoff).
What I need from you: a decision on structure and hierarchy. Copy and final imagery are placeholders for now, we’ll handle those in the next phase.
Who should attend: anyone who can block launch. If [Decision Maker] can’t make it, let’s move the call. There’s a solid take on this from a studio that gets this right.See you at 10.
That last line saves entire weeks. The person who can veto your work must be in the room. If they are not, you are presenting twice.
Prepare your own checklist
- Clean the file: hide scratch frames, name layers, remove abandoned versions
- Prototype the key flow so you can click through it live instead of describing it
- Prepare both desktop and mobile views (clients always ask, always)
- Add a short notes box next to each screen explaining what is fixed and what is placeholder
- Test the screen share, the link permissions, and the zoom level on a second monitor
The notes box on each mockup is a small habit that prevents a disproportionate number of disputes. “Photo is a placeholder, final imagery from your library in phase 3” stops the conversation before it starts.
How many mockups should you present?
One direction. Not three.
Presenting several options looks generous, but it turns your client into the designer and turns your meeting into a shopping session. You end up with a Frankenstein composite: navigation from option A, hero from option B, footer from option C, and no coherent rationale anywhere.
If exploration is genuinely needed, do it earlier at low fidelity (wireframes, moodboards) and present a single recommended direction at mockup stage. If a client explicitly paid for multiple concepts, present them sequentially with a stated recommendation, never side by side as equals.
Step 2: Open by Restating the Brief, Not the Design
The first 90 seconds decide whether the client evaluates your work against business goals or against their own taste. You control which.
Do not open with “Here’s what I made.” Open with what you were asked to solve.
Opening script
“Thanks for making time. Before I share anything, let me restate what we agreed, so we’re all measuring this against the same thing.
You told me three things in the kickoff: one, visitors don’t understand what you sell within the first screen. Two, your demo form gets abandoned about 70% of the time. Three, the site has to feel more credible to enterprise buyers, because you’re moving upmarket this year.
So everything I’m about to show you is an answer to those three problems. As we go through it, the question I’d like us to keep asking is: does this move those numbers? Sound right? Anything changed on your side since we last spoke?”
That last question matters. Businesses shift. If their priority quietly changed three weeks ago, you want to know before you present, not after.
Set the agenda and the rules of engagement
“Here’s how I’d like to run the next 30 minutes: I’ll walk you through the flow for about 10 minutes without stopping, so you see it the way a user would. Then I’ll go back screen by screen and we discuss. Please jot down reactions as we go, but hold them until the second pass. That way you see the whole logic before we get into details. Works for you?”
Asking permission for the format gets a verbal yes, and that yes makes it socially easy to say “let’s park that for the second pass” when someone interrupts on slide two.
Step 3: Walk the Journey, Not the Screens
Do not present a gallery of artboards. Present a story with a person in it.
Narrate as a user, not as a designer
Compare these two:
| Weak (designer view) | Strong (user view) |
|---|---|
| “This is the homepage. Here’s the hero section with the headline and CTA button.” | “Sarah, a procurement manager, clicks your Google ad on her laptop. In the first two seconds she needs to know what you do and whether you serve companies her size. That’s why the headline names the outcome and the subline names the segment.” |
| “Here’s the pricing table with three tiers.” | “She scrolls to pricing. Your sales team told me the biggest objection is ‘is there a hidden setup fee?’. So that answer sits directly under the price, before she has to ask.” |
The second version makes disagreement harder to express as taste. To argue with it, the client has to argue about their own customer, which forces a more useful conversation.
Show it clickable
Always click through a prototype rather than scrolling static images. Static images invite clients to judge them as posters. A working flow invites them to judge the experience. Even a rough Figma prototype with three hotspots changes the tone of the meeting.
Show mobile at the same time as desktop
If most of their traffic is mobile, present mobile first. Nothing repositions a conversation about a giant hero image faster than seeing it on a 390px screen.
Step 4: Explain Every Significant Decision With the “Goal, Decision, Reason” Formula
This is the core of the walkthrough. Every deliberate choice gets three sentences:
- Goal: the business or user problem
- Decision: what you did
- Reason: the evidence, principle or constraint behind it
Examples you can adapt
Navigation: “Goal: enterprise buyers need to find case studies fast, that was the top request in your sales calls. Decision: I cut the nav from nine items to five and pulled ‘Customers’ up to top level. Reason: with nine items, nothing gets clicked. Five is within the range people scan reliably, and the removed items still live in the footer.”
Form: “Goal: cut the 70% abandonment on the demo form. Decision: four fields instead of eleven, and the phone number is now optional. Reason: every required field costs you completions. We can enrich the rest of the data after they book.”
Color: “Goal: make the primary action unmissable. Decision: the orange is used for exactly one thing on every page, the primary button. Reason: if orange also appears in headings and icons, the button stops standing out. That’s why the accent looks ‘loud’ here in isolation. It’s doing a specific job.”
That last one is a preemptive strike. Explain your riskiest choice before the client can react to it. If you know the color, the amount of white space or the removed carousel will be questioned, address it on your terms first. You keep the frame.
Say what is not final
Be explicit and repeat it: “The copy is placeholder, focus on hierarchy. The photos come from your library later. The logo in the footer is the low-res version.” Unlabeled placeholders generate feedback you will have to throw away.
Step 5: Ask Structured Feedback Questions (Never “What Do You Think?”)
“What do you think?” is an open invitation to aesthetic opinion. Replace it with questions that can only be answered with business or user knowledge, which happens to be the knowledge the client actually has and you do not.
| Instead of asking | Ask this | Why it works |
|---|---|---|
| “What do you think?” | “Looking at this homepage, is there anything a buyer needs to know that they can’t find here?” | Targets completeness, not taste |
| “Do you like it?” | “Does this feel credible to the enterprise buyers you’re targeting this year?” | Ties the reaction to the agreed goal |
| “Any changes?” | “If a customer landed here and only read the first screen, what would they think you do?” | Tests clarity through their own eyes |
| “Is the layout OK?” | “Which objection from your sales calls is still not answered on this page?” | Uses knowledge only they have |
| “Should we change the colors?” | “Does anything here conflict with brand rules you’re required to follow?” | Turns taste into a factual constraint |
| “Ready to approve?” | “Is there anything blocking approval today, or anything that needs another stakeholder’s eyes?” | Surfaces hidden approvers immediately |
The silence technique
After each question, stop talking. Count to seven in your head. Clients need time to form a real thought, and designers habitually fill the gap with nervous justification. Silence produces better feedback than any follow-up prompt.
Capture feedback in writing, live
Share your notes document on screen while you type. Two benefits: the client sees their point recorded (so they stop repeating it) and they see the exact wording (so they correct it immediately if you misunderstood). Every item goes into one of three buckets:
- Change: agreed, in scope, will be done
- Discuss: needs more information or a decision from someone else
- Later: valid, but belongs in a future phase or a change order
Step 6: Close With a Decision, a Recap and a Deadline
Never end a design review with “send me your thoughts.” That sentence is where projects go to die.
Closing script
“Let me read back what I have. Three changes: shorter hero headline, move the testimonial above pricing, add the security badge in the footer. Two items parked for phase two: the resource hub and the language switcher. Everything else is approved as shown. Did I miss anything? A fuller account is out there.
I’ll send this recap within the hour. If anything’s wrong or missing, reply by Thursday 5pm. I’ll have the revised screens back to you Monday, and then we move into build. Any consolidated feedback after Thursday goes into the next round rather than this one, just so the timeline holds.”
Send the recap email within two hours
The recap is your project’s legal memory. Keep it boring and specific:
- Screens presented and the version number or link
- Approved as shown (list)
- Changes agreed (list, one line each, unambiguous)
- Out of scope or deferred (list, with a note that these will be quoted separately)
- Deadline for corrections to the recap
- Next delivery date and what happens after approval
Ask for a one-word reply: “Reply ‘approved’ to this email and I’ll start production.” Low friction approvals get sent. Formal sign-off PDFs sit in inboxes for a week. sitepoint.com walks through the specifics.
Handling the Classic Objections (With Exact Wording)
Redirecting an objection is not about winning an argument. It is about converting a taste statement into a solvable problem.
| Client says | What it usually means | What you say |
|---|---|---|
| “I don’t like the color.” | Something feels off, and color is the easiest word to reach for | “Good to know. Help me pin it down: is it that it clashes with your brand assets, that it feels wrong for your audience, or that it’s simply not a color you personally enjoy? Those get fixed three different ways.” |
| “It’s too empty, can we fill that space?” | Unfamiliarity with modern spacing, or fear of missing content | “The space is what makes the demo button the first thing the eye lands on. If we add a block there, what should it push down: the button or the social proof?” |
| “My wife/business partner doesn’t like it.” | A stakeholder was not in the room | “Let’s get them on the next call so I can walk them through the reasoning directly. Secondhand feedback loses the ‘why’ and we end up guessing.” |
| “Can you make the logo bigger?” | Worry that the brand is not prominent enough | “I can. Quick check first: visitors already know who you are from the ad they clicked. What they don’t know is what you sell. Do we want the biggest element to be your name or your offer?” |
| “Our competitor’s site does X.” | Insecurity, or a genuinely useful observation | “Let’s look at it together. What specifically works there? If it’s solving a problem we also have, I’ll adapt the principle rather than the look.” |
| “Can you show me another version?” | Something specific is unresolved but unnamed | “Happy to explore. Which part isn’t working? If it’s the hero, I’ll rework the hero. Redoing the whole page usually means we lose the parts you already liked.” |
| “I sent you my own mockup, can you build this?” | They are trying to be helpful and save time | “This is genuinely useful, it tells me your priorities. Let me treat it as a brief rather than a blueprint: I’ll keep the content order you want and apply the hierarchy and accessibility standards we’re contracted for.” |
| “Everyone needs to weigh in first.” | Design by committee is coming | “Makes sense. Can we agree on one person who consolidates and arbitrates? I’ll take conflicting notes to that person rather than trying to satisfy everyone, which usually satisfies nobody.” |
When the client is right
Sometimes the objection is correct. Say so quickly and clearly: “You’re right, that’s a genuine problem, I’ll fix it.” Conceding fast on real issues buys you enormous credibility when you need to hold your ground on a subjective one.
Tools: What to Present With
| Situation | Best format | Notes |
|---|---|---|
| Live call, one main stakeholder | Figma prototype, presented in Present mode via video call | Turn off multiplayer cursors and hide the layers panel |
| Multiple stakeholders, mixed technical comfort | Slide deck (Google Slides, Canva, Pitch) with embedded screens | Slides force a narrative order and stop random clicking |
| Different time zones, async client | Loom or similar video walkthrough, 6 to 8 minutes max | End the video by asking your three structured questions out loud |
| Formal sign-off or procurement process | PDF export with annotations and a sign-off page | Version the filename: client_homepage_v3_2026-08-22.pdf |
| Collecting written comments after the call | Figma comments or a single shared doc | One channel only. Never let feedback arrive via email, WhatsApp and Slack at once |
One rule regardless of tool: feedback lives in exactly one place. Scattered feedback is how items get missed and how you get blamed for missing them.
Common Mockup Presentation Mistakes to Avoid
- Apologising up front. “It’s still rough, sorry” tells the client to look for flaws. State what stage it is at, factually, without apology.
- Presenting unfinished work as finished. The opposite error. Always label placeholders.
- Using lorem ipsum on client-facing mockups. Use realistic draft copy. Clients cannot evaluate a page they cannot read.
- Talking in jargon. “Optical alignment”, “z-pattern”, “eight point grid” mean nothing to them. Translate everything into outcomes.
- Defending everything. If you argue every point, you look rigid. Pick the two or three that matter for the result.
- Letting the call end without a next step. Every meeting ends with a named action, a named owner and a date.
- Skipping the recap email. If it is not written down, it did not happen.
- Accepting unlimited revisions by silence. State the round count and what constitutes a new scope item, before revisions start.
A 30-Minute Presentation Timeline You Can Copy
| Time | What happens |
|---|---|
| 0 to 3 min | Restate the brief and goals, confirm nothing has changed |
| 3 to 5 min | Set the agenda and the “hold questions for the second pass” rule |
| 5 to 13 min | Uninterrupted journey walkthrough, clickable prototype, desktop then mobile |
| 13 to 20 min | Second pass, screen by screen, goal-decision-reason on key choices |
| 20 to 27 min | Structured feedback questions, notes captured live on shared screen |
| 27 to 30 min | Read back the list, confirm approvals, set the deadline and next delivery |
Frequently Asked Questions
How do you present a design to a client?
Start with the business goals you were hired to solve, then walk the client through the design as a user journey rather than a set of screens. Explain each significant decision with the problem it solves, ask structured feedback questions tied to those goals, and close with a written recap listing what is approved, what will change and what is out of scope. For the wider picture, see How to present web design mockups to clients.
Should I present more than one mockup?
Generally no. Present a single recommended direction with clear reasoning. Multiple options shift the decision to the client’s taste and often produce an incoherent mix. Explore alternatives earlier at wireframe stage, where changes are cheap and expectations are lower.
What if the client says “I don’t like it” with no explanation?
Ask a diagnostic question rather than defending the work: “Is it the layout, the tone, or the color palette that’s not landing?” Then narrow further. Vague rejection almost always hides one specific issue, and your job is to find it before you touch the file.
How long should a mockup presentation be?
Thirty minutes for two to four screens, forty five for a larger flow. Anything longer loses attention, and the last decisions get made carelessly. If you need more time, split it into two sessions with a clear objective each.
Should I send the mockup before the meeting?
Send context beforehand and the file itself only 10 to 15 minutes before, or during the call. Early unguided access produces gut reactions and scattered comments from people who never heard your reasoning.
How do I handle a client who keeps requesting changes?
Define the number of revision rounds in the contract, then enforce it politely with a change order for anything beyond it. Also check whether the loop is caused by an unnamed decision maker or an unclear original brief, which are the two most common root causes.
What is the best tool to present mockups to clients?
Figma prototypes for live interactive walkthroughs, a slide deck for mixed stakeholder groups, a short recorded video for async clients, and an annotated PDF when formal sign-off is required. The tool matters far less than the structure of the conversation.
How do I get faster approval?
Three things move the needle most: make sure the actual decision maker is in the room, capture feedback in writing during the call, and end with a low-friction approval request such as a one-word email reply. Most delays are process problems, not design problems.
Final Thought
Clients do not approve mockups because the design is beautiful. They approve because they understand what problem it solves, they feel heard, and they know exactly what happens next. Structure the meeting around those three things and the approvals take care of themselves.
If you want a second pair of eyes on a design review before you run it, or you need someone to run it for you, get in touch.