Start here.
Choose the decision and the responsible person first. Define each metric, its time window, exclusions, and freshness. Let the person inspect the records behind the number and take the appropriate next step. Add a summary only when it preserves those definitions and makes uncertainty visible.
- Define a decision before choosing the headline number.
- Events, unique people, and completed outcomes are different units.
- Keep stale or unavailable information visible.
Begin with the action after the glance.
An inquiry dashboard might help a coordinator find work that needs attention. Its job is not to display every available statistic. The next action could be assigning an unowned inquiry, checking an overdue handoff, or resolving a missing field.
Write that action beside the metric. If a change in the number would not affect what anyone does, the number may belong in a report or detail view instead of the main screen. The owner of the decision should help define what requires attention.
Separate status from performance. “Needs review” is a work state; “accepted within one day” is a timed outcome. Counting one does not establish the other.
Give the metric a definition.
For an illustrative inquiry queue, “open” might mean received but not closed, including assigned items. “Waiting for review” might exclude items missing required input. Those sets answer different questions even when their totals happen to match.
A definition needs a unit, numerator, denominator where applicable, date window, and treatment of repeated or cancelled records. It should also say whether dates use arrival time, update time, or completion time. Otherwise two reasonable screens can disagree without either calculation being broken.
| Decision | Metric definition | Record-level next step |
|---|---|---|
| Assign work | Unassigned inquiries received and not closed | Open the inquiry and select a valid owner |
| Resolve a blocker | Items held for missing required information | Inspect the source and named missing field |
| Check waiting time | Age since entering review, excluding closed items | Review the oldest item and its history |
| Evaluate completion | Accepted handoffs divided by eligible inquiries in the stated cohort | Inspect rejected and unresolved items too |
A real product shows why the unit matters.
In VLVTN’s committed reporting helper, a click-through calculation uses destination-click event count divided by page-view event count. Those are event counts, not unique people. A listener can produce several events, and a recorded outbound choice does not confirm a stream.
That example supports a general design rule: keep the observed event separate from the outcome you hope it leads to. A completed form is not automatically a qualified inquiry; an approved draft is not automatically a fulfilled request.
The VLVTN story describes this source-level definition without showing private campaign data. A dashboard for your project needs the definitions of its own actual report, not a borrowed interpretation of a familiar label.
Show freshness, missing data, and disagreement.
A result should identify its covered period and last successful refresh. A failed refresh must not make old data appear newly current. If some sources are unavailable, say which portion of the result is incomplete.
A zero needs context. It can mean no eligible records, no matching events, missing data, or a failed request. Those conditions should not collapse into one reassuring card. Similarly, an imported total can differ from a reconciled total because the two use different evidence.
Our MusicList and Clef stories illustrate related boundaries: sourced data differs from owner verification, and recorded financial information differs from a verified deposit. The screen should preserve the distinction that matters to its decision.
Let a person inspect and act.
Provide the list or source records behind a count, retaining the current filters. A reviewer should be able to find why an item belongs in the set and understand how an edit or approval changes its state. Record actions with enough context to investigate a mistake.
A summary that says “follow-up is falling behind” should identify the period, compared values, and unresolved items supporting that conclusion. If a model cannot obtain that evidence, it should avoid presenting the statement as established.
AI can help describe a checked set of records, but it cannot supply a missing metric definition. The ordinary table, filters, and source links still need to work when the summary is unavailable.
Test the decision with representative records.
Check an empty period, partial data, a stale refresh, a cancelled record, repeated events, and records crossing a date boundary. Ask the responsible person to make the intended decision from each screen.
Verify both the aggregate and its detail list. A correct total with an inconsistent drill-through can still mislead a person. The useful acceptance condition is that the decision can be made from accurate, current-enough evidence, with uncertainty shown where it remains.
A dashboard brief for one decision.
Specify the evidence before the visual treatment.
- Decision
- Who acts, and what would change their next step?
- Definition
- The unit, period, included records, and exclusions.
- Freshness
- What refreshes, how often, and what a failed refresh looks like.
- Inspection
- The underlying records and the permitted action from them.
A couple of common questions.
Should every dashboard have an AI summary?
No. First verify that its definitions, filters, source records, and next actions work. A summary is useful only if it helps the actual decision without hiding uncertainty.
Why do two dashboards show different totals?
Compare time windows, units, included records, repeated events, and refresh times. Different definitions can produce different valid totals; the interface should make those differences visible.