An analytical dashboard is built for the follow-up question, not for confirming that everything's fine
Aliases: analytical dashboard · analysis type
What it is
An analytical dashboard's job is "support the follow-up question": users do not come to confirm status but arrive with questions to take apart — why did it change, which segment drove it, how does it compare. Its design goal is exploratory capability: views that cross-reference, dimensions that switch, time that aligns, so one screen can host the loop of "pose a hypothesis, test it."
Why it happens
Depth and comparison ride on a set of interaction capabilities being in place: linking (a selection in one view highlights in another), dimension switching (the same metric decomposed along different axes), and time alignment (curves from different periods overlaid). These turn the dashboard from "a fixed chart collection" into "an operable pivot." The analytical type's information density is naturally higher — it must hold the full combination of dimensions, granularities, and comparators, and its layout serves logical structure (whole-to-part, question-to-evidence) rather than scan speed. The analytical type also pairs with state persistence: half-finished exploration must be savable and shareable (the bookmark-and-history family's conclusion), because analysis rarely completes in one sitting.
Where it stops holding
The analytical type's freedom can bite back: the more capability, the more complex the surface, and casual light users get scared off. The mitigation is layering — the default view presents the most common comparison combinations while the deep tools sit behind interaction (click to enter, mode switch). Nor does an analytical dashboard replace real analysis environments (exploratory tools, notebooks): dashboard analysis answers structured questions quickly, open-ended questions should still export to professional environments, and the surface should offer that exit at the right place.
Applying it
- Standard-equip analytical dashboards with three interactions: cross-view linking, dimension switching, and time-aligned overlay.
- Present the most common comparisons by default; tuck advanced capability behind interaction to keep the first screen scannable.
- Verification: have users complete a two-step attribution task (spot the anomaly, locate the dimension) inside the dashboard without leaving it — that is the bar.
Related
- Same group: U7.02.1 Monitoring dashboards optimise for anomaly detection · U7.02.3 Reporting dashboards optimise for conclusion delivery · U7.02.4 The three purposes differ in layout and density
- Nearby: U6.02.1 A selection in one view should sync to related views · U6.10.1 Analytical state must be encodable as a reproducible link or snapshot
- Search terms:
analytical dashboard·exploratory dashboard·self service analytics
Cards in the same group
- U7.02.1A monitoring dashboard exists so an anomaly has nowhere left to hide from whoever is checking it
- U7.02.3A reporting dashboard exists to deliver a few conclusions fast to people with no time to explore
- U7.02.4Monitoring, analytical, and reporting dashboards each demand their own layout and information density