Plan a Business Dashboard Around Decisions, Not Charts

Write the decisions before the charts

List the decisions the dashboard should support, one line each. Examples: whether to reorder a fast-moving item this week, whether a project needs an extra crew, whether a client account needs a call. For each decision, note who makes it, how often, and what they would do differently depending on what the dashboard shows. If a proposed tile does not change any decision, it is decoration.

Microsoft's Power BI guidance describes a Power BI dashboard as a single page that uses visualizations to tell a story, and notes that because it is limited to one page, a well-designed dashboard contains only the most important elements of that story. [1]

In Power BI, that guidance distinguishes dashboards from reports: filtering and slicing belong to reports. If Power BI is your chosen tool, confirm when users will need a linked report. Other dashboard products may offer different interactions, so assess the actual tool rather than applying this restriction universally. [1]

Build a metric dictionary, one row per number

For every number on the dashboard, write a row with these fields: metric name, plain-language definition, inclusion rule, exclusion rule, source system, owner, refresh expectation, and the decision it supports. Keep the definition short enough that two people reading it would compute the same number from the same data.

Worked example, hypothetical: metric name, Open service requests. Definition, requests received but not yet marked resolved. Inclusion, all requests logged through the intake form or email channel. Exclusion, duplicate submissions merged into an existing request, and test entries. Source, the request log. Owner, service coordinator. Refresh, every 15 minutes during business hours. Decision, whether to reassign a technician today.

Business requirements guidance recommends documenting functional and non-functional requirements and any business rules the team must follow, so project members understand what they need to deliver. A metric dictionary is a compact way to capture those rules for each number. [3]

Name a data owner for every metric

Each metric needs one named owner, not a committee. The owner confirms the definition, checks the source, and answers questions when the number looks wrong. Write the owner's role next to the metric, and note a deputy so the dashboard does not depend on one person being available.

Requirements guidance recommends defining success criteria, including acceptance parameters and metrics, so stakeholders share an understanding of what a successful outcome looks like. For a dashboard, that means agreeing what a correct number looks like before launch, not after the first dispute. [3]

Set refresh expectations per tile, not per dashboard

Different numbers can tolerate different delays. A cash position may need to be current to the hour; a monthly churn figure may only need to be current to the day. Write the expected refresh next to each metric, and state what the dashboard should display when the source has not updated yet, such as a last-updated timestamp or a stale marker.

Microsoft's Power BI guidance notes that its dashboard tiles update as the underlying data changes, and that hovering over an element displays a tooltip. Those behaviours are worth confirming against your own refresh expectations rather than assumed. [1]

Resolve two conflicting definitions without a winner-takes-all argument

Hypothetical: sales counts a closed deal when the contract is signed; finance counts it when the first invoice is issued. Both are reasonable. Rather than forcing one definition, write both as separate metrics with clear names, such as Signed contracts and Invoiced contracts, and note which decision each supports. If the dashboard only has room for one, the decision list decides which one stays.

Requirements guidance recommends describing current and future processes, because that step helps the team understand the project's impact on existing workflows. Conflicting definitions can reflect different workflows. Document the context for both and ask the relevant teams which decision each definition supports. [3]

Review the requirements set before design starts

Circulate the decision list, metric dictionary, owner list and refresh expectations to one person from each user group. Ask them to mark anything missing, unclear or already answered elsewhere. Keep the document short enough to read in one sitting, and update it before design begins.

Requirements guidance recommends presenting the document to stakeholders and revising it based on their feedback before approval, so everyone agrees on the direction and the risk of later misunderstanding is reduced. [3]

SistemaHub builds custom web applications for Philippine businesses, including business dashboards described as sales reports, staff management, analytics and real-time KPIs. The same requirements set applies whether the dashboard is built as part of a wider system or added to an existing one. [5]