Dashboard

Origin & evolution

The dashboard descends from the executive information systems of the 1980s, which promised senior managers a screen of key indicators drawn from across the business. The form became consumerised in the early 2000s as business-intelligence tools made charts cheap to produce, and the cheapness was the problem: screens filled with gauges, 3D pie charts, and decorative chrome that buried the signal.

Stephen Few set the design discipline. In Information Dashboard Design (2006) he defined a dashboard as "a visual display of the most important information needed to achieve one or more objectives🏁ObjectiveStrategyA strategic goal (OKR)View reference →, consolidated on a single screen so it can be monitored at a glance." Few spent much of the book defending that definition by exclusion, naming what a dashboard is not: not a report, not an exploratory analysis tool, not a portal, not a scorecard. His rules, single screen, summary and exception over detail, minimal non-data ink, came directly from Edward Tufte's data-ink principle applied to the monitoring case.

A second correction came from the startup world. Eric Ries popularised the term vanity metric for figures that "make you feel good but don't offer clear guidance for what to do", registered users, raw pageviews, cumulative totals that only ever climb. A dashboard packed with vanity metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference → passes Few's aesthetic test and still fails its purpose, because no number on it implies an action. Current practice merges both lessons: a good dashboard is sparse, scannable, and built from metrics that, when they move, tell someone what to do next.

How it works in practice

A subscription🔂SubscriptionSales & RevenueA recurring subscriptionView reference → team runs a weekly health dashboard. An early version showed total signups since launch, a number that only rose, a world map of users, and a revenue figure with no comparison. It looked healthy and told the team nothing. The redesign cut to four tiles: weekly active accounts against last week, trial-to-paid conversion against a 12% target, week-four retention by cohort👥CohortGrowthA group of users sharing a common characteristicView reference →, and net revenue retention. Each tile compares to a target or a prior period, so a glance reveals not just the value but whether it is good. When conversion dips to 9% one week, the dashboard surfaces it in red, the team drills into the linked report behind that tile, and finds a broken checkout step. The cumulative-signups number, impressive and inert, never returned.

Dashboard vs. its neighbours

• Report is built for reading, often paginated, detailed, and consumed once. A dashboard is built for repeated monitoring, summarised, and consumed at a glance. A report answers "what happened in Q1 in full"; a dashboard answers "is anything wrong right now". The graph holds detail behind the glance through dashboard_contains_reportDashboardcontainsReporthierarchy.
• Metric is a single measured quantity; a dashboard is a curated arrangement of several, chosen and laid out for one audience and purpose. The metric is the ingredient; the dashboard is the composed dish. The edge dashboard_tracks_metricDashboardtracksMetriccross-domain records which metrics a given dashboard surfaces.
• Data product🎁Data ProductData & AnalyticsA curated, reusable data assetView reference → is the engineered pipeline (a model, a serving table, an API) that produces trustworthy numbers. A dashboard is one consumer of that output, the presentation layer a data product feeds via data_product_serves_dashboardData ProductservesDashboardcross-domain.

In the graph

In the Unified Product Graph, a dashboard sits in the data and analytics region as a presentation node. It composes lower-level entities (dashboard_contains_reportDashboardcontainsReporthierarchy), surfaces the measures it monitors (dashboard_tracks_metricDashboardtracksMetriccross-domain), draws its numbers from upstream pipelines (data_product_serves_dashboardData ProductservesDashboardcross-domain), and can show live experiment🧫ExperimentValidationA test designed to validate a hypothesisView reference → results through dashboard_contains_experiment_runDashboardcontainsExperiment Runhierarchy. Products link to it via product_visualised_in_dashboardProductvisualised inDashboardhierarchy. That structure makes the vanity-metric trap queryable: a tile tracking a metric that connects to no objective or decision stands out as decoration, and the graph can flag a dashboard whose metrics lead nowhere.