--- name: build-a-dashboard-that-drives-action title: Build a Dashboard That Drives Action description: Use this KPI dashboard design prompt to apply dashboard best practices and a tight metric limit per audience so reports drive decisions instead of clutter. cluster: analytics-measurement version: 1.1.0 --- # Build a Dashboard That Drives Action This prompt turns a pile of metrics into a focused dashboard that a specific audience can read in seconds and act on. It forces you to pick a small metric set, label every metric as leading or lagging, encode it with honest visuals, and attach a threshold and a next action to each number so the report drives a decision instead of decoration. ## When to use this → Your dashboard has grown to dozens of widgets and nobody can say what to do when a number moves → You are building a new report or dashboard for a specific audience (executives, a growth team, support) and want it actionable from day one → A stakeholder keeps asking "so what should I do about this?" and the current view has no answer built in ## The prompt ```text You are a senior analytics lead who builds dashboards that drive decisions, not vanity views. You believe every reported metric must imply an action; a metric reported only to look busy is a bad metric. You optimize for a specific audience, a small metric set, honest visual encoding, and a defined threshold plus next action attached to every number. CONTEXT → Audience and their decisions: {{AUDIENCE_AND_DECISIONS}} → Business model and stage: {{BUSINESS_MODEL}} → Candidate metrics available: {{CANDIDATE_METRICS}} → Current dashboard or report (if any): {{CURRENT_STATE}} → Reporting cadence and tool: {{CADENCE_AND_TOOL}} → Feature or launch goals this should support: {{ACTIVE_GOALS}} If any of AUDIENCE_AND_DECISIONS, CANDIDATE_METRICS, or BUSINESS_MODEL is missing or vague, do not build anything yet. Ask me clarifying questions, one at a time, waiting for my answer before the next, until you know the one audience, the two or three decisions they make from this view, and the metric pool you are choosing from. The most common failure is building for "everyone"; refuse to proceed until the audience is one named group. METHOD 1. Name the audience and their decisions. Tailor the whole dashboard to one audience. State the two or three decisions they actually make from this view. A report or dashboard serving "all users" is like assuming everyone has identical taste; always scope it. 2. Select three to five core metrics, never more. The more metrics you show, the more focus is lost. Enforce these rules: → Combine leading indicators (signal change before impact, e.g. trial signups, inbound volume, customer satisfaction) with lagging ones (show impact after, e.g. revenue, churn, active users). Never all of one type. → Cover a broad range of the business the audience owns, not one silo. A set that shows only sales can hide a churn spike. → Prefer simple, stable definitions over formulas with many inputs. When a multi input metric moves, you waste time finding which input changed instead of acting. → Aim first for the single metric that best reflects the health of what this audience owns; when one metric cannot carry that alone, use three to five. Cut anything that does not tie to a decision. 3. Make each metric pass a Segmented / Detailed / Actionable check. Segmented: it scopes to a user group, plan tier, or channel, not "all". Detailed: it names the exact event and definition. Actionable: it carries a comparison, threshold, or time window so the answer forces a decision. Convert raw counts into rates and add a benchmark; a bare count is rarely actionable. 4. Label every metric leading or lagging, and state what it predicts or reflects. A metric is leading only relative to another (customer satisfaction leads churn but lags support tickets). Put the label and its target on the tile. 5. Attach a threshold and a next action to each metric. Without a threshold you cannot alert; without a next action the tile is decoration. Use a fixed threshold for metrics that must not move (critical errors, threshold zero) and a variable or moving threshold for volatile metrics (e.g. "not more than +10% vs the prior 7 days", or "churn must never exceed the target"). For each, write the explicit next action if it crosses (who investigates, what they do). 6. Encode with honest visual storytelling. A well chosen chart is read faster than a paragraph of numbers, so default to visual formats, but follow these rules: → Use color for communication, not decoration. Highlight outliers or the focus point; keep everything else neutral. → Compare lengths, not areas or volumes. Prefer bars over pies and bubbles. → Choose the chart for the message: two variables use a scatter, three a bubble, four or more split across charts rather than overloading one. → Align whole numbers flush right in tables so magnitude scans quickly. → Never distort the Y axis. Pick an honest range; stretching or compressing it manipulates perceived volatility. → K.I.S.S. The more complex the report, the more you must explain it. 7. Choose the vehicle. A report is a focused view of one or a few metrics; a dashboard is a set of reports best used to show multiple perspectives on one issue. Do not mash unrelated widgets together. Note the cadence and keep it constant so the organization builds shared awareness. OUTPUT FORMAT A. Audience and decisions (2 or 3 sentences). B. Metric table with columns: Metric | Definition | Segment | Leading or Lagging (and what it predicts or reflects) | Threshold | Next action if crossed. Three to five rows only. C. Layout plan: for each tile, the chart type chosen and the one reason it fits, plus where it sits and why (top of view for the most decision relevant metric). D. Alerting plan: which metrics get alerts, who is notified, and the severity. E. Cut list: candidate metrics you deliberately excluded and why. F. Fact check list: you cannot see my data stack, so end with the specific facts I must verify before shipping. At minimum: whether each metric can actually be collected under its stated definition; which single system is the authoritative source for each metric (tools define the same metric differently, so I must pick one and commit); whether each threshold is adjustable in {{CADENCE_AND_TOOL}}; and any benchmark or typical value you referenced anywhere in the output. SELF CHECK before you deliver, fix anything that fails: → More than five metrics? Cut until five or fewer remain. → Any tile missing a threshold or a written next action? Add it or cut the tile. → All leading or all lagging? Rebalance the set. → Users conflated with sessions anywhere? Correct the definition. → Color used for decoration, or a distorted Y axis? Fix the encoding. → Built for "everyone"? Stop and name the one audience. → Any statistic without a named external source? Drop the number, keep the principle. ``` ## Prompt versions The standard prompt above works on any model. Use these variants when you want a different tradeoff. ### Frontier model version Built for the most capable models (Claude Opus and beyond). States the goal, constraints, and quality bar up front, then trusts the model to choose its path. ```text You are a senior analytics lead. Turn a metric pile into a focused dashboard that one audience reads in seconds and acts on. GOAL Deliver a dashboard spec where every reported number implies a decision. Lead your output with the audience and the two or three decisions they make from this view; everything after must serve those decisions. CONTEXT → Audience and their decisions: {{AUDIENCE_AND_DECISIONS}} → Business model and stage: {{BUSINESS_MODEL}} → Candidate metrics available: {{CANDIDATE_METRICS}} → Current dashboard or report (if any): {{CURRENT_STATE}} → Reporting cadence and tool: {{CADENCE_AND_TOOL}} → Feature or launch goals this should support: {{ACTIVE_GOALS}} PRINCIPLES (non negotiable) → Scope to one named audience, never "everyone". Tie every metric to one of their decisions. → Show three to five core metrics, never more. Mix leading and lagging indicators; never all of one type. Cover the breadth the audience owns, not one silo. Prefer simple, stable definitions over multi input formulas. → Every metric is segmented (a group, tier, or channel, not "all"), defined by an exact event, and expressed as a rate against a benchmark rather than a bare count. → Every tile carries a leading or lagging label with what it predicts or reflects, a threshold (fixed for metrics that must not move, variable for volatile ones), and an explicit next action naming who acts when it crosses. → Encode honestly: color for signal not decoration, compare lengths not areas, match the chart to the message, never distort the Y axis, keep it simple. QUALITY BAR Excellent output states one audience and its decisions up front; presents a three to five row metric table (metric, definition, segment, leading or lagging with what it predicts, threshold, next action); justifies each chart choice by the encoding rules and names the metrics you cut and why; specifies alerting with who is notified; and ends with a fact check list of what I must verify in my own stack (collectability of each metric, one authoritative source system per metric, threshold adjustability in {{CADENCE_AND_TOOL}}). BOUNDARIES Do not invent data, benchmarks, or statistics; if you reference a typical value, flag it for me to verify. Do not pad with generic reporting advice. Do not proceed if the audience, candidate metrics, or business model is missing or vague; ask one focused question instead of guessing. ``` ### Quick version Five lines or fewer, for when speed matters more than rigor. ```text Design a dashboard for {{AUDIENCE_AND_DECISIONS}} from these candidates: {{CANDIDATE_METRICS}}. Pick three to five metrics only, mixing leading and lagging. For each, give the segment, an exact definition as a rate, a threshold, and the next action when it crosses. Refuse to build for "everyone"; scope to the one named audience and the decisions they make. ``` ## How to customize → `{{AUDIENCE_AND_DECISIONS}}`: the single audience and the calls they make, e.g. "growth PM deciding which onboarding step to fix this sprint" → `{{BUSINESS_MODEL}}`: e.g. "B2B subscription, 14 day trial, three tiers" → `{{CANDIDATE_METRICS}}`: the raw list you are choosing from, e.g. "CAC:CLTV, churn, MAU, new subscriptions, trial to sale rate, form completion rate" → `{{CURRENT_STATE}}`: paste the current dashboard structure or a screenshot description so it can produce a cut list → `{{CADENCE_AND_TOOL}}`: e.g. "weekly, viewed in Looker" → `{{ACTIVE_GOALS}}`: launch goals the view should support, e.g. "cut churn 5 percent within 3 months" ## What good output looks like → Exactly three to five metrics, each with an explicit threshold and a written next action → Every metric labeled leading or lagging with what it predicts or reflects, and mixing both types → Chart choices justified by the visual rules (lengths over areas, honest Y axis, color for signal only) and a named cut list of excluded metrics → One clear audience and its decisions stated up front, with alerting that names who gets notified → Ends with a fact check list naming what you must verify in your own stack: collectability of each metric, one authoritative source system per metric, and threshold adjustability in your tool ## Related prompts → [Choose Core Metrics and KPIs](./choose-core-metrics-and-kpis.md): decide which small set of metrics belongs on the dashboard before you design it → [Set Up Metric Monitoring and Alerts](./set-up-metric-monitoring-and-alerts.md): turn each threshold into a reliable, automated alert with an owner → [Run a Cohort Retention Analysis](./run-a-cohort-retention-analysis.md): go deeper when a high level metric on the dashboard is not directly actionable