Most organisations have more dashboards than they use. They were commissioned with good intentions, built with care, launched with a demo and then gradually ignored. When someone finally asks why, the answer is usually some version of “it doesn’t tell us what we need to know”.
In our work with leadership teams, that is rarely a technical failure. It is a design failure that happens before anyone opens a visualisation tool: the work started with the data available, or the tool licensed, rather than the decision the dashboard was supposed to support.
Begin with a sentence, not a sketch
Before discussing visuals, write down the decision the dashboard exists to inform, in one sentence, from the point of view of the person making it. For example:
- “Each Monday, the operations lead decides which regions need attention this week.”
- “Each quarter, the executive decides whether to continue, expand or stop this program.”
- “Each month, the leadership team decides whether the pipeline supports the hiring plan.”
If nobody can write that sentence, the dashboard is not ready to be designed. It may be a reporting requirement, a compliance obligation or a nice-to-have, all of which are legitimate, but they should be scoped and prioritised differently.
Work backwards to the few measures that matter
Once the decision is clear, ask what someone would need to know to make it well. This usually produces a short list: a handful of measures, a comparison point (target, prior period, peer group) and a way to see where the problem sits.
The discipline is in what you leave out. Every additional chart competes for attention. A useful test is to ask, for each element, “if this changed, what would someone do differently?” If the honest answer is “nothing”, the element belongs in a detailed report, not on the front page.
A dashboard is not a library of everything we know. It is an argument about what matters right now.
Agree definitions before you build
Many dashboards lose trust in their first week because two people looked at the same measure and expected different numbers. “Active customer”, “completed case” and “revenue” can each have several reasonable definitions.
Write each definition down, agree it with the people who own the decision, and publish it alongside the dashboard. This is unglamorous work, but it does more for adoption than any visual polish.
Design the reading order
People scan a dashboard in a predictable way: top left first, then across and down. Use that. Put the answer to the core question where the eye lands first, the context next, and the diagnostic detail last. Use colour sparingly and deliberately (to signal status or draw attention) rather than to decorate.
Prototype early, with the real audience
A rough prototype shown to the decision-maker in week one is worth more than a polished product shown in week eight. Watch them use it. Where do they look first? What do they ask? What do they try to click? Those observations will reshape the design more than any requirements document.
Plan for the second month, not just launch day
Adoption is earned in the weeks after launch. Decide who owns the dashboard, how questions about the numbers will be answered, and when it will be reviewed. Retire elements nobody uses. A dashboard that gets smaller and sharper over time is usually a sign that it is working.
A short checklist
- Can you state the decision in one sentence?
- Does every element change what someone would do?
- Are the definitions written, agreed and visible?
- Does the layout answer the main question first?
- Has the real audience used a prototype?
- Is there a named owner after launch?
None of this depends on a particular tool. It works the same in Power BI, Tableau or a well-built spreadsheet, because the hard part was never the software.