System

Dashboard Design as Information Architecture

Redesigning 8 dashboards by removing 62% of visual elements reduced decision time from 12 minutes to 4.3 minutes. Dashboards should communicate, not display.

Applying Edward Tufte’s data-ink ratio and the Stoic principle of clarity over ornamentation, I redesigned 8 executive dashboards. The redesigned dashboards reduced average decision time from 12 minutes to 4.3 minutes per review session, not by adding features but by removing 62% of visual elements that communicated nothing.

Why do most dashboards fail to communicate?

Most dashboards fail because they are designed as data displays rather than communication tools, optimized for showing everything the data contains rather than answering the specific questions their audience needs resolved.

I audited 23 dashboards across 4 organizations in 2024. Of the 23, only 6 had a documented purpose statement answering “What decision does this dashboard support?” The remaining 17 were built to “show the data” without a defined communication goal. The result was predictable: cluttered screens with 15 to 30 visual elements, each technically accurate, collectively unintelligible.

One executive revenue dashboard contained 27 charts, 4 filter controls, 3 date selectors, and a scrollable data table. The executive who used it told me: “I look at 3 numbers and ignore the rest.” Those 3 numbers (monthly recurring revenue, net retention rate, and pipeline coverage ratio) were buried among 24 other visualizations that served no function in the executive’s decision process.

What is the data-ink ratio, and how do you apply it to dashboards?

Edward Tufte’s data-ink ratio measures the proportion of ink on a page that represents data versus ink that represents decoration, and applying it to dashboards means eliminating every visual element that does not directly support the viewer’s decision.

Tufte defined data-ink as the non-erasable core of a graphic, the ink that, if removed, would reduce the information communicated. Applied to dashboards, this means: gridlines that don’t aid value reading should be removed. Chart borders that don’t distinguish content areas should be removed. Legend entries for single-series charts should be removed. Axis labels for obvious time series (“January, February, March”) should be simplified. Color that doesn’t encode data should be muted to gray.

Step-by-step application framework:

  • Step 1: Define the decision. Write one sentence: “This dashboard helps [role] decide [action] by showing [2-4 metrics].” If you cannot write this sentence, the dashboard has no clear purpose
  • Step 2: Identify primary metrics. List the 2 to 4 numbers that directly inform the decision. These get prominent placement: large type, top-left position, minimal surrounding decoration
  • Step 3: Identify supporting context. For each primary metric, identify the 1 to 2 contextual views that explain why the metric has its current value (trend line, breakdown by dimension, comparison to target)
  • Step 4: Remove everything else. Every chart, table, and visual element that is not a primary metric or supporting context should be removed or moved to a separate detail view accessible via drill-down
  • Step 5: Minimize non-data elements. For every remaining chart, remove gridlines (or reduce to 2-3 reference lines), remove chart borders, remove legends that can be replaced by direct labels, simplify axis formatting, and reduce color palette to 2-3 meaningful hues plus gray

How does the Stoic value of clarity apply to information design?

The Stoic commitment to clarity, saying exactly what is true and nothing more, translates directly to dashboard design: every element should convey meaning, and anything that does not convey meaning is not neutral but actively harmful because it competes for the viewer’s attention.

Marcus Aurelius wrote: “If it is not right, do not do it. If it is not true, do not say it.” Applied to dashboards: if a chart does not support a decision, do not display it. If a number does not represent something the viewer needs to know, do not show it. Silence is not emptiness; it is the space that allows what matters to be heard.

I redesigned a pipeline health dashboard using this principle. The original had 18 visualizations including a real-time task execution timeline, a historical completion rate chart, a resource utilization gauge, an error distribution heatmap, and 14 other views. The redesigned version had 4 elements: a current status indicator (green/yellow/red with the specific issue description), a 7-day trend of SLA compliance, the 3 most recent failures with root cause, and the next scheduled maintenance window.

The on-call engineer who used this dashboard said: “I can now tell in 3 seconds whether I need to act.” The previous version required scrolling through 18 charts to reach the same conclusion.

How do you structure dashboard hierarchy for different audiences?

Dashboard hierarchy should follow the inverted pyramid: executives see 3 to 4 summary metrics, managers see breakdowns and trends, and analysts see detail tables and filters, with each level accessible from the one above but never cluttering it.

  • Level 1 (Executive): 3-4 large-format KPIs with directional indicators (up/down, on-track/off-track). No charts. No tables. Decision time target: under 30 seconds
  • Level 2 (Manager): Each Level 1 KPI expands to show trend (sparkline or 12-week chart), breakdown by primary dimension (region, product, team), and comparison to target or prior period. 6-8 visual elements total. Decision time target: under 3 minutes
  • Level 3 (Analyst): Full detail with filters, date range selectors, exportable tables, and cross-dimensional analysis. No limit on complexity because the audience has analytical skill and exploratory intent
  • Navigation rule: Each level links to the level below through click-through. Never combine levels on a single screen. The most common dashboard failure is showing Level 3 detail to a Level 1 audience

What are the most common dashboard anti-patterns?

The 5 most common anti-patterns are: dual-axis charts that create false correlations, pie charts for more than 3 categories, traffic-light indicators without thresholds, real-time refresh on metrics that change daily, and dashboards that default to “all time” date ranges.

  • Dual-axis deception: Two Y-axes on the same chart allow arbitrary scaling that creates visual correlations between unrelated metrics. I found a dashboard where revenue and headcount appeared perfectly correlated because the axes were scaled to align. The actual correlation coefficient was 0.12
  • Pie chart overuse: Pie charts are effective for showing 2-3 part-to-whole relationships. For 4 or more categories, a horizontal bar chart communicates the same information with less cognitive load and more precise comparison
  • Meaningless traffic lights: Red/yellow/green indicators without documented thresholds create the illusion of monitoring without the substance. Every status indicator should have a tooltip or footnote explaining: “Green means X metric is above Y threshold, measured over Z period”
  • False urgency refresh: Dashboards that refresh every 30 seconds for metrics that change meaningfully once per day create anxiety without information. Match refresh rate to the metric’s meaningful change frequency
  • Unbounded date ranges: “All time” defaults obscure recent trends by compressing them against years of historical data. Default to the most relevant analysis window (last 4 weeks, current quarter) and provide date range selection for deeper exploration

A dashboard is not a window into data. It is an argument about what matters. Every element on the screen asserts: “This deserves your attention.” The discipline of dashboard design is the discipline of deciding what deserves attention and what does not, then having the courage to exclude the rest. Tufte called it maximizing the data-ink ratio. The Stoics called it clarity. The practice is the same: say what is true, show what matters, and let everything else fall away.

adam@adam-analytics.com writes about AI systems, software architecture, and the philosophy of technology at .