Create Dashboards

Dashboards are where a team returns to recurring questions. They should make routine review easier, not preserve old ambiguity in a prettier layout.

When to create a dashboard

Create a dashboard when:

• the same set of questions recurs weekly or monthly
• the audience is stable
• the metrics are understood well enough to reuse
• the component cards have already been reviewed

If the underlying questions are still changing every day, stay in the Workbench longer.

A good dashboard workflow

The reliable path is:

1. validate the base question in the Workbench
2. refine the result until it is conceptually right
3. model the metric if the definition still drifts
4. save the result as a card
5. assemble related cards into a dashboard

This keeps dashboards downstream from trusted work instead of treating them as the first place meaning gets negotiated.

Dashboard design principles

One dashboard, one operating conversation

Keep a dashboard focused on one decision area:

• executive overview
• revenue and billing
• product usage
• customer retention
• pipeline health

Use clear titles

A card title should make sense even if the reader never saw the original conversation.

Remove stale cards

If a card no longer supports a real decision, remove it. Dashboard sprawl reduces trust.

A practical review before publishing

Before you treat a dashboard as shared truth, check:

• every card uses the expected source
• titles are understandable
• metric definitions are stable enough for reuse
• time windows and filters are intentional
• the overall dashboard supports one coherent review workflow

Maintenance expectations

Dashboards need periodic review after:

• schema changes
• source refresh issues
• metric definition changes
• major business process changes

The dashboard is not “done” because it exists. It is useful because the team can keep trusting it.