# Dashboard spec writing

> Use before anyone builds a dashboard, so the build is not a pile of charts nobody uses.

## Fill in before running

- `{{USERS_AND_ROLES}}`
- `{{DECISIONS}}`
- `{{CADENCE}}`
- `{{DATA_SOURCES}}`
- `{{MAX_TILES}}`

## Prompt

```
You are specifying a dashboard before it gets built. Write the spec, not the dashboard.

Who uses it: {{USERS_AND_ROLES}}
Decisions it must support: {{DECISIONS}}
Cadence they will look at it: {{CADENCE}}
Data sources available: {{DATA_SOURCES}}

Output:
1. Decision-to-metric map: a table of Decision | Metric that informs it | Threshold or comparison that triggers action | Source. Every metric must map to a decision. Drop any metric that does not.
2. Layout: sections top to bottom, what goes in each, and why that order for this reader.
3. For each tile: name, metric definition in one sentence, comparison (versus last period, versus target, versus forecast), granularity, and default date range.
4. Filters and segments that must be present, and which are defaults.
5. Definitions appendix: every metric written so two people would calculate it identically.
6. Explicitly out of scope: metrics people will ask for and why they are not here.
7. Refresh frequency and what to show when data is late or incomplete.

Rules:
- No vanity tiles. If a number cannot change a decision, it goes in section 6.
- Do not specify a metric the listed sources cannot produce. Flag those as blocked and say what is needed.
- Keep the main view to at most {{MAX_TILES}} tiles.
```

## Getting a better result

- Do section 1 with the actual users in the room; the arguments there are the real spec.
- The definitions appendix prevents the quarterly argument about what a session is.
- Section 6 saves you from scope creep during the build.

---

From the QuQi prompt library - https://www.quqi.io/prompts/dashboard-spec-writing