Dashboards as Decision Systems

The executive question: what should a manager notice first?

Chapter 3 built the vocabulary — how to translate a business question into a comparison, which chart forms serve which comparisons, when to facet, and how to show what the data cannot support. This chapter spends that vocabulary on the artifact managers actually receive: a page of charts with somebody's name on it.

A dashboard is a sequence of business questions. Not a collection of charts, not a status report, not a data buffet — a sequence. The first panel asks an executive question, the second answers it, the third asks the natural follow-up, and so on until the page ends at a recommended action. When a manager looks at a well-built dashboard she does not scan; she reads, in the order the page is laid out, and the order makes sense.

The instinct to "show everything" is the most common failure in dashboard design. Twelve tiles, each showing a different KPI, each presented as if equally important, force the viewer to do the prioritization work the dashboard was supposed to do for her. The defense is to build the page the way an analyst writes a memo.

Three modes: monitor, diagnose, decide

Every panel on a dashboard is doing one of three jobs, and confusion between them is what makes pages feel busy but unhelpful.

Monitor asks whether something important changed. It is the only mode most dashboards ever reach, and on its own it produces a status report.

Diagnose asks where the change came from — which region, segment, cohort, or daypart is carrying it. This is where small multiples and breakdowns live.

Decide asks what action or test follows. This is the mode almost every real dashboard omits, and its absence is why so many polished pages get praised once and never opened again.

The distinction keeps the page honest in both directions. A monitor panel should not pretend to identify causes. A diagnostic panel should not stop at the pattern. A decision panel should not hide the uncertainty that qualifies it.

The arc, in six steps

The three modes expand into six concrete panels. This is the order that has worked for fifty years and will work for fifty more: the executive question on top, the KPI tile that lands the headline, the trend that puts the headline in context, the breakdowns that explain the trend, the drilldown that reaches the actionable level, and the recommended action at the bottom.

Here is the whole arc on one page — the executive question on top, then five panels reading straight down to the recommended action. Hover any chart for the underlying numbers, and notice that each panel answers the question the panel above it raises.

The six steps are not specific to a tool. They work in Looker, in Tableau, in a printed PDF, in a one-pager taped to a wall. What makes the dashboard work is not the platform; it is the sequence. Without a sequence, the same six panels are a buffet; with one, they are a memo.

The difference is entirely in the ordering. Toggle below between the buffet — the same four panels as equal tiles, with no obvious place to start — and the memo. The data never changes; only whether the page does the prioritizing for you.

Applying the arc: the soup dashboard

The Bean & Basket arc is a template. Running it against a real dashboard is where the discipline gets tested, so Figure 1 treats the Progresso soup dashboard as a critique object.

That dashboard already has four strong ingredients — monthly category volume, seasonal pricing, a store map, and category share — and an intuitive headline: demand weakens in summer while Progresso's price rises. It is a good seed precisely because the pattern is visual, memorable, and strategically uncomfortable. The redesign question is not whether it looks polished. It does. The question is whether it ends in a better managerial decision. A visual system that stops at "interesting" is unfinished.

In Figure 1, each panel is assigned a job, and each job gets an upgrade.

The strongest move in Figure 1 is the last one. A descriptive dashboard should not end by declaring that Progresso ought to lower price — it has no basis for that claim. It should end by naming what must be learned next: whether price changes caused lower volume, whether promotions or inventory explain the pattern, and which regions deserve separate pricing tests.

The deeper pathology behind all six pitfalls is the same: building dashboards from the data the team has instead of the questions the manager has. The fix is to start every dashboard project with the question, written down, before any chart template is opened. A team that does this ships dashboards that survive their first review. A team that doesn't builds beautiful tools that get closed after ninety seconds.