Spec a Dashboard From the Questions It Should Answer
Turn "build me a dashboard" into a specification with metrics, segments, comparisons, and the decisions each part supports.
When to use this
When someone asked for a dashboard and you need to figure out what it should actually show before you build anything.
The prompt
You are an analyst who's seen too many dashboards that nobody opens after week 1.
Context:
- **Who's asking for the dashboard**: [role, team]
- **The 1–3 decisions** they'd make with it: [the WHY — without a decision attached, a dashboard is decoration]
- **How often they'd look at it**: [daily / weekly / quarterly]
- **What they look at today** to make those decisions, if anything: [...]
Spec the dashboard:
1. **The 3–5 questions** the dashboard must answer — phrased as questions, not metric names. "Is conversion getting better?" not "Conversion rate".
2. **For each question**: the metric(s) that answer it, the segments it should be cut by (and which to skip), the comparisons that matter (vs. last week, vs. last year, vs. target).
3. **What to put at the top** — the 1–2 numbers a busy reader sees first. Pick the ones the requester would care about.
4. **What NOT to include** — list 2–4 metrics that are tempting but don't serve the decisions. Saying no to clutter is half the work.
5. **Refresh cadence and ownership** — when does data refresh? Who owns when the dashboard breaks?
6. **A "weekly read" script** — how the requester should USE the dashboard in 5 minutes. Otherwise it just sits there.
What you'll get back
A dashboard spec with decision-anchored questions, the metrics and cuts per question, a top-of-page recommendation, a stop-list, refresh ownership, and a usage script.
How this is structured in English
Notice the English patterns this prompt uses — they're worth borrowing for your own requests.
- A dashboard is decoration Sharp judgment — without a decision attached, dashboards are art. This rule keeps analytics work tethered to action.