The dashboard nobody opens

The launch goes well. The dashboard is shared in a meeting, people say it looks impressive, and the link goes out by email. For a week or two, a few people click through.

Then usage drops. Three months later, the same managers are still asking for figures by email, and someone on the team is still building the monthly Excel summary by hand.

This happens far more often than it should. In most cases the problem is not the tool, the colours or the analyst's technical skill. The dashboard was built to display data rather than to support a decision someone actually needed to make.

Why dashboards get ignored

When we review dashboards that are not being used, the same causes come up again and again:

  • It was built around the available data, not around anyone's questions.
  • It was built for everyone, so it fits nobody's needs particularly well.
  • It shows too much. Twenty visuals on a page leave the user to work out what matters.
  • People do not trust the numbers because they do not match figures from other reports.
  • It sits outside any routine. Nobody has a reason to open it on a particular day.
  • It is hard to reach, because of licences, slow loading or a layout that breaks on a phone.

Every one of these can be prevented before the first chart is built.

1. Start with the decision, not the data

Before opening Power BI or Tableau, sit down with the people who will use the dashboard and ask one question: what will you do differently depending on what this shows?

If nobody can answer that, the dashboard is not ready to be built. Write the answers as simple statements of need. For example:

As a state programme manager, I need to see which local government areas fell below 80% reporting completeness this month, so I can follow up before the monthly review meeting.

A statement like this tells you who the user is, which measure matters, what threshold triggers action and when they need it. That is most of a dashboard design already.

2. Design for one main audience

A director and a field supervisor need different things. The director wants a few headline measures and a clear signal of where to pay attention. The supervisor needs detail to act on, such as the specific sites, staff or records involved.

Trying to serve both on one page usually serves neither. Choose a primary audience for each page. If several audiences need the dashboard, give each one a page built for their decisions.

3. Agree on definitions before you build

Nothing destroys trust faster than a dashboard that says 1,240 when the monthly report says 1,198. Usually both numbers are "correct" and simply use different definitions, date ranges or filters.

Before building, write a short definition for every measure:

  • The name of the measure
  • How it is calculated, including what is excluded
  • The data source and how often it is refreshed
  • The person responsible for confirming it is correct

Get the main users to agree on these definitions. It takes an hour and can save months of arguments.

4. Sketch it first and test the sketch

Draw the layout on paper or a whiteboard before building anything. Show it to two or three intended users and ask them to talk through how they would use it. Where do they look first? What question do they ask that the sketch does not answer?

Changing a sketch takes minutes. Rebuilding a finished dashboard can take days, and by then people are less willing to say what is wrong with it.

5. Lead with the answer

The most important measure belongs at the top left, where most readers look first. Show it against a target, a previous period or a comparison group, because a number on its own rarely tells anyone whether things are going well.

Use chart titles that state the message rather than naming the chart. "Reporting completeness fell in 4 of 9 LGAs this month" is more useful than "Reporting completeness by LGA."

Remove anything that does not support one of the agreed questions. A focused page with five or six visuals will usually be used more than a crowded one with twenty.

6. Make the numbers easy to trust

Show when the data was last refreshed and where it came from. Before launch, reconcile key figures against reports people already rely on, and explain any differences in a short note.

If users find a single number they believe is wrong, they will often stop trusting the whole dashboard. Validation is not optional finishing work. It is part of the build.

7. Fit it into an existing routine

A dashboard gets used when it has a regular place in how decisions are made. Link it to a meeting that already happens, such as a weekly operations call or a monthly performance review, and use it on screen during that meeting.

This is the same principle we described in Your Indicator Table Is Not a Monitoring Framework: data only changes things when someone is responsible for reviewing it and acting on it at a set time.

8. Plan for what happens after launch

Launch is the start of the work, not the end. Agree who owns the dashboard and who maintains it when the data source changes. Check usage figures after the first month. Ask users what they use, what they ignore and what they still request by email.

Then act on what you learn. Remove pages nobody opens. Add the question people keep asking for. A smaller dashboard that is used every week is worth more than a large one that only looked good at the launch.

A short checklist before you publish

  • Can you name the main users and the decisions this dashboard supports?
  • Has every measure got an agreed, written definition?
  • Have the key figures been checked against an existing trusted report?
  • Does the top of the page answer the most important question?
  • Is there a meeting or routine where it will be used?
  • Is there a named owner responsible for keeping it accurate?

If you can answer yes to all six, your dashboard has a far better chance of becoming part of how the organisation works.