Skip to main content
How a dashboard should be designed is covered in report writing concepts. This page is the governance around them: which ones exist, who owns them, and what stops the set growing without limit.
Fill in the register and the rules below once, as a team. Everything here is a decision, not a rule handed down.

The rules

Four hold across every dashboard.
  1. Every dashboard reads from the flat file. Not from a platform connector, not from a separate export. A dashboard on its own data source will eventually disagree with a report, and there is no way to settle which is right.
  2. Every number traces to a row in the data dictionary. A metric on a dashboard that isn’t defined anywhere is a metric being invented in public.
  3. Every dashboard has one named owner. Not a team. Dashboards with no owner are the ones that break silently and stay broken.
  4. Every dashboard answers a stated question. Written on the dashboard itself, so a viewer knows what it’s for and a reviewer can tell whether it still does its job.

The register

One row per dashboard. This is the list that gets reviewed. Examples use Doughnut Labs, a SaaS company that sells disruptive Doughnut Technology. Delete them and fill in your own. Tiers match the KPI tiers in the dictionary. A dashboard mixing tier 1 outcomes with tier 3 diagnostics usually needs splitting, because the two have different audiences and different refresh needs.

Naming

A consistent name makes a dashboard findable in a tool that lists forty of them alphabetically. E.g. {account}_{scope}_{cadence}, lowercase with underscores: doughnutlabs_paid-media_daily. Scope is the area, not the tool. A dashboard named “Looker Studio copy 3” is a dashboard nobody will open.

Refresh and lag

A dashboard that silently serves stale data is worse than one that is visibly broken. People act on it. Showing the failure is the safer default.

Access

Broad view access is usually right. Broad edit access is how a shared dashboard acquires someone’s private filter.

Reviewing and retiring

Dashboards need maintenance in the opposite direction from most documents: the work is removing tiles, not adding them. At each review, per dashboard:
  • Does it still answer its stated question?
  • Has anyone opened it this quarter? Most tools can tell you.
  • Which tiles have not changed a decision in a quarter? Delete them.
  • Do the numbers still match the flat file? Check one figure by hand.
  • Is the owner still the right person, and still here?
Retire rather than delete. Mark it retired, note what replaced it, and keep the row. Otherwise the same dashboard gets rebuilt in six months by someone who assumed it never existed.

Before you build a new one

Check the register first. Most requests for a new dashboard are answered by an existing one, or by adding a filter to it. A near-duplicate dashboard splits the audience and doubles the maintenance, in the same way a near-duplicate landing page splits traffic.
Last modified on August 12, 2026