A dashboard should read in the same order as the decision it supports: check, locate, then decide
Aliases: information architecture order · decision flow
What it is
Users open a dashboard not to "look at data" but to answer a specific question and act on it. That question has an inherent step chain: first check whether the overall picture is normal, then find where the anomaly is, then what caused it, then decide what to do. When the dashboard's information sequence follows this decision chain—conclusion first, detail behind—the user's reading path flows naturally; when the order misaligns (conclusion buried at the end, detail blocking the start), users are forced into repeated jumps, each one draining attention.
Why it happens
The friction from misalignment comes from working memory's capacity limit: information gathered at step N needs to remain available at step N+1, but if what the next step requires is not in the current field of view, the context in working memory degrades during the jump—especially numeric precision, which after a few seconds decays to "roughly higher than before." When the order aligns with the decision chain, each step's information sits in the neighborhood of the previous step's, requiring no cross-page memory. This matters most in multi-metric dashboards: if the dashboard is organized by data source (all of database A's metrics first, then all of database B's) while the user's decision flow crosses sources (latency from both A and B first, then A's throughput), the user ping-pongs between two regions. Organizing by decision flow means the dashboard's sections correspond to the user's task stages, not to the backend's data structures—engineers naturally organize by data model, but that is an engineering constraint, not the user's cognitive model.
Where it stops holding
Decision order is not shared by all users: junior operations staff need the conclusion first ("should I worry?"), while data analysts may start from the raw distribution ("is this data trustworthy?"). When a dashboard serves multiple roles, no single correct order exists—offer role-specific views or user-defined arrangement. The decision chain itself shifts with context: routine patrol and incident triage follow different step chains, and a dashboard serving both requires an unavoidable layout compromise.
Applying it
- Before laying out, write the user's decision chain: what question gets answered first, then what, and which metrics each step needs.
- Arrange dashboard sections along the decision chain; name each section with the user's question, not the data source's name.
- Verification: observe a first-time user completing a typical task on the dashboard; if the browsing path frequently backtracks, the order does not match the decision flow.
Related
- Same group: U7.07.1 Important metrics should occupy the primary visual position · U7.07.3 One-screen capacity is bounded by interpretation ability
- Nearby: U7.07.1 Important metrics should occupy the primary visual position · U1.01.2 Clarify the question before choosing the chart
- Search terms:
information architecture·task flow·progressive disclosure