7 Common Dashboard Design Mistakes (And How to Avoid Them)

Most dashboards are never switched off. The open rate slides, the last-viewed timestamp stops moving, and a quarter later somebody asks whether anyone still uses the sales page and gets no answer.

In most of those cases the numbers were right and the BI tool was never the constraint. The damage came from design decisions: what goes on the page and where it sits. Seven go wrong often enough that I keep a list.

---

Mistake 1: Building Without a Clear Question to Answer

A dashboard should answer one primary question. "How is the business performing?" names a topic. "Are we on track to hit the quarterly revenue target, and which segments are behind?" is a question, because the answer changes what somebody does on Tuesday.

With no question at the centre, charts accumulate. Someone asks for one more breakdown in a review, it gets added, and the page becomes a data dump. The reader opens it, scans it, takes nothing away, and stops opening it.

The fix: Write the question at the top of a blank doc before you open the BI tool. Every chart you add has to help answer it, and the rest go on a different page.

Ten metrics that all feel important is usually two dashboards, each with a question of its own.

---

Mistake 2: Too Many KPIs

More metrics reads as more value in a requirements meeting and lands as more noise on the page.

The workable range depends on the audience: 3–5 KPIs for executives, 5–7 for managers, 7–9 for operational teams. The usual anchor is George Miller's 7 ± 2 (opens in a new tab), and the caveat most articles skip is that Miller measured working memory rather than visual scanning. Past the top of your audience's range, readers start skipping cards. They skip the important ones too, because nothing on the page marks which those are.

The fix: For every metric, name what the reader does differently when the number moves. If the answer is nothing, the metric belongs in a chart further down, or nowhere.

Keep the prime real estate, the top row and the large cards, for the three to five KPIs someone acts on. Secondary metrics go below the fold or on a second tab.

---

Mistake 3: Wrong Chart for the Data

Chart choice is where analysts make the mistakes nobody reports back. The chart looks reasonable and the numbers behind it are right, so a reader who struggles with it assumes the difficulty is theirs.

The most common wrong-chart mistakes:

The fix: Name the comparison the reader is making, then pick. Time against time is a line. Category against category is a bar. Part against whole is a pie, five slices at most. Value against target is a KPI card with a variance indicator. Caught between a pie and a bar, take the bar, because the eye judges length more accurately than angle or area (opens in a new tab).

Bar and line cover most of what a dashboard is asked to do. Default to one of them and you will be right more often than not.

---

Mistake 4: No Visual Hierarchy

Open a dashboard where every element carries the same size and weight, and your eye has nowhere to land. You end up reading it left to right like a page of text, which is the slowest way to read something built to be answered on sight.

Hierarchy is the part of layout that does this work, and layout is worth more on a dashboard than any amount of colour. The number that matters should be the largest thing on the page. The charts that explain it sit below it at a lower weight, and the detail stays reachable without competing.

KPI cards are where hierarchy breaks most often. They come out of the tool identical, so the metric someone gets called about at 8am looks the same as the one that gets checked once a quarter.

The fix: Three levels, decided before you place anything.

1. Primary: large KPI cards, bold numbers, high contrast
2. Secondary: medium charts, normal text
3. Tertiary: supporting tables, footnotes, filters

Most BI tools expose card size and font weight. A hero KPI at 64px above secondary metrics at 32px changes how the page reads before you touch a colour picker.

---

Mistake 5: Ignoring Filters and Context

"Revenue: $1.2M." Good or bad? Up on last month, or down against target? On its own the number states a position and settles nothing, so the reader opens a second tab to work out what it means. That is the moment the dashboard failed.

Four omissions cause most of it:

• No comparison period (vs. last month, vs. last year, vs. target)
• No visible date range for the data
• No filter state shown, so nobody knows whether they are looking at all regions or one
• Absolute numbers with no benchmark

The fix: Give every KPI card a comparison, either a percentage change against a prior period or a delta against target. Keep the date range visible and show the active filters.

Something close to: $1.2M ↑ 8% vs. last month | Jan 1 – Mar 31, 2026

One line of comparison turns a position into a direction, and direction is what someone came to the card for.

---

Mistake 6: Designing for the Creator, Not the Viewer

You know your data. You know the churn chart excludes trials, that NRR means the thing your team settled on in March, and that red on this page means late rather than bad. The viewer knows none of it, and nothing on the page teaches them.

This shows up as:

• Internal jargon or abbreviation-heavy labels ("Q1 NRR δ vs LY")
• Charts that require prior knowledge to interpret
• Drill-downs where the surface level shows almost nothing
• Colour coding that only means something if you know the internal conventions

The fix: Put it in front of someone who uses the data and did not build the page, then say nothing while they read. Wherever they pause or ask a question, you have found a label to change.

With nobody available, read your own labels aloud as if you were explaining them to a new hire. Anything that needs a spoken sentence needs an annotation on the page.

---

Mistake 7: Building Before Getting Alignment

The expensive mistake hides inside a page where nothing is broken. The refresh works, the totals match the finance export, and the dashboard answers a question nobody asked. There is nothing to debug and nothing to point at in a review, so it survives until the views drop off.

One question settles it before the build: what will you do differently after seeing this? If the stakeholder cannot answer in a sentence, the request is for a report, and reporting requirements are a different document with a different shape.

When you do put a layout in front of someone, keep it ugly. Polish reads as a decision already taken, and people mark up a sketch in ways they will not mark up something that looks signed off. Empty boxes and placeholder labels hold the discussion on where things go, which is where the mistake would be.

The fix: Get an answer to that question in writing, then show a low-fidelity layout while changing it still costs minutes.

Rough can be paper, and a dashboard wireframe is the same idea with the parts already drawn. datawirefra.me (opens in a new tab) gives you KPI cards, charts and filters you place rather than build out of rectangles, plus a link to share and no account for the person reviewing it.

---

The Checklist

Before you ship your next dashboard, run through this:

• One clear primary question the dashboard answers
• 3-7 KPIs in the top row, not 12+
• Chart type matches the comparison (see table above)
• Visual hierarchy: primary, secondary, tertiary
• Every KPI has a comparison period or vs. target
• Date range and active filters are visible
• Labels are readable by someone unfamiliar with the data
• The person who asked for it can say what they will do differently once they have it

None of the eight is hard. Each one happens before the interesting work starts, which is the reason they get skipped.

---

Where to Go From Here

The Dashboard Planning Checklist and the dashboard requirements gathering framework cover the conversation that happens before design, where mistakes 1 and 7 are cheapest to catch. For the tool-specific versions, see Power BI and Tableau.

If the layout is the part you are stuck on, the wireframing guide runs from a blank page to something a stakeholder can mark up.