Theme

Wireframe reference, version 4

The Anatomy of a Dashboard

Nine regions, the questions to settle before you draw any of them, and the four data states each region has to survive. The specimen below is one coherent analytical dashboard rather than a menu of every possible part: an example that shows everything at once teaches you to design dashboards that show everything at once.

Scope
Generic reference, not tied to one product
Audience
Anyone who designs, builds or reviews dashboards
Sources
Eight, cited in the text as [1] to [8] and listed at the end with how each was used
Reading order
Left to right. Mirror it for Arabic and Hebrew
Out of scope
Five things, named in the closing section

Settle these before drawing anything

Layout is the second question. A dashboard that gets these six wrong cannot be rescued by good typography, and every one of them changes what the regions below should contain.

  1. Which decision does this support, and who makes it?

    Name the decision and the person. If neither can be named, the dashboard is a report and should be built as one.

    Regions with no decision behind them are decoration.

  2. How often is it read, and under what pressure?

    Read hourly by someone on shift, or weekly in a review meeting. This single answer decides almost everything else.

    See the two-modes table further down.

  3. Must it fit one screen?

    Stephen Few's definition of a dashboard requires a single screen. If the content will not fit, decide now whether to cut it or to accept that this is a page and not a dashboard.

    The specimen below scrolls, and so is a page by Stephen Few's definition.

  4. What is the comparison baseline?

    Previous period, or the same period last year. For anything seasonal, including anything in education, previous period is actively misleading.

    Pick one, state it on the screen, and keep it consistent.

  5. Whose week and whose clock?

    Week start, timezone and whether the current period is complete. This causes more disputed numbers than chart choice ever does.

    A partial final period reads as a collapse. Mark it or exclude it.

  6. How many metrics can earn a place?

    Decide the ceiling before you fill the space. Four to six summary figures is a workable default. Anything beyond that is a list, not a summary.

    Space that exists will be filled unless a number says stop.

The specimen

An analytical dashboard: read weekly, scoped to twelve complete ISO weeks, the Monday-start numbered weeks of ISO 8601, with comparison against the previous week stated on the card. In the wireframe, a solid circled number marks one of the nine regions; an outlined circle marks a detail inside the region whose number it repeats. Every figure below reconciles with every other figure, because a reference document is judged on its example.

A solid marker numbers a region. An outlined marker carries the same number as its region and points to a detail within it, so the outlined 3 and the outlined 4 are properties of regions 3 and 4 rather than regions of their own. There are nine regions, not eleven. The controls drawn in the specimen are illustrations and deliberately inert. The specimen is deliberately one mode only: an operational dashboard built from the same nine regions would weight them differently, as set out in the two-modes table below.

Four phases, and one concern that runs through all of them

This is one defensible reading order, not the only one. It groups the regions by the job the reader is doing at that moment: orient, read the state, understand why, act. Trust is not a phase, because it is checked continuously rather than at the end.

Phase 1

Orient

Answer where am I, what am I looking at, and how current is it, before showing a single number.

1

Header

Names the workspace, states how current the data is and how often it refreshes, and gives one search entry point. Freshness belongs here because a number's age changes how you read it.

Practice convention. No usability source claims this.

2

Filter and control bar

Persistent, never hidden in a dialog, and it must agree with the charts it governs. It also shows filters set elsewhere: the linked control reflects a selection made in region 5.

Linked views: IBM Carbon [4]

Phase 2

Read the state

A few seconds should be enough to know whether anything needs attention.

3

Summary strip

Four figures, each with the reference value it is judged against and a definition control for metrics whose method is arguable. Place the most important at the top of the page and follow the F pattern for the rest: the eye-tracking finding that readers sweep across the top of a page, make a shorter sweep below it, then scan down the left edge. Reading order is reversed for right-to-left languages.

Layout rule: IBM Carbon [4]. See the note on the F pattern in the sources.

3

Target and threshold are different things

A target is what you are aiming at, and missing it is information. A threshold is what triggers an alert, and crossing it demands action. Uptime is below target and marked quietly. Support backlog is over threshold and marked loudly, with the threshold stated. Direction and verdict are carried by the words higher, lower, improving and worsening. An arrow or a colour may accompany the words but never substitute for them: direction alone cannot say whether up is good, and colour alone excludes whoever cannot see it.

Encode by more than colour: WCAG 1.4.1 [6]. Colour as a secondary cue: NN/g [1]

Phase 3

Understand why

The analytical core, including the detail table. A chart shape is abstract until words anchor what it means.

4

Primary chart

One chart answers the core question. Length and position are read more accurately than angle and area, so bars and lines beat pies, donuts and gauges. Bars must start at zero because their length is the encoding. Lines need not, and forcing a zero baseline onto a metric that lives between 99% and 100% makes it unreadable. The chart-or-table toggle is not a convenience: the table is the route by which the same numbers reach screen readers and anyone else who cannot read the shape.

Encoding accuracy: Cleveland and McGill [2], as presented by NN/g [1]. Zero baseline for bars: Stephen Few [3]. Table as text alternative: WCAG 1.1.1 [6]

4

Title states the finding, caption explains the marks

The title says what happened as a sentence: "rose for a third consecutive week", not "Users over time". The caption gives the unit, the window and how to read any emphasis, and the emphasis on the chart must be exactly what the title describes. If the title and the marks disagree, readers believe the sentence.

Titles carry the takeaway: EU Data Visualisation Guide [5]. Captions are our own addition.

5

Breakdown

A ranked bar list beats a pie for comparing categories, provided the bars are drawn as true shares of the whole track. Scaling the longest bar to fill the space destroys the part-to-whole reading, which is the one thing a pie does adequately.

Encoding accuracy: Cleveland and McGill [2]

6

Written insight

A short note of what actually needs a decision, with a named author and a stated cadence. It must say what it cannot support: co-occurrence is not cause, and an unfalsifiable insight block is worse than none. An unowned one rots within a quarter.

Practice convention. Not sourced.

7

Detail table

Row-level explanation, with visible sort state and the active filters named. Its percentage column states its own denominator, because two columns labelled "share" with different denominators is the commonest way a dashboard loses an argument. Denser spacing here than anywhere else earns its place.

Compact density for data-rich views: Material Design 3 [7]

Phase 4

Act

Give the reader somewhere to go, and make sure what leaves matches what was shown.

8

Action bar

Export, share and subscribe together, so they read as things to do rather than more data to scan. Two obligations: an export must reconcile with the figures on screen, and a shared view must carry the filter state, including any cross-filter, or the recipient sees different numbers.

Practice convention. Not sourced.

Runs throughout

Trust

Checked in the first two seconds and again before anyone acts. Not a final step.

9

Provenance strip

Source table, week start, timezone, owner, review date and a route to metric definitions. The definition link is what the caption cannot carry: a caption says what is plotted, not how "active user" was counted, and that ambiguity is what derails review meetings.

Practice convention from analytics engineering, not usability research.

Partial periods and small numbers

Not a region, so it carries no marker: it is a rule the whole screen has to obey. The final bar of any period series is usually incomplete and reads as a collapse. Either exclude incomplete periods, as the specimen does by scoping to twelve complete weeks in regions 2 and 4, or mark them clearly. Where counts are small enough that a handful of users move the figure, say so rather than letting a percentage imply precision it does not have.

Practice convention. The most common way an otherwise honest dashboard misleads.

Which regions to drop

Nine regions is a vocabulary, not a target. Most good dashboards use five or six. Numbered markers mean order of reading, not order of assembly, and the test for keeping a region is always the same: name the decision it serves.

  1. Drop the breakdown (5)

    When there is no segmentation a reader would act on differently. A breakdown nobody filters by is five bars of decoration.

  2. Drop the written insight (6)

    When nobody will own writing it every cycle. An unowned insight block goes stale and then actively misleads.

  3. Drop the detail table (7)

    When the reader cannot act on a single row. If the answer to "what would you do with this row" is nothing, it is a data dump.

  4. Drop the action bar (8)

    When the reader has no authority to act. Buttons that lead nowhere teach people to ignore the region.

  5. Never drop provenance (9)

    It is the cheapest region and the one that decides whether a number gets acted on or argued with.

  6. Keep regions 1 to 4 in almost every case

    Orientation, scope, a summary and one chart is close to the minimum viable dashboard. Below that it is a figure with a caption.

Four data states, not one

Every region above needs all four specified. Slow and broken states are where trust is actually lost, and they are the states most wireframes never draw. Jakob Nielsen's ten-second limit [8] is the practical budget: past it, attention goes elsewhere and a progress indicator becomes mandatory.

  1. 1. Loaded

    The state that normally gets designed.

  2. 2. Loading

    A skeleton at the real dimensions of the label, figure and delta, so nothing moves when data lands. Past ten seconds it needs a progress indicator, not a spinner.

  3. 3. Empty

    Separate "genuinely zero" from "nothing matched your filters", and give the way out. Zero is a finding. Empty is a dead end.

  4. 4. Stale or failed

    Show the last known figure, marked plainly as old, rather than a blank or a silently current-looking number. Unmarked staleness is the failure that costs trust.

The same regions, weighted two ways

Stephen Few distinguishes three kinds of dashboard: strategic, analytical and operational. The two below diverge most in layout, and the specimen above is analytical throughout. Building a hybrid is how a dashboard ends up serving neither reader.

How emphasis shifts between operational and analytical
DimensionOperationalAnalytical
The jobNotice a deviation now and respondUnderstand what happened and decide
RefreshLive, seconds to minutesDaily or weekly. Comparison period matters more than recency
Region 3, summaryDominant. Large figures, threshold state on every cardPresent but subordinate to the charts below it
Region 2, filtersA handful, scoped to the operator's own service or regionMany. Segments, comparison periods, saved views, cross-filtering
Region 7, tableA short queue of items needing action, or absentCentral. This is where the work happens
AlertingPushed, because the reader may not be lookingA passive marker found while scanning
Failure to design againstA breach nobody noticed in timeA confident conclusion drawn from a misread chart

What this reference does not cover

Five omissions, each needing a decision before a real build.

  1. Semantic colour

    Neutral grey forces state into form and words, which is the right dependency order: a design that works in grey works for colour vision deficiency. The cost is that grey cannot carry good against bad, which is why direction is spelled out in words here. A real build needs a severity palette kept separate from the brand accent, and Stephen Few's bullet graph is the established answer for a value against a target and a qualitative range.

  2. Motion and live updates

    How a cross-filter transitions, and how a figure that updates while being read announces itself without stealing the reader's place. Live regions for auto-updating numbers remain an unsolved problem in operational dashboards. Whatever is chosen must honour a reduced-motion preference.

  3. Responsive behaviour

    Which regions fold first is a content decision, not a breakpoint decision. Charts and tables can both survive a narrow screen, via horizontal scroll or a card per row, but deciding which one leads is a product call.

  4. Real copy

    Titles that state a finding cannot be templated. "Rose for a third consecutive week" has to be computed or written each cycle, and a stale one does more harm than a plain label, because readers trust the sentence over the shape.

  5. Uncertainty and lifecycle

    Confidence intervals, small-sample suppression, who sets thresholds and how alert fatigue is managed, and when a dashboard is retired. Stamping a version number in the footer does none of this: lifecycle is a practice, not a label.

Sources, and how each was used

Each claim above names its source, or says plainly that it is practice convention with no research behind it. Several widely repeated dashboard statistics could not be traced to a primary source and were left out.

  1. Dashboards: Making Charts and Graphs Easier to Understand, Nielsen Norman Group (NN/g). Used for: operational versus analytical framing, the preference for length and position over angle and area, and colour as a secondary rather than primary cue. This article states that up to 4.5% of the general population has some form of colour vision deficiency.
  2. Cleveland, W. and McGill, R. (1984), Graphical Perception: Theory, Experimentation, and Application to the Development of Graphical Methods, Journal of the American Statistical Association, 79(387), 531–554. Used for: the accuracy ranking of visual encodings, which originates here rather than with any design system. Extended by Mackinlay (1986), Automating the Design of Graphical Presentations of Relational Information, ACM Transactions on Graphics, and replicated at scale by Heer and Bostock (2010), Crowdsourcing Graphical Perception, ACM CHI.
  3. Few, S., Information Dashboard Design (2nd ed., Analytics Press, 2013), building on Tufte, E., The Visual Display of Quantitative Information (2nd ed., Graphics Press, 2001). Used for: the single-screen definition, the three-way strategic, analytical and operational taxonomy, zero baselines for bars specifically, and the bullet graph. Note that Stephen Few argues against literal data-ink maximisation, and that the data-ink ratio, Tufte's rule that ink not spent on data should be removed, has been challenged empirically by Inbar, Tractinsky and Meyer (2007), Minimalism in Information Visualization, ECCE, so it is not treated as settled here.
  4. Dashboards, presentation versus exploration, IBM Carbon Design System. Used for: linked views that mirror filter changes across charts, drill-down, and the layout rule to place the most important element at the top of the page and follow the F pattern for the rest.
  5. Understandable chart titles, EU Data Visualisation Guide. Used for: a title should communicate what to take away, not describe the topic. It does not discuss captions, so the caption guidance above is ours and is labelled as such.
  6. Web Content Accessibility Guidelines (WCAG) 2.1, Success Criterion 1.4.1 Use of Color and Success Criterion 1.1.1 Non-text Content, W3C. Used for: the requirement that colour is never the only means of conveying information, and the requirement that non-text content has a text alternative, which is what the chart-or-table toggle satisfies. These, not a prevalence statistic, are the normative reasons to encode state in form and words.
  7. Material Design 3, layout and spacing, Google. Used for: denser spacing in data-rich views such as tables. Version 3 specifically, because Material 2 and 3 differ on density.
  8. Response Times: The 3 Important Limits, Jakob Nielsen, 1993. Used for: the ten-second limit beyond which attention moves elsewhere and a progress indicator becomes necessary. This is the defensible basis for taking loading states seriously.

A caution about the F pattern

The F pattern is often cited as a reason to place the most important element top left. Nielsen Norman Group's own research describes it as the default behaviour readers fall into when a page gives them no better cues, and argues that good design should reduce it rather than exploit it. Their studies concern prose, not summary cards, and they record a mirrored pattern in right-to-left languages.

The layout rule used above is therefore cited to IBM Carbon [4], which does prescribe it for dashboards, and not to NN/g. It is offered as a reasonable convention for left-to-right readers, not as a research finding.