A dashboard is not a collection of charts. It is a decision support system. The question it should answer is not what does the data look like, but what should I do next, and why.
This distinction matters because it changes the design criteria. A chart collection is evaluated on completeness — does it show all the metrics? A decision support system is evaluated on relevance — does it surface the right information at the right moment to support the right decision?
The four most common dashboard failures
1. The data is wrong
The most common dashboard failure is invisible: the numbers are wrong, but nobody knows. Data pipelines have bugs. Source systems have data quality issues. Business logic is implemented inconsistently across multiple pipelines. The dashboard displays confident numbers that are subtly incorrect.
The symptom is often a user who cross-references the dashboard against a spreadsheet and finds discrepancies. At that point, the dashboard is no longer trusted. A distrusted dashboard is worse than no dashboard, because it introduces uncertainty into decisions that should be clear.
2. The wrong metrics
Dashboards are often built bottom-up: what data do we have, and what can we visualize? The result is a dashboard full of available metrics, very few of which are decision-relevant. The correct approach is top-down: what decisions does this dashboard support, and what information would change those decisions?
3. No time intelligence
Most business metrics are only useful in context. Revenue of €240,000 this month means nothing without knowing whether that is 20% up or 40% down from last month, from last year, or from plan. Dashboards that display absolute values without trend context produce false confidence or false alarm.
4. Too much information
The fastest path to an unused dashboard is to include every metric the client asked for. When every metric is highlighted, nothing is highlighted. Visual hierarchy — size, position, color weight — must be used deliberately to direct attention to what matters most.
The most dangerous dashboard is one that looks credible but measures the wrong things.
The data model requirements for good dashboards
Most dashboard failures trace back to a data model designed for transaction processing, not analysis. OLTP databases — the kind that power applications — are optimized for fast reads and writes of individual records. Analytical queries — aggregations over time, cross-dimensional comparisons, funnel analysis — are expensive on transactional schemas.
The solution is not always a full data warehouse. For smaller datasets, a well-designed aggregation layer can run on the same database. For larger datasets, a separate analytical store is necessary. The key decision is whether the data model supports the required analytical queries — not whether it stores all the data.
Metrics design as a discipline
Metrics are not pulled from databases. They are defined by business stakeholders, then implemented in data systems. The definition matters as much as the implementation.
The most durable dashboards are built after a metrics design session — a structured conversation with the decision-makers who will use the dashboard, where each metric is defined, named, scoped, and agreed upon before a single query is written.