There is a scene familiar to anyone who has built a dashboard for a large company. The launch meeting. A big screen showing dozens of colorful charts. Everyone nods. Someone says, “Wow, this looks great.” Three months later, the dashboard is barely opened. The board is back to asking for the recap as a spreadsheet sent by email.
I have been on both sides of that story. I once led the creation of a 21-page Power BI dashboard to monitor the performance of six regions at an oil and gas company, and a 17-page supplier dashboard for an automotive company. From those projects I learned that the difference between a dashboard that lives and one that dies has almost nothing to do with the technology. The difference is in the way of thinking. Here are the seven principles I hold to.
1. Start from the question, not from the data
The most common mistake: the project owner asks, “show everything we have.” The result is a page full of charts that answer nothing. A good dashboard is built from decision questions. For example:
- “Which regions are below target this month, and by how much?”
- “Which suppliers’ response times are getting worse?”
- “What has changed compared with last month?”
If a chart does not answer any such question, it is a candidate for removal. Not because the chart is bad, but because it takes attention away from the charts that matter.
2. The main reader is a busy human
A director does not have time to read twenty pages. Design the first page as a summary that can be understood in thirty seconds: a few key numbers, their status (good, watch, or bad), and one or two things that need attention. The following pages are space for digging deeper (drill-down) for those who want to know “why”.
If a director has to click five times to find out whether there is a problem, the dashboard has already failed.
3. Every number needs a comparison
A number without a comparison is a number that cannot be read. “Sales of IDR 12 billion” means nothing until you know the target, last month’s result, or last year’s figure. Each main indicator card (KPI) should ideally show at least one comparison: target, previous period, or another region. Use color sparingly and consistently: green for on target, yellow for watch, red for below target. Do not use red for things that are not truly urgent, because when everything is red, nothing is red.
4. Definitions must be single and written down
One of the silliest sources of conflict in meetings is two people bringing different numbers for the same metric. “Sales” according to the finance team differs from “sales” according to the sales team, because one uses the invoice date and the other uses the order date. A good dashboard provides a metric dictionary: definition, formula, data source, and update frequency, easy to access from inside the dashboard itself. Trust in a dashboard is built on the consistency of its numbers. Once or twice of figures not matching other reports, and people stop trusting it.
5. Data quality is the foundation, not an add-on
A dashboard is only a window. If the data behind it is messy (duplicates, mixed date formats, inconsistent region codes), the prettiest window just shows the mess more neatly. In my experience, most of the time in a dashboard project is actually spent behind the scenes: cleaning data, merging sources, building a reliable refresh pipeline, and setting up data governance (who owns the data, who may change it, how errors are handled). If your project seems to spend too much time on “making it look nice”, suspect the foundation.
6. Design for reading, not for showing off
A few simple rules that consistently help:
- One message per visual. A chart title should be a conclusion (“Region C has declined three months in a row”), not just a label (“Sales by region”).
- Choose the chart type for the purpose. Comparing categories suits bars. Trends over time suit lines. Avoid pie charts with more than five slices and avoid three-dimensional effects.
- Cut the decoration. Heavy gridlines, shadows, and too many colors add reading burden.
- Start the axis at zero for bar charts. Truncating the axis makes small differences look dramatic.
- Mind the device. Many executives read dashboards on a tablet or phone. Test the view on that device.
7. A dashboard is a living product, not a finished project
Business needs change. New questions appear. A dashboard that is right today can lose relevance next year. Provide a feedback mechanism (who uses it, which pages are opened most, what is missing), monitor usage, and schedule regular reviews. If a page has not been opened in three months, ask: should it be removed, simplified, or merged?
Another equally important point: train the users. A dashboard that is not understood will be abandoned, however good it is. A short introduction session, a one-page guide, and someone to contact when confused often matter more to success than extra features.
A simple test: the thirty-second test
Before launching a dashboard, run this test. Show the first page to a leader who has never seen it. Give them thirty seconds. Then ask: “Are we doing well or badly, and what should we pay attention to?” If they can answer, your dashboard works. If they answer “hmm, this is a lot, isn’t it…”, you have homework to do.
A good dashboard does not try to make its audience marvel. It tries to make its audience brave enough to decide.
Example: from 21 charts to one summary page
Imagine a dashboard for six operating regions. The first version shows 21 charts on one screen: sales by region, by product, by month, by channel, and so on. The version that works shows a summary page with a simple structure: the top row has four main KPI cards (for example achievement against target, growth compared with last month, the number of regions below target, and one risk indicator). In the middle is one bar chart showing the six regions’ achievement against target with status colors. Below is a short “needs attention” list naming the region and the problem. The remaining 20 charts are moved to drill-down pages that can be opened when needed. The data content is not reduced, only the order of priority changes.
Checklist before launch
Make sure: (1) all numbers have been reconciled with official sources, (2) metric definitions are written down, (3) the data refresh time is shown, (4) access rights are appropriate, (5) the display has been tested on the devices your leaders use, and (6) someone is designated to answer user questions during the first two weeks. These six things often decide a dashboard’s fate more than the choice of chart type.
Quick Q&A
What is the ideal number of dashboard pages? There is no magic number. What matters is that the first page answers the main question within seconds, and that every other page has a clear function: drill-down, deeper analysis, or reference. A dashboard with many pages can be good as long as navigation is clear and every page has a purpose.
Power BI, Tableau, or Excel? The tool matters less than the design. Choose what fits your data ecosystem, your team’s skills, and your budget. A well-designed dashboard in any tool will beat a poorly designed one in the most expensive tool.
Need a Power BI dashboard or reporting system your leadership actually uses? The datalytics.indo team can help with everything from framing the business questions, cleaning and modeling the data, and designing the dashboard, through to training the users. In-house Power BI and Excel/VBA training for your team is also available. Let’s discuss your needs first. We’ll provide a tailored quote based on your project.