Designing business intelligence people will keep open
Start from the meeting the numbers must survive. Then write definitions. The tiles come last.
Most BI estates grow by accretion. Someone needed a chart for a board pack. Someone else copied it and changed a filter. Two years later the homepage is a directory, and the real report is a spreadsheet emailed on Sunday night.
Write the metric before the chart
A metric has a name, a grain, a time rule, and an owner. “Active customer” means nothing until those are written. If two executives need different grains, that is two metrics, not one tile with a silent toggle.
Design for a job
An executive review needs a short narrative and exceptions. A warehouse manager needs a list they can act on this morning. Combining both on one canvas produces a picture that helps neither person. Navigation and density should follow the job.
Performance is part of trust
If a filter takes half a minute, people stop asking questions. Aggregates, incremental refresh, and a semantic model are not polish. They are why the tool gets used after the launch meeting.
Unused reports should be removed. A large catalogue is not a sign of a data-driven culture.
Common questions
What makes a good BI dashboard?
It is designed for one job and audience, uses metric definitions that have been agreed and owned, shows exceptions rather than everything, responds quickly enough to encourage exploration, and is retired when nobody uses it.
Why do dashboards show different numbers?
Usually because the same metric is defined differently in different reports — a different grain, time rule, or filter. Writing metric definitions once, in a shared semantic model, and certifying the reports that use them removes most of these conflicts.
This article supports our analytical platforms services. If the situation it describes is familiar, tell us about the systems involved.
