Key takeaways
- Start from the decision, not the data you happen to have.
- Fewer, trusted reports beat dozens of overlapping ones.
- Adoption is a design problem. Test dashboards with real users before rolling them out.
Many companies have invested heavily in BI tools, yet meetings still start with somebody exporting a spreadsheet. The dashboards exist; they're just not used. In our experience, the cause is rarely the technology. It's how the reports were designed in the first place.
Symptom 1: reports built around data, not decisions
The most common anti-pattern is starting with the tables you have and asking “what can we chart?”. The result is a page of technically correct visuals that don't answer anybody's question.
Flip it around. Before building anything, list the decisions a team makes every week, such as which stores need more stock, which customers are at risk or which campaigns to scale, and the questions behind each one. Every visual should earn its place by helping answer one of those questions.
Symptom 2: nobody trusts the numbers
If two dashboards show different revenue figures, people stop trusting both. Trust is built in the data model, not the report:
- Define each key metric once, in a shared semantic model, with a plain-English description.
- Assign an owner to every core dataset.
- Show data freshness clearly (“Last refreshed: 07:00 today”).
- Retire duplicate reports aggressively.
Symptom 3: too much on one page
A dashboard that tries to serve the CEO, the sales team and finance at once serves none of them. Design for one audience at a time, lead with three to five headline numbers, and let people drill down for detail rather than showing everything up front.
A good dashboard answers a question in five seconds. A great one tells you what to do next.
A simple framework we use
- Decision workshop: list the decisions, the questions behind them, and who makes them.
- Metric definitions: agree on calculations and owners before writing any DAX.
- Model first: build a clean, well-documented data model.
- Prototype and test: put a rough version in front of real users and watch them use it.
- Consolidate: replace old reports, don't add to them.
- Measure adoption: track usage and keep improving what people actually open.
Where to start
Pick one team and one important weekly decision. Build a single, trusted view for it, measure whether it changes how the meeting runs, then expand. Small, visible wins build the credibility you need for bigger data projects.
Written by
Itrowin Data Practice
Data & AI engineers. We share what we learn building engineering teams and software for clients across the UK and beyond.