A useful business dashboard begins with a decision

A dashboard can display a large amount of information while leaving its user unsure what to do next. The design question begins with the person using it: what are they trying to understand, and what decision follows?

The UK Government Analysis Function’s dashboard guidance asks teams to establish a user need, understand the decisions involved and consider whether a dashboard is the right format. Its context is public analysis, but the questions are useful when designing internal business reporting.

Give each measure a clear meaning

Consider an illustrative operations dashboard showing enquiries, completed reviews and revenue. Each label needs a definition. Does an enquiry include spam? Is a review complete when someone opens it or when an authorized person records a decision? Is revenue displayed for the same period and business scope as the activity figures?

Write these definitions before using the numbers together. Record the source, owner, calculation, period and refresh schedule. If a definition changes, explain the effect on comparisons.

Make uncertainty visible

Data quality has several dimensions. The UK Government Data Quality Framework includes completeness, uniqueness, consistency, timeliness, validity and accuracy. A current record may still be duplicated; a complete dataset may still contain incorrect values.

For each measure, identify which quality questions could change its interpretation. Show the period covered and when the underlying data was refreshed. When records are incomplete, explain the limitation near the affected information.

Design the route from observation to action

An illustrative manager reviewing a rise in unresolved cases may need to distinguish new volume from older work, identify the stage where cases wait and know who can resolve the issue. A total count alone may not answer those questions.

Choose the comparisons and detail views around that task. Where a short written explanation would be clearer than an interactive display, use the simpler format. Keep a readable table or export available for people who cannot use the visual display effectively.

Review the dashboard as part of the process

Ask a representative user to work through a realistic question. Observe whether they can find the relevant measure, explain its meaning, identify its limits and describe the next action. Revise the dashboard where that chain breaks.

For Kweesha’s proposed approach, a reporting specification therefore begins with the decision, then defines the measures, information and interface needed to support it. The chart is one part of the system around that decision.