How to Build a Dashboard Your Team Will Actually Look At
Most business dashboards are built to impress, not to inform. Here is how to design one that generates decisions instead of being politely ignored.
There is a particular kind of business dashboard that everyone has seen and nobody uses. It was built by someone who cared — probably by the head of finance or an ambitious ops lead — and it lives in a Notion page or a Looker embed that twenty people have bookmarked and three regularly visit. It has forty metrics, color-coded cells, sparklines, and a last-updated timestamp that reads two weeks ago. It is comprehensive. It is ignored.
The failure is not technical — it is design. A dashboard that is hard to parse, that requires explanation, or that presents information without a clear answer to "so what?" is not a dashboard. It is a data dump. The best dashboards in the world are boring by design: they show the smallest number of metrics necessary to tell the team whether things are going well or not, and they make the answer obvious at a glance.
The single question a dashboard must answer
Before building anything, answer this question: when someone opens this dashboard, what decision should they be able to make faster? If you cannot answer that question specifically, you are not ready to build the dashboard yet. You need to decide who it is for — an executive team, a sales team, a product team — and what they need to know to do their jobs better.
An executive dashboard answers: "Is the business on track?" A sales dashboard answers: "Are we going to hit the number this month?" A product dashboard answers: "Are users getting value from what we shipped?" Each of these requires a different set of metrics. Trying to build one dashboard that answers all three produces one that answers none.
A dashboard that requires explanation is not a dashboard. If someone needs a tour before they can read it, the design has failed before the data arrives.
The six-card executive dashboard
For most small and growing teams, a six-metric executive dashboard is enough. The goal is to show the state of the business across three dimensions — growth, retention, and cost — with enough context to know whether each dimension is healthy.
Each card shows four things: the metric name, the current value, the change versus the previous period, and a threshold. The threshold is what makes a dashboard actionable — without it, a number has no meaning. $84,200 in monthly revenue is good or bad depending on your target. 2.1% churn is acceptable or alarming depending on your benchmark. Show the target alongside the number so the reader does not have to remember it.
The threshold principle: every metric needs a line
A metric without a threshold is a fact without context. The threshold — the value at which you take action — is what transforms a data point into an operational signal. Setting thresholds forces a useful conversation: what value of this metric would make us do something differently? If you cannot answer that, the metric may not belong on the dashboard.
There are two types of thresholds. A target threshold is a goal — revenue above $80,000, NPS above 40. An alert threshold is a floor or ceiling — churn above 2.5% triggers a review, burn above budget triggers a spend audit. Both belong on the dashboard. Targets tell you whether you are winning. Alerts tell you whether something is breaking.
The discipline of setting thresholds upfront forces the conversation about what "good" actually means for each metric. Too many teams build dashboards first and argue about what the numbers mean afterward. Setting thresholds before you start means the dashboard arrives with its decision logic already embedded — the color of the indicator tells you whether to act, not the memory of a meeting three months ago.
What kills a dashboard: the most common design failures
| Failure | Why it happens | The fix |
|---|---|---|
| Too many metrics | Everyone added their own metric and nobody removed any | Enforce a hard limit (6–8 cards) and require removal for every addition |
| No thresholds | Nobody agreed on what "good" looks like before building | Set a target or alert level for every metric before it goes on the dashboard |
| Stale data | Manual updates that no one owns | Automate updates or assign a single owner with a recurring task to refresh |
| No comparison period | A current value with no context looks like a fact, not a signal | Always show delta vs. prior period (MoM, WoW) alongside the current value |
| Wrong audience | One dashboard built to serve everyone serves no one | Build separate dashboards for leadership, sales, product — different questions need different numbers |
The review ritual that makes a dashboard worth having
A dashboard is only as useful as the meeting it informs. The most valuable thing you can do with a well-designed dashboard is use it as the opening five minutes of your weekly or monthly business review. Walk through each metric, note whether it is on track or off, identify the one or two that need discussion, and move on. The dashboard should take five minutes to review. The discussion it generates should be where the time goes.
If reviewing the dashboard consistently takes more than ten minutes, it is too complex. The data is doing work that the team's judgment should be doing. Good dashboards produce fast pattern recognition — green means skip, yellow means note, red means discuss — not extended analysis sessions.
Some teams compulsively refresh their dashboards throughout the day, checking metrics that do not meaningfully change hour-to-hour. This is a form of anxiety management, not business management. Set a cadence for reviewing each dashboard — daily for operational metrics, weekly for growth metrics, monthly for financial metrics — and stick to it. Continuous monitoring without a trigger or threshold is not management; it is watching.
In FabricLoop, teams often pin a dashboard note to their leadership group — a weekly-updated note that lists the six to eight metrics with their current values, targets, and a one-line commentary from the owner. Because it lives alongside the team's tasks and threads, the transition from "here is what the number is" to "here is what we are going to do about it" happens in the same place. Recurring tasks ensure the update never gets skipped. Threads attached to the note capture the decisions and context that future reviewers will need to understand why a metric moved in a given week.