Most BI teams measure themselves by the number of reports they ship. Dashboards built, queries answered, ad-hoc requests closed. It is a natural scoreboard: visible, countable, easy to defend in a planning cycle.
But it rewards the wrong thing. Reports are not the deliverable. The decisions they enable are. And once you start designing for decisions instead of reports, nearly everything about the work changes — what you build, how you structure it, and how you know whether it worked.
The reporting trap
We see this pattern in almost every engagement. A team inherits or builds a reporting surface — a set of dashboards, a scheduled email, a self-service layer — and over time, the surface grows. New charts are added. Filters multiply. Tabs proliferate. Nobody removes anything because nobody is sure what anyone else is using.
The result is a reporting estate that is large, slow to maintain, and quietly ignored by the people it was built for. Stakeholders glance at the summary page, then message the analyst directly. The analyst re-derives the number from scratch because they do not trust the dashboard either.
This is not a tooling problem. It is a design problem. The reports were built to show data, not to support a decision. And there is a meaningful difference between the two.
What a decision needs
A decision, at its simplest, is a moment where someone chooses between options under uncertainty. Good analytical tools reduce that uncertainty — but only if they are designed around the decision itself.
That means answering three questions before you build anything:
- What is being decided? Not "what do people want to see" — what are they actually choosing between? Pricing changes, inventory allocations, staffing levels, capital expenditure. Name the decision.
- Who decides, and when? A weekly ops review has a different cadence, audience, and tolerance for complexity than a quarterly board pack. The interface needs to match the rhythm of the decision.
- What would change the answer? Which variables, if they moved, would flip the decision? These are the things worth showing. Everything else is context at best, noise at worst.
When we frame the work this way, the resulting tool looks nothing like a traditional dashboard. It tends to be smaller, more focused, and more useful. It answers one question well instead of gesturing at twenty.
Reports vs. decision tools
It helps to be concrete about the difference.
A report says: here is what happened. Revenue was up 4%. Churn was 3.2%. The Western region underperformed. It is descriptive, backward-looking, and comprehensive. It asks the reader to do the interpretive work.
A decision tool says: here is what you should consider doing about it. Given current trajectory, the Western region will miss target by Q3 unless we reallocate two reps from Metro. Here are the trade-offs. It is prescriptive, forward-looking, and selective. It does the interpretive work for the reader and presents the choice.
The shift is not about adding AI or fancy modelling. It is about editorial intent. Someone — usually the analyst, sometimes with a designer — has to decide what matters, what to foreground, and what to leave out. That is a design act, not a data act.
The one-page test
We use a simple heuristic in our practice: if a dashboard cannot fit on a single page (or screen, or view) without scrolling, it is probably trying to serve too many decisions at once.
This is deliberately strict. The constraint forces you to choose what matters. It surfaces the editorial question — what is this page actually for? — that most dashboard projects skip.
The irony is that teams who build forty-tab workbooks often spend less time on design than teams who build a single page. The tabs are a way of avoiding the hard editorial choices.
Symptoms you are in the reporting trap
A few signals we look for early in an engagement:
- The analyst is the interface. People ask the analyst for numbers instead of looking at the dashboard. The dashboard exists but is not the source of truth — the analyst is.
- Metrics disagree. Revenue on the executive dashboard does not match revenue on the finance dashboard does not match revenue in the board pack. Nobody is wrong, exactly — they are measuring slightly different things — but nobody has reconciled them.
- The refresh is the event. The weekly report email is the moment the organisation pays attention to data. Between refreshes, nothing is actionable. The tool is a broadcast, not an instrument.
- Nobody can explain the logic. Ask three people what "active customer" means and you will get three answers. The definition is embedded in a query somewhere, not in a governed semantic layer.
- Charts outnumber decisions. Count the charts on a dashboard. Count the decisions it supports. If the ratio is worse than 3:1, the dashboard is a data museum, not a decision tool.
Designing for decisions in practice
We are not suggesting you throw out your dashboards and start again. The shift is more subtle than that. It is about changing what you optimise for.
Start with the decision register. Before building anything, catalogue the decisions the analytical surface is meant to support. Be specific: "Decide weekly staffing levels for the call centre" is a decision. "Understand customer behaviour" is not — it is a research programme.
Assign each decision an owner and a cadence. If nobody owns the decision, nobody will use the tool. If the cadence is wrong — a daily dashboard for a quarterly decision — the tool will be ignored or, worse, will drive short-term thinking.
Design the minimum viable view. For each decision, ask: what is the smallest set of information that would let the decision-maker act with confidence? Build that. Nothing more. You can always add context later, but you cannot easily subtract once people have anchored on forty tabs.
Separate the semantic layer from the interface. The metric definitions — what "revenue" means, how "churn" is calculated, which customers are "active" — should live in a governed layer that is independent of any particular dashboard. This is the semantic layer, and it is the single most important piece of the analytical stack. It means every decision tool draws from the same truth.
Measure decision quality, not report usage. Dashboard view counts tell you whether people opened the page, not whether it helped them decide. Better measures: did the decision get made on time? Did the decision-maker feel confident? Did the outcome improve? These are harder to track, but they are what matter.
The semantic layer connection
This is worth expanding on, because it is where the architecture meets the design.
When every dashboard builds its own metrics from raw data, you get the disagreement problem — five definitions of revenue, three of churn, two of active customer. The analyst who built each dashboard made reasonable choices, but those choices diverged.
A semantic layer — whether it is a dbt metrics layer, a LookML model, a Cube.js schema, or something custom — codifies those definitions once. Every downstream tool consumes the same metric. The definition is versioned, documented, and testable.
This is not just good engineering. It is a prerequisite for decision design. You cannot build a trustworthy decision tool on top of untrustworthy metrics. And you cannot govern metrics if they are scattered across fifty dashboards and a hundred queries.
We wrote about this in more detail in our piece on the semantic layer. The short version: if you are spending time reconciling numbers, you do not have a reporting problem. You have a modelling problem.
What changes when you get this right
Teams that shift from reporting to decision design tend to see a few things happen:
The analytical surface shrinks. Fewer dashboards, fewer tabs, fewer charts. But each one does more. The remaining tools are used daily because they are genuinely useful — they help people make the call, not just review the data.
Trust goes up. When metrics are governed and the interface is designed around a specific decision, people stop second-guessing the numbers. They argue about what to do, not about whether the data is right. That is a significant upgrade.
The analyst's role changes. Instead of running queries and building charts, they become decision designers — people who understand the business well enough to curate what matters, structure the argument, and present the trade-offs. It is harder work, but it is more valuable work, and it is more interesting.
And the organisation starts to treat data as an operating system rather than a rear-view mirror. The data infrastructure exists not to record what happened, but to help people decide what to do next.
Starting small
If this resonates, the best first step is not a platform overhaul. Pick one decision. The most important recurring decision in your business — the one that, if made 10% better, would move the needle.
Map it: who decides, when, what information they use, where the uncertainty lives. Then build the smallest possible tool that serves that decision well. One page, one question, one source of truth.
That is the prototype. If it works — if the decision-maker uses it, trusts it, and tells you it changed how they think — you have the pattern. Apply it again. And again.
The reporting estate will not disappear overnight. But it will start to matter less, because the things that replace it will matter more.