How to Present a Dashboard Mockup to Stakeholders and Get Sign-Off

Getting a stakeholder to approve a dashboard design sounds simple. Show them the mockup, they say yes, you build it. In practice it’s messier: vague feedback, competing opinions, last-minute scope changes, or silence that you interpret as approval but isn’t.

Here’s how to run a mockup review that ends with a real decision.

Who should be in the room

Invite:

• The primary stakeholder — the person who will use the dashboard daily and owns the business question
• The final approver — often the same person, but sometimes a manager who needs to sign off on analytics work
• Any secondary stakeholders who will use the report, if they have meaningfully different needs

Don’t invite everyone who has an opinion. A five-person review produces five sets of conflicting changes. If you need to gather input from a wider group, do it before the review meeting and incorporate it into the mockup first.

Set expectations before the meeting starts

Send the mockup in advance with a short note:

“I’ve put together a wireframe for the sales dashboard we discussed. This is a rough sketch of the layout — real data, colors, and exact labels will look different in the final report. The goal of our meeting is to agree on structure: which metrics to show, where they sit, and what filters we need. Looking forward to your thoughts.”

This primes the stakeholder to think about content and structure, not aesthetics. It also avoids the awkward moment where they think they’re seeing a finished product.

Structure the meeting

5 min — Context. Restate the business question the dashboard is designed to answer. “We’re building this so the sales team can track pipeline health without pulling a weekly Excel report.” This anchors the conversation.

10–15 min — Walk through the mockup. Don’t just show a static image and ask for reactions. Walk through each section:

• “This top row shows three KPI cards: total pipeline value, deals won this month, and average deal size.”
• “Below that is a line chart showing pipeline by stage over the last 12 months.”
• “On the right we have a table with open deals, sortable by owner and close date.”
• “The filter at the top lets you slice by region and sales rep.”

Explain what each visual will show, not how it looks. The stakeholder needs to evaluate whether it answers their question.

10 min — Feedback. Ask specific questions:

• “Is there a metric you expected to see that’s missing?”
• “Are there any visuals here that you wouldn’t actually use?”
• “Does the filter set cover all the slicing you need?”
• “Is this the right level of detail, or do you need more granularity somewhere?”

Avoid open-ended “what do you think?” questions. They produce vague answers.

5 min — Decisions. Before the meeting ends, state out loud what was agreed and what changed: “So we’re removing the pipeline-by-stage line chart, adding a win rate KPI card, and keeping everything else. I’ll update the mockup and send it over — if you don’t have changes within 48 hours I’ll start building.”

Handling common pushback

“Can we add X?” — Evaluate scope. If it’s a small addition (one more KPI card), add it. If it’s a significant new section, ask if it should be a separate report tab or a follow-on phase. Don’t let scope creep turn a two-week build into a six-week build without a conversation.

“I don’t like the layout.” — Ask what specifically isn’t working. “The KPI cards should be bigger” is actionable. “It just feels off” needs more probing. Try: “If you could change one thing, what would it be?” That usually surfaces the real concern.

“What will it look like with real data?” — This is a sign they’re unclear on what a wireframe is. Remind them the colors and exact numbers will look different in the final report. If they need to see a data-connected prototype to approve, plan a second review after you’ve built a rough version.

Silence or “looks great.” — Don’t take this as sign-off without explicitly asking: “So we’re good to start building based on this?” Make the approval verbal and follow up with a written summary.

The follow-up

After the meeting, send a short email:

“Thanks for the review. Based on our discussion, here’s what we agreed: [2–4 bullets on changes]. I’m planning to start building on [date] and target [completion date]. Let me know if anything changes before then.”

This creates a record of what was agreed, sets expectations for timeline, and gives the stakeholder a clear window to raise any final concerns.

Why this matters

The mockup review isn’t a formality. It’s where you find out whether you understood the requirement correctly — before you’ve spent 20 hours building the wrong thing. The more clearly you run the meeting, the less rework you do later.

---

Build your dashboard mockup in Mockko and export it as a PDF or PowerPoint to share before your next review.