How to Design a KPI Dashboard Executives Will Actually Use
The stakeholder questions to ask before opening Power BI or Tableau, since that's the step almost everyone skips
5 Minutes Read
How to Design a KPI Dashboard Executives Will Actually Use
Many dashboards go unused for reasons that have little to do with whether the charts look good. They're unused because nobody asked the executive what decision the dashboard was actually supposed to support before building it. The analyst picked the metrics that were easiest to pull, arranged them in the order the data happened to load, and shipped something technically correct that nobody opens after the first week.
The fix isn't a better chart type. It's a five-minute conversation that happens before you open Power BI or Tableau at all, and it's the step this guide spends the most time on, because it's the one almost every tutorial skips in favour of jumping straight to the visuals.
The stakeholder interview: what to ask before building anything
Treat this as a genuine short interview, not a formality. Four questions do most of the work. They also line up closely with the way Microsoft and Tableau recommend thinking about dashboard purpose and audience before getting into visual design.
"What decision does this dashboard need to support?" Not "what do you want to see," which tends to produce a wish list, but what specific decision or action this dashboard should make faster or clearer. A dashboard meant to help a VP decide where to reallocate ad spend needs completely different metrics from one meant to reassure a board that the business is healthy.
"How often will you actually look at this?" A dashboard checked daily needs to surface change and anomalies quickly. A dashboard checked monthly needs more context and trend, since the viewer has less continuous memory of what "normal" looks like. Building a daily-cadence layout for a monthly-cadence viewer, or the reverse, is a common, quiet source of a dashboard nobody opens.
"If one number changed significantly, would you want to know immediately?" The answer identifies your headline metric, the number that earns the most prominent spot on the page. If the honest answer is "not really, I'd rather see the trend over the quarter," that tells you the layout should lead with trend, not a single large number.
"What should this number be compared against?" A number alone rarely means anything to an executive. Compared to last month, compared to target, compared to the same period last year, each comparison implies a different layout decision and, often, a different data pull entirely.
Design principles that follow directly from those answers
Lead with the headline number, not a wall of charts. Whatever answered the "if this changed, would you want to know" question belongs at the top, large, with its comparison right next to it. An executive should be able to identify the single most important fact almost immediately, before scrolling or clicking anything. Microsoft's guidance makes a version of the same point, noting that most people read top to bottom, so the highest-level information belongs at the top left, with more detail as the reader's eye moves further into the page.
One dashboard answers one core question well, rather than ten questions poorly. A dashboard trying to serve sales, marketing, and finance simultaneously usually serves none of them, since each function's headline metric and comparison logic differ. If you catch yourself building for three audiences at once, that's usually a sign you need three dashboards, or three clearly separated pages within one.
Every number needs a comparison, not just a value. "Revenue: ₹2.3 crore" tells an executive almost nothing on its own. "Revenue: ₹2.3 crore, up 8% versus last month, 3% behind target" tells them whether to feel good, bad, or neutral, and that judgment is the actual product a dashboard is meant to deliver.
Keep the first page to only the visuals needed for the decision. If the page starts feeling crowded, move detail to a second page or drill-down rather than extending the first page indefinitely. Tableau's own guidance is specific on this point, generally recommending limiting a single dashboard to two or three views, and the Tableau Blueprint visual best-practices guide frames white space itself as functional, since it helps define hierarchy and keeps a dense page from becoming harder to read, not as empty space to be filled with more charts. If there's genuinely more the audience needs, that's what a second page or a drill-down click is for.
Match the time period consistently across every visual on the page. A dashboard showing this month's revenue next to last quarter's churn rate next to year-to-date signups is quietly asking the viewer to do date-normalisation math in their head before any comparison makes sense. Academic research on dashboard design describes this kind of choice as a genuine tradeoff, not a purely aesthetic one: fitting more onto one screen, one page, and one interaction model always costs something elsewhere, whether that's consistency, clarity, or the viewer's own effort to reconcile what they're looking at.
A worked example: a sales VP's dashboard
The interview. The VP says the dashboard needs to support a monthly decision about which regions get extra sales headcount. She checks it weekly during the review cycle, mostly monthly otherwise. If regional revenue growth stalls significantly, she wants to know immediately. She compares everything against the quarterly target, not last year, since the business has changed too much year over year for that comparison to mean much anymore.
What that interview determines. The headline metric is revenue versus quarterly target, broken out by region, since that's the number tied directly to the headcount decision. The comparison logic is target-based, not year-over-year, which rules out several chart types that assume a historical trend line is the point. The cadence is weekly-glanceable with monthly depth available, which argues for a top-line summary card plus a trend chart underneath, rather than a dense weekly-grain table.
The resulting layout. A headline card at the top: total revenue versus quarterly target, with the gap called out explicitly. A regional breakdown directly underneath, sorted by how far each region is from its own target, not alphabetically, since the sort order itself is doing analytical work. A trend line beneath that, showing the same metric over the past six months, so a stall is visible before it becomes a crisis. Headcount and pipeline data sit on a second page, available but not competing for attention with the number that actually drives the decision.
Notice that none of this required a novel chart type. The differentiation is entirely in what got included, what got left off, and what order it appears in, all of which trace directly back to the four-question interview.
Common mistakes
Skipping the stakeholder conversation and guessing at what matters. This is the root cause behind most of the mistakes below; a short conversation can prevent many dashboard problems before they're built.
Building for yourself instead of the audience. An analyst's instinct is to include everything interesting; an executive needs everything decision-relevant. Those are frequently different, shorter lists.
Including a metric because the data was easy to pull, not because it matters. Data availability is not the same thing as relevance, and a dashboard padded with easy-but-irrelevant metrics dilutes the ones that actually matter.
Reporting a number without its comparison. A raw value with no target, no prior period, and no benchmark forces the viewer to supply their own judgment, which is exactly the work the dashboard was supposed to do for them.
Inconsistent time periods across visuals on the same page. Even technically correct numbers become hard to compare mentally when each chart quietly uses a different date range.
Decorative colour with no analytical purpose. Colour should mean something, above or below target, this region versus that one, not just make the page look finished. Random colour variety is one of the fastest ways to make a dashboard feel busy without adding information.
Where to go from here
This guide covers the thinking behind a dashboard, not the button-by-button build. If the modelling and relationship side of building one in Power BI still feels shaky, the Power BI for beginners tutorial covers that ground, including the data model decisions that any well-designed dashboard depends on underneath the layout.
Dashboard design can come up in analyst interviews too, sometimes framed directly as "how would you design a dashboard for a stakeholder," which is close to the exact scenario worked through above; the interview questions guide covers that question alongside the technical rounds. And if you want to practise the stakeholder-interview habit on a real build rather than reading about it, the sales dashboard entry among the beginner project ideas is a close match for the worked example in this guide.
Quiz
TEST WHAT YOU LEARNED
Question 1 of 15
Q1: According to this guide, what is the most common root cause of an unused executive dashboard?
FAQ
FREQUENTLY ASKED QUESTIONS
Nobody asked what decision the dashboard needed to support before building it. The result is a technically correct dashboard answering a question the executive never actually had.
There's no fixed number that applies universally; the right count is whatever the decision actually requires, not a target to hit. As a practical signal, if the page starts feeling crowded or hard to scan quickly, that's the cue to move detail to a second page or drill-down rather than adding to the first.
Yes, wherever practical. A number without a comparison point—a target, a prior period, or a benchmark—tells the viewer very little on its own and pushes the interpretation work back onto them.
Ask the stakeholder directly: if one number changed significantly, would they want to know immediately? Whatever they name is almost always the right headline metric.
That's usually a sign you need separate dashboards or clearly separated pages, not one dashboard trying to serve every audience simultaneously. A shared dashboard with conflicting priorities tends to satisfy nobody fully.
Yes. A daily-use dashboard needs to surface change and anomalies quickly, since the viewer checks in often enough to notice them. A monthly-use dashboard needs more built-in context and trend, since the viewer has less continuous memory of what normal looks like.
Consistency is generally right, but colour should still carry meaning—above or below target, one region versus another—rather than being decorative. Reserve a distinct colour for genuinely important signals like being off-target.
The design thinking in this guide applies to either tool. If you haven't settled on which to prioritise, Power BI vs Tableau vs Excel covers that decision separately from the design question covered here.
Specific enough to produce a concrete answer, not a general one. "What do you want to see" invites a wish list; "what decision does this support" invites a genuinely useful answer you can design around.
Data availability has nothing to do with decision relevance. A dashboard that includes a metric purely because it was easy to pull usually crowds out attention from the metrics that actually matter to the decision at hand.
Separate pages within one file, each with its own headline metric and layout logic, generally works better than one page trying to satisfy every audience's different priorities at once.
Usually yes, in a smaller supporting position beneath the headline number, since a single current-period number can't show whether the situation is stable, improving, or quietly deteriorating.
It wastes the sort order's analytical value. Sorting by distance from target, or by size of change, surfaces the regions or categories that actually need attention first, rather than making the viewer scan the whole list to find them.
A useful signal is whether the intended audience returns to it when making the decision it was designed to support, without needing to be reminded. That's not proof on its own—a dashboard can be opened out of habit without actually informing a decision—but a dashboard genuinely tied to a real decision tends to get used this way more often than one that isn't.
Pick a public company's investor relations numbers or a project dataset, invent a specific decision a fictional executive would need to make from it, and design the dashboard around that decision rather than around the data alone; the beginner project ideas linked above include a sales dashboard build that works well for exactly this kind of practice.