A request to build a dashboard usually starts with screen mockups. But if it is built before anyone agrees on what the numbers mean, every meeting goes back to how the numbers are defined, even after the screens are finished. Decide first who will use it for which decisions and how each metric is calculated, and the screens can simply follow the order those decisions need.

01. Start with the decisions the dashboard supports
Write down, as sentences, the decisions people will make by looking at the dashboard, such as “At the weekly meeting, decide which stores get more staff” or “At the end of the month, check whether each region met its target.” Once the decisions are set, the metrics you need, how often they are viewed, and the comparison baselines narrow down with them.
Different viewers need different levels of detail. Separating a summary for executives, a status view that operations leads check daily, and detail screens where staff look for causes eases the pressure to fit every number on one screen.
What to prepare
- Decisions to make from the dashboard
- Who views it, and how often
- Comparison baselines (targets, previous periods, other regions or teams)
02. Write each metric’s definition as a sentence
Even “sales” comes out differently depending on whether cancellations and returns are excluded and whether the order date or the payment date is used. For each metric, write the calculation, the reference date, and the exclusions in one sentence, and confirm it with the department responsible.
If a metric is already used in other reports, first check that the definitions match. If they differ, decide which one to treat as the standard, and consider showing the definition on the screen as well.
What to prepare
- Metric name and calculation
- Reference date and exclusions
- The department that confirms the definition
03. Check data sources and refresh cycles
For each metric, check which data from which system it is calculated from, and whether data gathered in Excel or by hand is mixed in. If there are several sources, also check that the codes and names referring to the same thing match.
Separate metrics that need checking right away from those that are fine to view daily or weekly. Showing the refresh cycle and the last refresh time on screen means fewer questions about when the numbers are from.
04. Lay out screens in the order people ask questions
Users usually ask in this order: “Are things on track right now?” “Where is something different?” and “Why?” Put the key metrics and comparison baselines needed for decisions at the top, comparisons by region and period in the middle, and detailed lists at the bottom, and the screen follows the order of the questions.
Whether comparisons are easy to see matters more than the chart type. Use color only to distinguish status, and don’t rely on color alone: add text or symbols as well. Label numbers with their units and reference period. On detail screens, let users drill down to the source list to check where the numbers come from.
What to prepare
- Top: key metrics and comparison baselines
- Middle: comparisons by region and period
- Bottom: detailed lists and source data
05. Retire metrics no one uses
Once the dashboard is in use, metrics tend to keep multiplying as requests come in. Check regularly whether each metric is actually used for decisions, and move metrics no one has looked at for a long time to detail screens or retire them.
When you change a metric’s definition, record the date and the reason, and let users know. Comparing numbers from either side of the change at face value can lead to wrong decisions.
That’s all you need before a consultation.
If you prepare the items below, we can align on scope more quickly in early discussions. Even if not everything is ready, we can start with your current situation.
- Decisions the dashboard supports, and its users
- Calculation, reference date, and exclusions for each metric
- Data sources and refresh cycles
- How summary, status, and detail screens are divided
- A log of definition changes and a schedule for retiring metrics
KPS project guide · The specific technical setup and conditions depend on your requirements.




