Dashboard Design That Drives Decisions, Not Vanity

Tuesday, 9:47 PM. The Slack ping. "Hey, this report is wrong, our MRR is showing 4.1M but Finance says 4.3M, can you take a look?"

You open the dashboard. You haven't touched it in seven months. The owner field says "Sarah K" and Sarah left in October. There are 14 charts. Three of them claim to show MRR and they all disagree. The last viewer was three weeks ago, and it was you, opening it to share the link in this exact thread.

That ping isn't a data quality problem. It's a design problem. Probably your design problem, from a build you shipped during a sprint you've already forgotten.

Most BI tools quietly report the same number: somewhere between 60 and 80 percent of dashboards get opened fewer than five times in their entire lifetime. Looker's own usage data, Tableau Server admin logs, Hex's adoption analytics: same shape every time. The graveyard is bigger than the live floor. And every dead dashboard still costs you: warehouse query spend on the scheduled refresh, trust erosion when stakeholders find conflicting numbers, and your calendar when someone resurrects it at 9:47 PM.

This playbook is the design discipline that keeps your dashboard count flat or shrinking while stakeholder trust compounds. It's IC craft, not BI vendor theatre.

The principles that kill the kitchen sink

Before any specific rule, three principles. If you internalize these, the rest writes itself.

One decision per dashboard. Write the decision in the title. Not "Sales Overview." That's a topic, not a decision. Write "Should we reforecast Q3 sales?" or "Which AE pipelines need manager review this week?" If you can't write the decision in one sentence, you don't know what the dashboard is for, and neither will the person opening it. Topics multiply. Decisions don't.

Visual hierarchy, not visual democracy. The headline number on the dashboard should be at least 3x bigger than anything else on the page. Eye tracking studies on BI tools (Tableau Research, 2023) show users spend 60% of their first 8 seconds on the largest tile. If everything is the same size, you've told the user nothing is important. Pick the one number that answers the decision. Make it huge. Everything else is supporting evidence.

Color discipline. One accent color for the brand or the primary metric. Gray for everything else. Red and green only for variance against a target, never for categorical series. If your "Revenue by Region" chart has red, green, blue, yellow, and orange bars, you've trained the user that red means nothing. Then when red actually means "we missed plan," it doesn't land. Color is a finite budget. Most analysts blow it in the first chart.

These three are the foundation. The rest is application.

The 5 metrics rule

No dashboard ships with more than 5 primary metrics. Period.

This is the rule everyone fights and everyone is wrong to fight. The argument is always the same: "but the VP wants to see X, and Y, and also Z." Fine. Build them somewhere. Just not on the same surface as the decision.

Why 5? Cognitive load research (Miller, 1956, yes, the "magical number seven" study, refined by Cowan in 2001 to a working memory capacity of 4±1) is the floor. In a meeting, with someone presenting, with Slack pinging, the practical limit is even lower. A dashboard with 14 tiles isn't read. It's scanned. The user picks the two that look surprising and ignores the rest. You did 12 tiles of work for two tiles of attention.

The rule, applied:

If you have 5 primary metrics and someone asks for a 6th, you're building two dashboards. One serves Decision A, the other serves Decision B. Split it.
If you can't decide which 5, you haven't decided which decision the dashboard serves. Go back to step one.
Drill-downs are not metrics. A clickable headline number that opens a breakdown is one metric, not seven. Treat the surface tile count as the limit.
"Reference" tiles (a definition, a refresh timestamp, a filter pane) don't count against the 5. Only tiles a stakeholder reads to make the decision.

I have shipped dashboards with three metrics. Three. The CFO opens those weekly. I have shipped dashboards with eleven metrics. The CFO opened those once and asked me to "summarize the takeaway." That's the same dashboard failing.

Context beats visualization, every time

Here's the heresy: a number with a written diagnosis beats a beautiful chart with no narrative. Every time.

"MRR: 4.18M (-4.2% MoM)" with a one-line annotation ("Down driven by 3 enterprise churns in EMEA, all three flagged at QBR; expansion booking 2.1M offsets net-net to -1.8%") is more useful than the prettiest line chart in the world. Because the chart shows you something happened. The annotation tells you what happened, why, and whether to panic.

Make this a rule for every tile that goes on a dashboard a human will read: one line of "what changed and why." Not a paragraph. One line. If you can't write it, the tile isn't ready to ship.

This is the part most analysts skip because it feels like writing, not analysis. It is analysis. The act of writing "down 4.2% because of three enterprise churns in EMEA" forces you to actually answer the question instead of presenting the chart and walking away. If the answer is "I don't know yet," that's also a valid annotation. "Down 4.2% MoM, root cause TBD by Friday, see #data-investigations" tells the stakeholder you saw it, you're on it, and they don't need to ping you. That ping you don't get is the highest ROI line of text you'll write all week.

Tools that make this easier: Hex's text cells next to chart cells, Looker's HTML tile with a templated comment, Tableau dashboards with a text-object footnote per tile. All of them support the pattern. None of them enforce it. You enforce it.

The "this report is wrong" panic post-mortem

Eventually a stakeholder will challenge a number. It's not optional. The question is whether you handle it like a professional or like someone trying to win a Slack argument.

Here is the protocol. Memorize it. It will save your career at least twice.

Step 1. Acknowledge in 5 minutes, not 5 hours. "Got it, looking now, will reply by EOD with what I find." That's the entire message. Don't defend. Don't argue. Don't explain why your number is right before you've actually checked. The stakeholder's anxiety drops the moment they see "looking now."

Step 2. Confirm the query. Open the underlying SQL. Run it fresh. Do you reproduce the dashboard number? If yes, the dashboard isn't lying. There's still a question about whether the query is right, but the surface is consistent. If no, you have a caching or scheduling problem; flag it and refresh.

Step 3. Confirm the source of truth. What does Finance / RevOps / the system of record say? Is your mrr column derived from subscriptions.amount or from a monthly_recurring_revenue materialized view that was built in 2022 by someone who left? Is Finance pulling from Stripe directly while you're pulling from a Fivetran sync that's 6 hours stale? 90% of "this report is wrong" tickets resolve here, and the resolution is rarely "the dashboard is wrong" or "Finance is wrong." It's "we're computing two slightly different things and calling them by the same name."

Step 4. Document the mismatch. In the post-mortem template, fill in: timestamp of the report, query used (paste it), source of truth value, dashboard value, root cause (definition mismatch / stale data / actual bug), fix (rerun / definition change / new annotation), and stakeholder communication.

Step 5. Ship a fix or a caveat in 24 hours. Either you fix the underlying issue, or you add a tile-level annotation explaining the gap. Both are acceptable. What's not acceptable is letting it sit while two parts of the org continue operating on different numbers.

Never argue in Slack threads. Arguments in threads are how analysts get a reputation as "defensive." Move the conversation to the post-mortem doc within 30 minutes. The doc is the artifact. The thread is the noise.

I keep a running log of every panic post-mortem I've shipped. Re-reading them is the single best skill development exercise I do. I can see exactly which definition mismatches keep recurring (it's always revenue recognition, always) and where to invest in upstream fixes. Every panic is also a signal about which tile needs a permanent annotation so the next person doesn't ping.

Adoption is the metric that proves the dashboard works

The dashboard you built last quarter: is it working? Most analysts can't answer that question, which is wild because we are professionally obsessed with measurement.

Instrument adoption. Every BI tool has the data:

Looker has System Activity, an internal Explore. history.query_run_count, dashboard.view_count, user.id, all queryable.
Tableau Server / Cloud has the Admin Insights project. views_workbooks and views_dashboards give you opens per asset per user.
Hex has built-in usage analytics on the workspace settings page.
Mode has the Discovery API and admin reports.
Power BI has Usage Metrics reports per workspace.

Track three numbers per dashboard, monthly:

Unique viewers. Not opens. Humans. A dashboard with 200 opens from 2 viewers is a tab someone left pinned, not a working dashboard.
Time on dashboard. A dashboard nobody scrolls is a dashboard nobody reads. Most BI tools log session duration; under 30 seconds means they opened it and bounced.
Repeat viewer rate. Of last month's viewers, how many came back this month? The recurring viewers are the real audience. Everyone else came once and moved on.

A dashboard with fewer than 3 unique viewers per month, for two months running, is a deprecation candidate. Not a "needs a redesign" candidate. A deprecation candidate. Stop optimizing things nobody opens.

The most useful exercise I run quarterly: rank every dashboard I own by repeat viewer count. Top 5 get my time and care. Bottom 5 get a deprecation review. The middle gets benign neglect, which is fine. Neglect is cheap, deprecation is honest, and active care is expensive. Spend it where it returns.

The 6-month deprecation review

Deprecation is a feature, not a failure. Adopt this and you'll never feel bad about killing a dashboard again.

Every six months, you sweep. Block a half-day. Pull the adoption data for every dashboard in your space. Sort by unique viewers, ascending. Then:

Anything with under 3 viewers/month over the last 6 months: archive. Not delete. Archive. Move to a hidden folder, drop a pin in #data-archive announcing what got moved, link the archive list. If anyone yells, you can restore it in 60 seconds. Nobody will yell. They didn't open it.
Anything 3-10 viewers/month: re-confirm ownership. Ping the named owner. "Still own this? Still relevant? Still has named decision?" If the owner left, you're the new owner. Decide whether it's worth keeping or sending to archive. No-reply within a week = archive.
Anything 10+ viewers/month: keep, audit the tile annotations, refresh stale numbers, and update the decision in the title if the business shifted. These are your real surface area. They earn maintenance.
Post the kill list publicly. A short message in the org's data channel: "Sweep complete: archived 12 dashboards, kept 47, here's the list." Three things happen. (a) Nobody complains because nothing they actually used disappeared. (b) Other teams see the cadence and start doing their own. (c) Leadership notices that someone is treating the BI instance like infrastructure, not a junkyard.

The first time I ran a sweep like this at a previous company, I archived 38 dashboards. Two people pinged me, both about the same dashboard, which I un-archived in three minutes. That's the entire risk surface. The reward was a BI instance that loaded faster, had clearer search results, and had visibly fewer "wait, which one is the real revenue dashboard?" Slack threads.

In six months, your BI instance should have fewer dashboards than today. Not more. If it has more, the design discipline isn't working and the deprecation cadence is being skipped. Both are fixable. Both are your job.

Templates you can steal

Dashboard one-pager spec. Fill before you build:

Decision this dashboard answers: (one sentence, ends in a verb)
Audience: (named role, not "stakeholders")
5 primary metrics, ranked: (1, 2, 3, 4, 5)
Refresh cadence: (real-time / hourly / daily / weekly, match to decision velocity)
Owner: (named human, not a team)
Sunset criteria: ("archive if <3 unique viewers/month for 60 days")

Panic post-mortem template. Fill within 24 hours of every challenge:

Reported by, when, in which channel
Stakeholder's expected number vs dashboard number
Query used (paste full SQL)
Source-of-truth comparison (Finance / RevOps / system value)
Root cause (definition / freshness / bug / user error / actually correct)
Fix shipped (link to PR or annotation)
Comms back to stakeholder (paste the reply)

6-month review checklist. Block a half-day, run the sweep:

Pull adoption data for all owned dashboards
Sort ascending by unique viewers
Archive: <3 viewers/month for 6 months
Owner re-confirmation: 3-10 viewers/month
Audit + refresh: 10+ viewers/month
Post the kill list publicly
Update the deprecation log (date, archived count, kept count)

These three documents are 90% of dashboard hygiene. Print them. Pin them. Use them.

Common pitfalls

A handful of patterns I see, repeatedly, on every team:

Building from the request, not the decision. Stakeholder says "I want a chart of conversion by source." You build it. You ship it. Six weeks later, nobody opens it, because the actual decision was "should we keep paying for the Google Ads contract?", and that needed CAC by source plus retention overlay, not a conversion bar chart. Always ask the decision before you write the SQL.
The exec dashboard with 14 tiles because the VP "wants to see everything." The VP doesn't want to see everything. The VP wants to feel informed and surface the two surprises. Give them a 5-tile dashboard with a one-line written summary at the top, and they'll thank you. Probably promote you, eventually.
Rainbow palettes. Eight series, eight colors, all the same saturation. The user reads nothing. Use one accent, gray everything else, highlight only the series the decision depends on.
Never deprecating, only adding. This is the slow death. Every quarter, the count goes up. Every quarter, the average dashboard quality goes down. Six months in, the BI instance is unsearchable and three different dashboards say three different things about MRR. The fix is the sweep cadence. Without it, you're adding tech debt forever.

What "good" looks like

You've internalized this when:

Every dashboard you own has a named decision in its title, not a topic.
You can list, from memory, your top 5 dashboards by adoption and your bottom 5 deprecation candidates.
"This report is wrong" pings drop quarter over quarter, because every tile has a written diagnosis the stakeholder reads first.
The BI instance has fewer dashboards in 6 months than it does today, not more.
Your panic post-mortem doc has at least 5 entries from the last year, and you can point to the upstream fix that came out of each one.

That's the bar. Not "I built more dashboards." Not "stakeholders love my charts." It's: I shipped surface area people use, I documented the failures, and I killed the ones that didn't earn their keep.

Dashboard design isn't an aesthetic exercise. It's an attention budget exercise. Every tile costs a stakeholder's attention. Every dashboard costs your maintenance time. Spend both like they're scarce, because they are.

Data Analyst Playbooks