A dashboard can be attractive and still leave a team unsure what to do. Useful reporting begins with a clear question and information that can be checked. The visual design comes after the team agrees what the measures mean and where the underlying records come from.
Choose the decision the report supports
Ask the intended reader what they need to decide. A service manager may need to identify work waiting too long. A programme lead may need to compare progress across locations. Those questions require different views and definitions.
Write the question in ordinary language before choosing a chart. Then identify the few measures that help answer it. This prevents a report from becoming a collection of whatever numbers are easiest to obtain. If a measure has no clear use, consider leaving it out of the first version.
Define each measure carefully
Terms that sound obvious often hide different interpretations. A “completed request” could mean a decision was recorded, a response was sent or the requested work actually finished. Agree the definition, relevant dates and any exclusions.
Record those choices in a short metric dictionary. Include the owner and the source information. When the definition changes, record the change rather than silently comparing unlike periods. A reader should be able to understand what a number represents without asking the original analyst to explain it each month.
Trace one number back to its source
Before approving a dashboard, choose an important total and ask a colleague to explain how it was produced.
Tick a check as you review it.
A dashboard is easier to trust when its reader can trace the definition, records and update behind a result.
Check the records before the chart
Look for duplicates, missing values and inconsistent labels. Compare a sample of the prepared records with the original information. Investigate differences before combining them into a summary.
For a service report, two records might describe the same request or two genuinely separate tasks. That distinction matters. Agree a matching rule with the service team and keep uncertain cases visible for review. Data preparation should make the information more understandable, not conceal ambiguity by forcing every record into a convenient category.
Show context that changes the interpretation
A chart needs enough context to support a sensible reading. Label the period, unit and relevant comparison. Where information is incomplete, show that limitation near the result. A small number of observations should not be presented with the same confidence as a well-established pattern.
Design the report around the reader’s sequence of questions. Start with the overall position, then provide a way to investigate the parts that need attention. Use tables where exact values matter and charts where the pattern is the useful information.
Make the report maintainable
Check the finished view against known examples and ask the intended users to explain what they would do with it. Resolve disagreements about meaning before widening access. Provide a simple guide covering definitions, routine checks and who handles questions.
The deliverables include the data-quality findings, a metric dictionary, a dashboard and a reconciliation record. The test of usefulness is whether the next person can update it and reach the same interpretation from the same evidence. A report that depends on one person’s memory is difficult to sustain.
Explore our Data quality, migration and useful dashboards, related services and Map your applications before planning a replacement.
Questions and answers
Why do two dashboards show different totals?
They may use different date fields, definitions, filters or update times. Compare one measure and its underlying records before assuming that either chart is wrong or changing the reporting design.
What should we bring to a dashboard review?
Bring the report, the decision it supports and a sample of its source information that is appropriate to share. Include known disagreements and the manual steps required for each update.