A dashboard that people actually use

A useful dashboard has defined audiences, answers specific questions, and supports a decision or response. The main view needs a clear hierarchy; details can sit lower down or in separate views for different roles.

That difference has nothing to do with technology. It comes from designing a panel around a question, not around available data.

Why dashboards die

Four common causes:

1. They have no audience. A panel “for everyone” answers nobody’s question. Everyone looks once, finds nothing for them, and does not return.
2. There are too many charts. Attention is finite. A large number of equally important indicators makes it hard to see which one needs action.
3. The data is stale or uncertain. An unexplained discrepancy erodes trust. Visible source status, agreed definitions, and documented corrections can restore it.
4. Nobody knows what to do with what they see. A chart shows a decline — then what? A panel without a reference point or a definition of normal does not lead to action.

Seven principles that fix this

1. One view, a defined audience, and a question

Before designing anything, ask: who will look at it and what decision will they make from it? “Management, so they know what is happening” is not enough. Get to something concrete, such as “the sales lead decides on Monday morning what to focus on this week”.

Different audiences may use the same data and definitions but need different views, levels of detail, and update frequencies.

2. Put the answer at the entrance

The most important number should be easy to find and shown with context appropriate to the decision, such as the previous period or target. “Sales: 240k” is often insufficient; “240k, 12% below last month, against a target of 280k” makes the deviation much easier to assess.

3. Keep the first view to a limited set of indicators

Put the rest lower down or in a detailed view. An indicator belongs in the main view only if it answers the audience’s question, has a trustworthy definition, and leads to action — the same test is described in our article about vanity metrics.

4. Make data status visible

Show when data was last updated and whether a source has stopped responding. It looks like a detail but is a foundation of trust: a panel that displays the last known data without a warning can mislead its audience. “Data from 6:00 a.m.; source X unavailable” is useful information, not a defect.

5. Use context, not a chart alone

Choose a reference point that fits the decision: the previous period, the same period last year for seasonal work, or an agreed operating range. Without appropriate context, direction alone says little — rising cost may be a problem, while fewer tickets after automation may be a success.

6. Allow a route to detail

An indicator says that something happened, but some decisions need causal context. The view should then lead to the relevant breakdown, source records, or a documented diagnostic path. Not every audience needs a full drill-down, but the way to verify a number must be known.

7. Use the same definitions for everyone discussing the result

If two people arrive with different definitions of a number, the meeting becomes a debate about data. Views may differ, but they should use the same versioned definitions, update-time information, and correction rules.

What actually takes time in this kind of project

Scope depends on the state of the data, but it is worth pricing these areas separately:

Stage	What affects the work
Agreeing questions and indicators	number of roles, decisions, and conflicting definitions
Data access and collectors	number of sources, APIs, quality, and freshness
Cleaning up and agreeing definitions	missing data owners, duplicates, correction rules
Dashboard interface	number of views, accessibility, filters, and drill-down

The frequent difficulty is hidden in the third row: “sales” can mean two different things in two systems (tax included or excluded, order date or invoice date, returns included or excluded). A delivery team can facilitate agreement on definitions, but the client-side process owner should approve the meaning of each indicator.

How we know it works

Not from declarations, but from use. After delivery we measure:

• who visits and how often — after a window covering several planned decision cycles, no use is a signal to revisit the audience question;
• which indicators are viewed and which are not — the latter leave the main view;
• whether manual reporting has disappeared — if someone still assembles a spreadsheet, the dashboard did not answer their question.

Each signal answers something different: visits show adoption, view use shows fit, and the disappearance of manual reporting shows whether the prior process was replaced.

When a dashboard is not the answer

• When the question is asked rarely and does not need continuous alerting. An on-demand report may be cheaper than a panel maintained in the background.
• When data first needs to be collected. The first project is then a reliable layer for collection, definitions, and data-quality control; a dashboard comes next. We design that work within data and analytics.
• When the problem is a lack of decisions, not data. A panel cannot force anyone to decide. A company may already have all the numbers and simply not use them.
• When questions concern content rather than numbers. “What is in this contract?” is a job for a second brain, not a dashboard.

How much does it cost?

Our ranges as of August 2026: a dashboard integrating several sources 15,000–40,000 PLN net, an analytics platform with collectors and automated reporting 40,000–120,000 PLN net, a predictive layer as a module from 20,000 PLN net, and maintenance 2,000–7,000 PLN net/month.

Pricing moves with the number and quality of data sources, the need to agree definitions, required data freshness (once a day or near real-time), and the size of history to retain.

Frequently asked questions

Is a ready-made reporting tool not cheaper?

Often it is. Ready-made tools can connect many sources and perform advanced calculations, so compare connectors, licensing model, permissions, ability to version logic, and team skills. A dedicated panel makes sense when a specific requirement does not fit those limits or ownership of the interface is part of the product.

How fresh does the data need to be?

That is a business and technical decision. Near-real-time data may require different architecture, monitoring, and handling of delayed events. The question is what decision you would make differently with data from a minute ago rather than a day ago — and what that difference is worth.

Can forecasts be added?

Yes, as a separate module, if there is sufficiently long, reliable history for the phenomenon and a way to evaluate forecasts on data outside training. First define the decision horizon, reference point, and cost of error; a trend chart alone is not yet a useful forecast.

---

We maintain our own analytics and prediction platform on TimescaleDB, with monitored collectors and periodic reporting. Interruptions are possible; we design alerts and gap backfilling so they are visible and handled. See data and analytics and our platform.