Prompt library
Specify a dashboard around decisions
Decision-first specification inverts the usual chart-collection process and is why some dashboards run companies while most decorate them. The kill list and the 30-day deletion test build in the lifecycle discipline that keeps dashboard sprawl from reaccumulating.
DataPlan
Last reviewed July 17, 2026
The prompt
Specify a dashboard.
Who uses it and the decisions they make with it: {{audience}}
Available data: {{data}}
Method:
1. Decision inventory first: list the recurring decisions or checks these users make, each with its cadence and the question they ask the data. A dashboard is a decision surface; charts come later.
2. For each decision: the ONE number or comparison that answers it, the threshold or comparison point that makes the number meaningful (target, last period, peer set), and the drill-down the user needs when the number is bad.
3. Layout: order panels by decision frequency, top-left first. Kill any panel that does not map to a decision from step 1; list the killed panels and why they wanted in.
4. Per panel spec: chart type with the perceptual reason, time window, refresh need, and the annotation that carries the "so what".
5. The staleness contract: how the dashboard shows its own data freshness, because a silently stale dashboard is worse than none.
6. The 30-day test: what usage pattern would prove this dashboard earns its maintenance (opens, decisions cited), and what would justify deleting it.
No panel without a decision; no decision without a threshold.Run in idaptOpens a new chat with the prompt prefilled. Nothing sends until you press send.
Fill in the variables
| Variable | What it is | Example |
|---|---|---|
| {{audience}} | Users and their recurring decisions | support leads: staffing next week, escalation triage, SLA health |
| {{data}} | What data is available | ticket system export, CSAT, staffing schedule |