What a dashboard is for
A dashboard is a way to answer a few recurring questions quickly: is anything wrong, is anything heading the wrong way, and does something need attention today? It is not a report archive and not a place to display everything that can be measured.
Many dashboards fail not because the charts are poor but because nobody has a reason to open them. The choices below are about avoiding that outcome.
Start with the audience
Different readers need different things from the same data.
- Front-line teams usually want current queues, items waiting and anything overdue. They need detail and fast updates.
- Team leads and managers tend to want trends, exceptions and workload balance, in order to make staffing and priority decisions.
- Senior stakeholders typically want a few summary measures and whether each is on track, with the ability to ask for detail when needed.
Trying to serve all three on one screen usually serves none well. A common approach is a short summary view for leadership, with a more detailed operational view for the people doing the work, both drawing on the same underlying numbers so they never disagree.
Before building anything, write down who will look at the dashboard, how often, and what they will do differently depending on what they see. If you cannot answer the last part, the content is not yet clear enough.
Choose the contents
Pick from the measures you have already decided matter, rather than from whatever data is easy to pull. The wider process of choosing metrics is described in the overview of operations metrics selection; the dashboard should show the output of that choice, not replace it.
Some rules of thumb:
- Keep the count low. A screen that can be read in under a minute is more likely to be read at all.
- Show each measure with context: a target or agreed range, and the previous period, so the viewer can tell whether a value is good or bad without guessing.
- Include a small number of exceptions, such as the oldest open item or anything past its deadline, because averages can hide them.
- Use only measures with a written definition. If two people would calculate a number differently, the dashboard will cause arguments rather than decisions.
Layout that helps reading
Simple layout conventions go a long way.
- Put the most important measure top-left, since that is where most readers look first.
- Group related measures together and label each group plainly.
- Use plain labels in the audience’s own words, not internal system names.
- Show trends as simple lines or bars over time; a single figure is far less informative than a figure with its history.
- Use colour sparingly and consistently. If red means “needs attention”, do not use red for anything else. Do not rely on colour alone, as some readers cannot distinguish certain colours.
- Avoid decoration such as 3D effects, large gauges or crowded legends that take space without adding meaning.
A table is often better than a chart when readers need exact values, and a chart is better when the shape of the change matters.
Decide how often it refreshes
Refresh rate should match how quickly the underlying work changes and how quickly someone could act on the information.
- A live queue for a support team may justify near-real-time updates.
- A weekly cost or backlog trend gains little from being refreshed every hour.
- Monthly outcome measures only change when the month closes.
More frequent is not automatically better. Constant movement can encourage reacting to noise, and fast refreshes can mean reading numbers that have not yet been checked. It helps to show a visible “last updated” time so viewers know how current the figures are.
If the dashboard draws on several systems, consider how integrated reporting data will be assembled and how long that takes. A dashboard that mixes figures from different times without saying so can mislead.
Build trust in the numbers
People stop checking a dashboard the first time they catch a wrong figure. A few habits protect trust:
- Name an owner for each measure and for the dashboard as a whole.
- Link each measure to its definition so viewers can see what is counted.
- Check the dashboard against a source report when it is first built, and again after any system change.
- Be open about known gaps, such as a data source that is not yet connected, rather than leaving a blank that looks like zero.
Underlying data quality issues, such as duplicates or missing dates, will show up on the dashboard whether or not anyone intended it. Fixing them at the source is usually better than correcting them in the chart.
Where it fits in a wider setup
A dashboard is one component of a broader reporting picture. Some organizations also allow self-service reporting so that teams can explore the data themselves, which brings flexibility but also the risk of inconsistent figures; a central dashboard with agreed definitions gives everyone a common starting point.
A dashboard should also feed into a regular conversation. Numbers that nobody discusses rarely change anything, which is why dashboards work best alongside structured performance review meetings.
Start small and adjust
A reasonable first version is a single page with a handful of measures, built with tools the team already uses, and shown to a few real users. Ask them what they looked at, what they ignored and what they wished were there. Then remove things before adding them. Dashboards tend to grow over time, and an occasional clear-out keeps them useful.
Spreadsheets are enough for many small teams; a specialist tool becomes worthwhile when data comes from several sources or many people need access. That is a judgement call for each organization, not a rule.