Which decision should the dashboard support?
Ask the future user a simple question: what will you do differently after looking at this dashboard? If the answer is vague, the report will be too. A good brief names the decision, how often the report is reviewed, the thresholds that call for attention and the person who acts when a threshold is crossed. This is the first question in any BI dashboard development project.
Choose a small set of measures that answer that question. Different users need different views, even when they share the same data. A management overview shows trends and deviations, an operations queue (the core of operations analytics) shows the specific items that need action today, and a product investigation needs room to dig into details. Trying to fit all three onto one screen usually produces a report that serves none of them well. On a shop floor, for example, the operations queue is the view that manufacturing workflow software is built around.
Describe the workflow around the report as well: who opens it, at what point in their day or week, and what they do next. That description is worth far more to the developer than a list of every field in the database. Not every available field needs to become a chart; a field earns its place on the screen only if it helps someone make the decision.
What goes into a metric dictionary?
For each metric, write down what it means in business terms, how it is calculated, where the data comes from, which filters apply and which time basis it uses. Order date, payment date and shipping date can give very different pictures of the same month.
Decide explicitly how cancellations, duplicates and late updates are treated. Where departments use the same word differently (“client”, “sale”, “active user”), choose one authoritative definition for the dashboard and record it. Otherwise each team will read the same figure in its own way, and meetings about the report will be spent arguing about the numbers instead of the decisions.
Show on the screen when the data was last refreshed and which gaps are known, so the report does not give the impression that incomplete data is current and complete. Before the design is approved, reconcile a few sample figures with the people responsible for the source systems. Discrepancies found at this stage are cheap to fix; found after launch, they undermine trust in the whole dashboard. This kind of reconciliation is a routine part of data analytics services.
How do you test the report as a working tool?
Test the dashboard on realistic situations, not on the screen design. Give the intended user a scenario and see whether they can find the issue and decide what to do about it. If they need help, or have to open another system to make sense of the figures, the report is not finished yet.
Check filters, access rights and how the report looks on the devices people use: a dashboard designed for a large monitor may be unreadable on a laptop or on a phone in the warehouse. Include the states that are easy to forget, such as what the screen shows when there is no data for the period and when the data is out of date.
Decide who maintains the report and who investigates when figures do not match the source. A dashboard is ready for acceptance when both the numbers and the decision process around them can be checked, not when the screen merely looks finished.
Checklist: dashboard brief
- Name the decision, the user and how often the report is reviewed.
- Document the formula, filters and authoritative source for every metric.
- Show the time of the last refresh and the known gaps in the data.
- Reconcile sample figures with the source and test whether the user can take the intended action.
Example: overdue jobs for a supervisor
A supervisor opens the dashboard and sees overdue jobs grouped by the person responsible, together with the time the source system was last updated. Cancelled jobs are excluded according to a rule written in the metric dictionary, so nobody has to wonder why the figures differ from the raw list.
From each overdue job, the supervisor can open the relevant work record directly, without searching for it in another system. The example tests whether the report supports a decision, not whether it contains a decorative collection of charts.
