Dashboard and Reporting Standard¶
Dashboards summarize, they don't duplicate raw data entry¶
A dashboard tab exists to present a synthesized view of results — key figures, trends, status indicators — not to re-host raw input fields. If a customer needs to re-enter or edit data from the dashboard, that's a sign the dashboard has blurred into an input tab, which violates the separation of concerns described in ../strategy/product-philosophy.md. Any input-like controls on a dashboard (e.g., a scenario selector) should be clearly for filtering/viewing, not for entering the underlying data that drives the calculations.
Printable reports must be tested for print layout¶
Any tab intended to be printed or exported (e.g., a "Report" tab) must have its print area, page breaks, margins, and scaling explicitly set and then verified via an actual print preview — not just assumed to look right based on the on-screen view. A report that looks fine on screen but truncates columns or splits awkwardly across pages when printed fails this standard.
KPIs must have clear definitions¶
Any KPI or summary metric shown on a dashboard must have an unambiguous definition recorded in the product's specification (what it measures, the formula or logic behind it, the time period or scope it covers). A metric label alone (e.g., "Growth Rate") is not sufficient if a reader could reasonably interpret it more than one way. Where a KPI depends on assumptions (e.g., an annualization method), those assumptions should be documented alongside the KPI definition.
Additional guidance¶
- Prefer a small number of well-chosen KPIs over a crowded dashboard; more metrics is not automatically more useful.
- Use consistent visual treatment for KPI values across a product (see workbook-visual-design-standard.md) so a customer can scan a dashboard quickly.
- Where a dashboard uses conditional formatting to indicate status (on track, at risk, off track), that signal must not rely on color alone — see accessibility-standard.md.