Designing Dashboards People Actually Read
By CodexierPublished 6 min read
A dashboard is not a report with charts. It is a screen someone opens to decide something: call a customer, reorder stock, move a technician, stop a campaign. Dashboards fail when nobody wrote down which decisions they serve, so every metric that exists gets a tile. This guide gives a method that starts from the decision and ends with a screen people open on purpose, whether it is built in Power BI, Looker Studio or inside your own product.
Start from the decision
Interview the viewers before drawing anything. Ask what they decided last week, what information they went looking for to decide it, and what they wish they had known earlier. Write each answer as a sentence: the dispatcher decides every morning which jobs to reassign, using yesterday's overruns and today's sick leave. Those sentences are the specification, and every tile has to trace back to one of them.
Fewer numbers, more context
A number means nothing without a reference. Revenue this month is a fact; revenue this month against target and against the same month last year is a decision aid. Every tile should carry its own context, so the viewer never has to remember what good looks like.
| Instead of | Show | Why |
|---|---|---|
| Open tickets: 43 | Open tickets: 43, up 12 since Monday, target under 30 | The viewer sees direction and distance to goal at once |
| Twelve KPI tiles in a grid | Three primary numbers, the rest one click away | Attention is finite; the grid hides the important one |
| Revenue by product, pie chart | Revenue by product, sorted bar with last period as a marker | Pies cannot show change or small differences |
| Colour on every tile | Colour only where a threshold is crossed | Red that is always on stops meaning anything |
If you cannot say what action a tile triggers when it turns red, remove the tile.
Chart types that fit the question
Line: how is it changing?
Trend over time, one or few series, with the target as a flat reference line. Avoid more than four lines; split into small multiples instead.
Bar: which is bigger?
Comparison across categories, sorted by value, not alphabetically. Horizontal bars when labels are long, which they always are in Swedish.
Number with delta: where are we now?
A single status the viewer checks daily. Big number, small change indicator, threshold colour. This is most of a good operational dashboard.
Table: which ones exactly?
When the decision is about specific rows, such as which invoices are overdue, a sortable table beats any chart. Add the action link in the row.
Layout and reading order
People read a screen top left to bottom right, and they read the first row properly and the rest quickly. Put the decision-driving number top left, its explanation to the right, supporting detail below, and history at the bottom. Group by question, not by data source: the viewer does not care that two tiles come from different systems.
- One screen, no scrolling, for the operational view. Detail lives on a second page reached by clicking a tile.
- Consistent time windows across the screen. Mixing today, this week and rolling thirty days on one page is a common cause of wrong decisions.
- Label units and dates fully. Week 38 means nothing to a manager reading on a Monday; write the date range.
- Test on the device it will be used on. A warehouse screen and a phone need different layouts, not a responsive squeeze.
Alerts instead of staring
The best dashboards are rarely open. If the decision is triggered by a threshold, the system should send the alert, by mail, Teams, Slack or SMS, with the number, the threshold and a link to the screen. The dashboard then becomes the place to investigate, not the thing to watch.
- List the thresholds that would make a viewer act. If there are none, the dashboard is a report and should be scheduled as one.
- Send one alert per event, to the person who acts, with a snooze. Alerts that go to everyone get muted by everyone.
- Review alert volume monthly. More than a few per day per person means the thresholds are wrong.
For a dashboard inside your own product, this design work is what a product design sprint produces in a week: interviews, the decision list, a clickable prototype and a test with real users before anyone builds it. For an existing dashboard nobody reads, a UX audit finds why. Both are fixed prices on the pricing page.
When you do not need design help
If the dashboard is for you alone and you know what you are looking for, a Looker Studio or Excel view you build yourself is fine; the method above still applies, but you do not need us. If the real problem is that the data is wrong or arrives late, no layout fixes that; solve the pipeline first. Design help pays when many people with different roles must act on the same data, or when the dashboard is part of a product customers pay for. A short call is enough to say which case yours is.
Frequently asked questions
How many metrics should a dashboard have?
Three to five primary numbers on the first screen for one role, with supporting detail one click away. More than that and viewers scan instead of read. If two roles need different numbers, build two dashboards rather than one with fifteen tiles.
Power BI, Looker Studio or a custom dashboard?
For internal reporting on data you already have in Microsoft or Google systems, the ready tools are faster and cheaper. Build custom when the dashboard is part of your product, must match your interface, or needs actions such as reassigning a job directly from the screen.
Should we use real-time data?
Only if someone will act within minutes. Most decisions are daily or weekly, and real-time numbers on a weekly decision create anxiety without value. Match the refresh rate to the decision cadence and say on the screen when the data was last updated.
Have a dashboard nobody opens?
Bring a screenshot and the list of who uses it to a short call. We tell you which decisions it serves, which tiles to cut, and whether a design sprint or a UX audit is the right fixed-price next step.
Book a free 15-minute call