Consider a dashboard when decision questions recur, information comes from several sources, and users regularly need comparisons or filters. A structured report can be enough for a fixed, infrequent question. Data readiness and agreed metric definitions matter more than the number of charts.
Signs of a practical need
Review the current process before choosing an application. Are the same figures rebuilt every week? Does a manager compare branches or periods? Does the team disagree on what counts as a completed order or revenue? These questions identify the work needed before visual design.
- A recurring answer requires manual preparation by one person.
- Several files exist and the latest approved version is unclear.
- Users need to move from an overall metric to the details behind it.
- Someone is responsible for acting on the information.
For a one-off summary, organising a spreadsheet or report may be simpler. A dashboard is not an objective in itself, and attractive charts do not repair missing information.
Start with the decision, then define the metric
Write the question, identify the reader and describe the action that could follow. Select a small set of relevant measures, with clear titles, periods and units. Microsoft’s dashboard guidance also emphasises audience needs and avoiding clutter.
A manager tracks on-time delivery. If 100 orders were due during the month and 84 of them were delivered on time, the rate is 84% under that definition. Rules for cancellations and changed due dates must be agreed before using the measure.
Do not compare that result directly with a rate calculated only from delivered orders: the denominator is different. Document the formula and source so that a change in definition is not mistaken for an improvement in performance.
What should you prepare?
- Users: who will view the dashboard, and which details may each person see?
- Sources: available files or systems, an appropriate sample and a description of the fields.
- Definitions: metric name, calculation, unit, period and exceptions.
- Refresh: a suitable frequency, a responsible owner and a visible last-successful-update time.
- Deliverables: agreed screens, filters, languages and handover format.
Use synthetic or de-identified sample data for an initial discussion where that is sufficient. Full customer or employee records should not be needed merely to explain a proposed layout.
Interactive does not automatically mean real time
A branch or date filter does not establish that a dashboard connects to every business system. It may use a manually updated file, a specific integration or a scheduled refresh. Ask how data reaches the dashboard and what happens if an update fails.
Agree hosting, licences, viewing and editing permissions, and any external service costs. Live integrations, data collection and extensive historical cleanup are not automatically included in a design scope. A sample dashboard demonstrates a visual direction; it is not a ready-made connection to your systems.
How should you review it before acceptance?
Choose a small sample that you can calculate independently. Compare the output with the source, then test filters, empty periods and missing values. The display should distinguish an actual zero from unavailable data and clearly show its update time.
- Check totals and underlying details after important filters are applied.
- Review units, currencies, dates and numerical rounding.
- Check permissions without giving everyone a shared account.
- Use the screen sizes the team actually needs, including phones where appropriate.
- Assign responsibility for monitoring and resolving failed updates.
Begin with a scope you can evaluate
Choose one management question, a clear source and an appropriate set of measures. Once definitions and results are accepted, decide whether another screen or source supports a further decision. Review WJAZ examples for the visual direction, then discuss a scope based on your actual data.
Frequently asked questions
Do I need a large volume of data?
Volume alone is not the deciding factor. Recurring decisions, a clear question and reliable information matter more. A simple report may be sufficient for a limited requirement.
Does a dashboard guarantee better decisions or sales?
No. It helps users interpret a defined set of data. Data quality, interpretation, decisions and execution remain separate responsibilities, and business outcomes are not guaranteed.