11 Dashboard Design Decisions That Decide If It Gets Used

A dashboard nobody opens is almost never a data problem. The numbers were right, the tool was capable, and the thing still died in a folder three weeks after launch.

What kills it is a short list of decisions, most of them made before anyone opens Power BI. Eleven of them below, and what I'd choose for each.

Most lists of dashboard design best practices give all eleven the same weight. Two of them decide whether the dashboard gets opened at all. The other nine decide how good it feels once somebody does, which is a smaller job than it sounds.

---

1. Start With a Question, Not a Dataset

The first decision lands before you open Power BI, Tableau or Looker Studio: what question this dashboard answers.

One dashboard, one primary question.

"Sales performance" is not a question. "Are we on track to hit quarterly revenue, and which deals are at risk?" is one, and the difference decides everything downstream, from which metrics make the page to how far the detail goes.

Write the question at the top of the requirements doc. Every chart after that has to earn its place against it, and a chart that doesn't help answer it belongs on a different dashboard.

The way to get that question out of a stakeholder is to ask what they will do differently once they can see this. If the answer takes longer than a sentence, you have found the gap while it is still free to fix. If there is no answer at all, they have asked for a report rather than a dashboard, and a report gets specified with a different document.

---

2. Know Your Audience

A dashboard for a CFO and a dashboard for an operations manager share a dataset and nothing else.

The CFO wants three to five high-level KPIs, a trend direction, and one signal: on track, or not. Executives are not asking for an exploration tool. They want that answered on arrival and then they want the page to get out of the way, which is why every filter you add to an executive view costs more than it returns.

The operations manager wants the opposite and has good reason to: drill-down, filter controls, a breakdown by team or region, enough detail to act on before lunch.

Build for nobody in particular and you get a compromise that serves neither of them.

Five questions worth settling before you sketch anything:

• What is their job title and primary responsibility?
• How often will they look at this? (Real-time, daily, weekly, monthly?)
• What decision do they make when they open it?
• What's their data literacy level? (Can they read a scatter plot? Do they know what a rolling 30-day average is?)
• Do they view this on desktop, mobile, or both?

Those five answers settle most of the arguments that turn up later in the build.

---

3. Limit Your Metrics

The KPI count follows the audience: 3–5 for executives, 5–7 for managers, 7–9 for operational teams. (Full reasoning in how many KPIs should be on a dashboard.)

Every metric on the page competes with the ones already there. Past the top of your audience's range, people scan instead of read, and the signal you cared about goes by at the same speed as everything around it.

The instinct to add is easy to understand. Every metric looks important when you are close to the data. From the other side of the screen it reads as a wall.

So the work is in cutting. For each metric, ask what the reader does differently when the number moves. If the answer is nothing, or that they would like to be aware of it, it belongs on a drill-through rather than the front page.

My own test is narrower: every card earns its place by showing direction, not just a value. That is the whole argument in how many KPIs belong on a dashboard, and it decides more cards than any counting rule does.

KPI Card Hierarchy

When several KPIs earn their place, rank them on the page:

1. Hero KPI, top-left and largest. The one number the dashboard exists for: revenue against target, active incidents, open deals.
2. Row KPIs, next in visual weight. Three to five metrics that give the hero number its context.
3. Secondary metrics, smaller and lower. The numbers somebody reaches for occasionally and never opens the page to see.

---

4. Choose the Right Chart Type

Chart choice is where the mistakes stay quiet. Nothing errors out, and the reader ends up working harder than they should for a number a different chart would have handed over.

The Core Chart Types and When to Use Them

Two of those rows are worth arguing about. Past five slices a pie stops being readable and a bar chart does the job better. And a scatter plot on an executive page asks the reader to learn a chart before they can read it, which is the one thing that page has no room for.

---

5. Layout and Visual Hierarchy

Same blocks, same colours. On the right the headline number sits where the eye arrives last.

This is the decision I'd defend hardest. Colour is worth an afternoon; layout is worth the day, because layout is what decides whether the primary question gets answered in three seconds or not at all.

Readers cross a dashboard the way they read a page, starting top-left and running down the left edge, with the bottom-right getting whatever attention is left over. Nielsen Norman Group's eye-tracking studies (opens in a new tab) documented this as the F-pattern, where attention concentrates along the top and down the left edge and thins out toward the bottom-right.

The F-Pattern Layout

The top-left zone is read first and read most.

Order the page by importance:

1. Top row: primary KPIs, visible without scrolling.
2. Upper main area: the one or two charts that tell the primary story.
3. Lower main area: supporting charts and secondary breakdowns.
4. Bottom or sidebar: tables, filters, supplementary detail.

Put the number somebody came for in the zone they read first, and let the rest fall in the order you want it read.

Grid Alignment

Charts that don't line up read as noise, and most people can't say why. Snap every card and chart to one grid. Twelve and sixteen column grids both divide cleanly into halves, thirds and quarters, which covers almost every arrangement you will want.

Size differences say something whether you mean them or not. A chart twice the width of its neighbours claims to be twice as important, so make sure it is.

White Space

White space is not wasted space. This is the practical side of Edward Tufte's data-ink ratio, the principle from The Visual Display of Quantitative Information that every drop of ink on the page should carry information, and non-data ink should be erased "within reason." Stephen Few adapted the idea specifically for dashboards in Information Dashboard Design (opens in a new tab): strip the chart junk, and the signal stands out. Space is what lets the eye tell one element from the next, and a page that spends every available pixel feels overwhelming even when the data on it is fine.

Minimum padding: 16px between cards, 24-32px between sections.

---

6. Color

Color is the most misused tool in dashboard design. Three ways it goes wrong:

• A different color for every series, until the chart is a rainbow
• Red and green carrying the whole message, with nothing behind them for the readers who can't separate the two (around 8% of men)
• Color as decoration, on elements that mean nothing by it

How to Use Color on a Dashboard

Encode meaning with it and nothing else. Red and green work for status when you also add a symbol (+, -, ↑, ↓). A single hue at varying saturation works for magnitude, light for low and dark for high. Categorical colors work for series that differ in kind, up to five or seven of them.

Then keep the vocabulary fixed. Across a set of dashboards the same color has to mean the same thing every time. If blue is actual and orange is target on one page, they are actual and target on all of them.

Default to neutral. Most chart elements belong in gray or blue-gray, with the accent reserved for the element you want read first. One bright color carries. Five cancel each other out.

Colour blindness, most commonly the red-green type, affects about 1 in 12 men (8%) and 1 in 200 women (opens in a new tab), per Colour Blindness Awareness. Back every critical status with a shape, an icon or text. "Revenue: $1.2M ↑ 8%" still reads in grayscale.

---

7. Text, Labels, and Annotations

Text is where dashboards most often fall short, and it is the cheapest part of the page to fix.

• Abbreviations. "NRR δ vs LY" means something to whoever built it and nothing to anyone else. Write it out: Net Revenue Retention, change vs last year.
• Missing units. Dollars, thousands, percent? Put it in the label or the title.
• Unlabeled axes. An unlabeled Y-axis asks the reader to guess what they are reading.
• No freshness stamp. Add "Last updated: [timestamp]" to every dashboard. On an operational page it is the difference between acting on live numbers and acting on a three-day-old snapshot.

Annotation Tips

• Annotate any spike, dip or anomaly on the chart itself. "Spike due to holiday promotion" saves the reader the investigation that a mysterious peak starts.
• Use the metric card subtitle to define the metric. "Revenue" is ambiguous. "Recognized revenue, excl. refunds" is not.

---

8. Filters and Interactivity

Ten filter controls do not make a dashboard more useful. Each one is a question you handed back to the reader.

Where filters earn their place:

• Put them in the same spot on every dashboard, along the top or down a left sidebar
• Show the current filter state where it can't be missed, so nobody reads a subset as the whole
• Default to the view most people want rather than to all data. An executive usually wants the current quarter on arrival
• Keep it to three to five primary filters

Interactivity has the same problem. A cross-filter that redraws every chart when somebody clicks a bar looks useful in a demo and surprises the people who did not build it. Watch one real user click through it before launch.

---

9. Mobile and Responsive Design

More executives read dashboards on a phone than most analysts plan for. A dashboard that looks right on a 27-inch monitor and unreadable on a phone is a dashboard those people stop opening.

Check the screen your audience has before you check anything else. Power BI's 1280×720 canvas is a guess about somebody else's monitor, almost nobody verifies it, and the complaint arrives later as "why do I have to scroll?"

Mobile checklist:

• Check at 375px and 768px viewport widths
• KPI cards stack vertically on mobile
• Body text at least 14px, KPI numbers 24px or larger
• Touch targets (filter controls, clickable elements) at least 44×44px
• Tables scroll horizontally rather than compressing to illegibility

If your users are all desk-based, this drops down the list. If any of them are field reps or executives checking something between meetings, it moves up.

---

10. Performance

People stop opening a dashboard that makes them wait, and five seconds is about the limit I would design to. Most of what puts you over it was decided before anyone opened the design view.

Most slow dashboards are slow because of the model underneath. No amount of layout work rescues a bad star schema, and design advice that ignores this is a large part of why so many reports stay slow.

Design still has one lever here, and it is the number of visuals on the page. Every visual fires its own query, so the familiar eight-to-ten guidance is a query budget that happens to also help readability. Framed as "don't clutter your dashboard" it sounds like taste, and taste is easy to overrule.

---

11. Whether to Wireframe First

A wireframe is a low-fidelity sketch of the layout, made before anything gets built. It does three specific things:

1. The layout and KPI selection get checked while changing them is still cheap
2. The gap between what the stakeholder asked for and what they need shows up early
3. You find out whether you're trying to fit too much onto one page

It takes 15 to 30 minutes. Whether that trade is worth it depends on what rework costs you, and that's a different number for a two-person team than for a BI group with a six-week queue.

One thing to watch if you sketch with an AI tool or a design tool: keep it rough. Both of them will hand you something that looks shippable, and a layout that looks shippable collects agreement instead of corrections. You want the reviewer arguing about where the number sits, not admiring the spacing.

How to wireframe a dashboard: step-by-step guide →

If you need a starting point rather than a blank canvas, there are pre-built wireframe templates available for common use cases:

• Power BI Sales Dashboard Wireframe Template
• Tableau Executive Dashboard Wireframe
• Looker Studio Marketing Analytics Wireframe

---

Quick Reference: Dashboard Design Checklist

Before the Build

• Primary question defined and written down
• Primary user identified (specific role, not "the team")
• Metrics list created and reviewed with stakeholder
• Layout agreed with the stakeholder, in whatever form you showed it
• Requirements doc completed

During the Build

• 3-7 KPIs maximum on the primary view
• Chart types match the data comparison
• Visual hierarchy reflects metric importance
• Color used for meaning, not decoration
• All labels, units, and axes labeled
• Date range and filter state visible

Before Launch

• Tested with at least one naive user
• Mobile/tablet view checked
• Data freshness indicator added
• Performance tested (target: under 5 seconds)
• Labels checked for insider jargon

---

Which of these actually decide it

You don't make eleven decisions in order. You make three or four of them well, skip the rest, and find out which ones you skipped when the dashboard goes quiet a month later.

Dashboards fail from misalignment far more often than from bad chart types. Which means the first two decisions, the question and the audience, carry more weight than the eight that follow. A dashboard with mediocre charts answering the right question gets opened. A beautiful one answering nobody's question does not.

None of this needs design training. It needs the first two decisions made out loud, with the person who asked for the dashboard in the room.

The 7 mistakes these decisions prevent →

The checklist for the first two →