Dashboards as decision systems, not decoration.

Walk into any large organization and ask to see “the dashboard.” You’ll find dozens. Some are beautiful. Some are tragic. Most have something in common: nobody can tell you what decision they exist to inform.

That’s the failure mode worth naming. A dashboard isn’t a report, it’s a decision system. It exists to compress the gap between what is happening and what someone should do about it. If a stakeholder can stare at a screen for thirty seconds and still not know what to do next, the dashboard has failed at its actual job, regardless of how good its color palette is.

The pivot: start with the decision

The most reliable fix is the simplest. Before you draw a single chart, write down, in plain English, the decisions a specific person owns, and the small set of indicators that meaningfully change those decisions. If a metric doesn’t change a decision, it doesn’t belong on the screen. It might belong somewhere else, but not in the cockpit.

This exercise is uncomfortable. It surfaces the metrics that exist only because someone asked for them three years ago. It exposes the dashboards that are really political artifacts, proof of effort, not instruments of decision. That’s the point.

A metric that doesn’t change a decision doesn’t belong on the cockpit. It might belong somewhere, but not there.

Three patterns we keep using

1. The single-screen rule

A decision-grade dashboard fits on one screen, at the resolution the stakeholder actually uses (often a phone in a meeting, not a 4K monitor in an office). If you can’t fit it, the dashboard is probably trying to inform too many decisions.

2. The “so what” column

Every chart earns its place by answering a “so what.” If the anomaly is real, what does the user do next? If the trend continues, what do they need to know first? Add the interpretation directly to the chart, tooltips, annotations, the small text few designers bother to write.

3. Adoption is the metric

We instrument every dashboard we ship, view counts, time on screen, interactions. After ninety days, we run a usage review. Dashboards that aren’t used get pruned, not patched. Maintaining unused surfaces is a tax on the entire data team.

What changes when you do this

The visible change is fewer dashboards. The deeper change is cultural: data stops being a status symbol and starts being a working surface. Teams argue less about whose number is right, because the metrics are tied to decisions, and the decisions have owners. The data team gets time back, real, measurable time, because they’re no longer maintaining screens that exist only to exist.

It is not a glamorous transformation. There is no slide with a robot on it. It is, however, the change that consistently pays for itself within a quarter.

A worked example: the operations huddle

One useful test case: the daily or weekly operations huddle. Whatever it’s called in your organization, the morning stand-up, the operating review, the war room, the meeting is doing what a dashboard should: looking at what happened, flagging anomalies, and assigning actions.

If you map the decisions made in that meeting, you almost always end up with fewer than ten. Then ask which metrics were referenced to make each of those decisions. The intersection, the metrics that actually changed something, is the spine of the dashboard. Everything else is decoration that crept in over time.

We’ve done this exercise enough times to predict the outcome: the new dashboard is roughly a third the size of the old one, the operations team agrees with it inside a week, and the meeting gets shorter. The unused metrics aren’t deleted; they’re moved off the cockpit and into an explore-style surface where someone can dig if needed.

What stops teams from doing this

It would be unfair to suggest this is unknown territory. Most analytics teams know they should be designing for decisions. They aren’t. The reasons cluster into a few familiar patterns.

Political legacy.Half the metrics on the dashboard exist because an executive asked for them once, three years ago. Removing them feels riskier than leaving them. The fix here is leadership cover , an explicit mandate that the dashboard’s job is to inform decisions, not to commemorate requests.

Vague stakeholder briefs.The decision-map exercise is harder than building a chart. It requires sitting with a stakeholder and asking, in plain English, “what do you actually do with this information?” Many analysts have never been given permission to ask that question.

No usage feedback loop. Without instrumentation, the team has no idea which dashboards are alive and which are zombies. Adding usage analytics is a one-week project that pays for itself in a quarter by pruning the dead surfaces.

A checklist worth using

Before you ship a new dashboard, ask:

• Who, by name, owns the decisions this informs?
• What are those decisions, in plain English?
• What action is each metric supposed to provoke if it shifts?
• Where will this be opened, phone, monitor, projector?
• How will we know if it’s being used three months from now?
• What gets deleted when this lands?

The questions are obvious. The discipline is in answering them honestly , before the build, not after.

Adoption, not aesthetics

We benchmark dashboards on two numbers: weekly active users among the stakeholders we built it for, and the artifacts it replaced (the weekly slide deck, the side-spreadsheet, the chase email). If neither moves, the project failed regardless of how clean the charts look.

That framing turns adoption into the metric the team is paid against , not the proxy metrics (data accuracy, refresh frequency, chart count) that are easier to hit and easier to fool yourself with.