Analytics Dashboard Design

A client needs to design a marketing or product analytics dashboard that connects business goals to daily metrics, with the right visualizations for the right audience.

---

How it works

1. You provide the client name, business goals, available data sources, and target audience for the dashboard
2. The skill builds a KPI hierarchy aligned to goals, specifies the dashboard layout with widget details, defines alert thresholds, and produces a data requirements doc
3. It returns a complete dashboard specification that a designer or engineer can implement without ambiguity

---

Prompt

You are designing an analytics dashboard specification for a Kate Makrigiannis consulting engagement. Kate uses this to help clients move from scattered metrics and ad-hoc reporting to a structured dashboard that answers the right questions for the right people. The output is a build-ready specification, not a wireframe. Before writing, read knowledge/voice-tone-guide.md -- use the client-facing voice.

Inputs I will provide:

• Client: {{CLIENT}} (company name, product, business model)
• Business goals: {{GOALS}} (what the business is trying to achieve -- growth targets, efficiency goals, product milestones, board-level objectives)
• Data sources: {{DATA_SOURCES}} (analytics tools, databases, APIs, spreadsheets -- what they have today and what they are willing to add)
• Audience: {{AUDIENCE}} (who will use this dashboard -- executives, ops team, product managers, ICs, the whole company. Can be multiple audiences with different views.)
• Context (optional): {{CONTEXT}} (current reporting setup, pain points with existing dashboards, tool preferences, team data literacy, refresh cadence requirements)

Step 1: Clarify the dashboard purpose

Before designing anything, answer three questions:

1. What decisions will this dashboard support? (If nobody will change behavior based on a metric, it does not belong on the dashboard.)
2. Who needs to see what? (Executives need trends and exceptions. Ops needs real-time signals. ICs need diagnostic detail.)
3. What is the current state of data infrastructure? (If the data does not exist yet, the dashboard spec becomes a data requirements doc first.)

If any of these are unclear from the inputs, flag: [CLARIFY WITH KATE: ...]

Step 2: Build the KPI hierarchy

Connect business goals to measurable KPIs in a clear hierarchy. Every metric on the dashboard must trace back to a business goal.

KPI Hierarchy

Business Goal: {{GOAL_1}}
├── Primary KPI: [metric that directly measures goal progress]
│   ├── Supporting Metric: [input that drives the primary KPI]
│   ├── Supporting Metric: [input that drives the primary KPI]
│   └── Supporting Metric: [input that drives the primary KPI]
└── Guardrail: [metric that ensures we're not breaking something while optimizing]

Business Goal: {{GOAL_2}}
├── Primary KPI: [metric]
│   ├── Supporting Metric: [metric]
│   └── Supporting Metric: [metric]
└── Guardrail: [metric]

For each metric in the hierarchy:

Metric	Definition	Calculation	Goal Connection	Owner
[Name]	[What it measures in plain language]	[Exact formula: numerator / denominator, time window]	[Which business goal it serves]	[Team or person responsible]

Metric count check: A well-designed dashboard has 8-15 metrics total. More than 15 creates noise. Fewer than 8 may miss important signals. If the hierarchy produces more than 15 metrics, recommend splitting into multiple views. If fewer than 8, check for blind spots.

Step 3: Design the dashboard layout

Specify the layout for each audience. If multiple audiences are specified, design separate views.

Dashboard Layout: {{AUDIENCE}} View

Layout principle: Most important metrics at top-left. Scanning pattern follows an F-shape: top row for headlines, left column for primary KPIs, right side for supporting detail.

Top Row: Headlines

Position	Widget	Metric	Chart Type	Why This Type	Refresh
Top-left	Primary KPI	[North Star or top-line metric]	Single number with trend arrow and sparkline	Immediate signal: are we up or down?	[Real-time / Hourly / Daily]
Top-center	Goal Progress	[Primary goal metric vs. target]	Progress bar or gauge	Visual gap-to-goal for quick read	[Daily / Weekly]
Top-right	Alert Summary	[Count of metrics in alert state]	Traffic light or badge count	Exception-based: draws attention only when needed	[Real-time / Hourly]

Primary KPI Row

Position	Widget	Metric	Chart Type	Why This Type	Refresh	Time Range
Row 2, Col 1	[KPI Name]	[Definition]	[Line chart / Bar / Area]	[Reason]	[Cadence]	[Last 30 days / 12 weeks / etc.]
Row 2, Col 2	[KPI Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]
Row 2, Col 3	[KPI Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]

Supporting Metrics Row

Position	Widget	Metric	Chart Type	Why This Type	Refresh	Time Range
Row 3, Col 1	[Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]
Row 3, Col 2	[Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]
Row 3, Col 3	[Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]

Guardrails Row

Position	Widget	Metric	Chart Type	Why This Type	Refresh	Threshold
Row 4, Col 1	[Name]	[Definition]	[Horizontal bar with threshold line]	Shows current value against acceptable range	[Cadence]	[Acceptable range]
Row 4, Col 2	[Name]	[Definition]	[Chart type]	[Reason]	[Cadence]	[Range]

Chart Type Selection Guide

Use this logic for each metric:

Data Pattern	Recommended Chart	Avoid
Single current value	Large number with trend arrow	Pie chart, bar
Trend over time (one series)	Line chart or area chart	Bar chart (harder to read trends)
Trend over time (2-3 series)	Multi-line chart	Stacked area (obscures individual trends)
Comparison across categories	Horizontal bar chart	Vertical bar (harder to label), pie chart
Part of whole (2-5 segments)	Stacked bar or donut	Pie chart with > 5 segments
Distribution	Histogram or box plot	Line chart
Funnel progression	Funnel chart	Bar chart
Goal vs. actual	Bullet chart or progress bar	Line chart (does not show target clearly)
Geographic data	Choropleth map	Tables

Step 4: Define alert thresholds

For each alertable metric, specify when to raise an alarm and who should respond.

Alert Definitions

Metric	Green (Normal)	Yellow (Watch)	Red (Act)	Notification Channel	Responder	Expected Response
[Metric 1]	[Range]	[Range]	[Range]	[Slack / Email / PagerDuty]	[Role]	[What they should do first]
[Metric 2]	[Range]	[Range]	[Range]	[Channel]	[Role]	[First response action]
[Metric 3]	[Range]	[Range]	[Range]	[Channel]	[Role]	[First response action]

Threshold-setting logic:

• Green: Within 1 standard deviation of the trailing 30-day average (or within target range if targets are set)
• Yellow: 1-2 standard deviations from average, or trending toward Red for 3+ consecutive data points
• Red: More than 2 standard deviations from average, or below a hard floor that indicates a problem (e.g., conversion rate < X%, error rate > Y%)

If the client does not have enough historical data to set statistical thresholds, use business-judgment thresholds and flag: [ASSUMPTION: alert thresholds set based on business targets rather than statistical baselines -- recommend revisiting after 90 days of data collection]

Step 5: Data requirements document

Specify exactly what data the dashboard needs and where it comes from. This is the handoff to the engineering or analytics team.

Data Requirements

Metric	Data Source	Table/Endpoint	Fields Needed	Transformations	Available Today?
[Metric 1]	[e.g., Google Analytics, Stripe, product database]	[Specific table or API endpoint]	[Column names or API fields]	[Any calculations, joins, or aggregations]	[Yes / Partial / No]
[Metric 2]	[Source]	[Table]	[Fields]	[Transforms]	[Yes / Partial / No]

Data gaps: For each metric marked "Partial" or "No":

• What's missing: [Specific data or instrumentation needed]
• Effort to add: [Low: config change / Medium: new event tracking / High: new integration or pipeline]
• Workaround: [Temporary alternative if the ideal data is not available yet -- e.g., "Use Google Analytics goal completions as a proxy until product-side event tracking is implemented"]

Step 6: Implementation roadmap

Phased Build Plan

Phase 1: Foundation (Week 1-2) Build with data that exists today. Focus on the top-row headline metrics and primary KPIs.

• Metrics included: [list]
• Data sources connected: [list]
• Audience: [who can use it immediately]

Phase 2: Depth (Week 3-4) Add supporting metrics and guardrails. Requires any new instrumentation from the data requirements.

• Metrics added: [list]
• New data sources: [list]
• Alerts activated: [list]

Phase 3: Polish (Week 5-6) Add audience-specific views, drill-down capabilities, and automated reporting.

• Additional views: [list]
• Drill-down paths: [e.g., "Click on conversion rate to see by channel, then by campaign"]
• Scheduled reports: [e.g., "Weekly email digest to leadership every Monday at 8am"]

Tool Recommendation (if applicable)

If the client asked for tool guidance or lacks a dashboard platform:

Tool	Best For	Cost	Data Literacy Needed	Integration Strength
[Tool 1]	[Use case]	[Pricing tier]	[Low / Medium / High]	[Connects to X, Y, Z]
[Tool 2]	[Use case]	[Pricing tier]	[Level]	[Integrations]

Only recommend tools if the context calls for it. If the client already has a platform, design for that platform.

Kate's Talking Points

• Why this dashboard is structured this way (goal hierarchy, not just "metrics we can track")
• What the dashboard will NOT tell them (limitations, metrics that require qualitative context)
• How to run the review cadence: daily glance, weekly review, monthly deep-dive
• When to revisit the dashboard design (after major product changes, new goals, or quarterly strategy shifts)

For defining the North Star Metric that anchors this dashboard, use /north-star-metric. For the metrics framework underlying the dashboard, use /metrics-dashboard. For funnel-specific views within this dashboard, use /funnel-analysis.

---

Business Goal: Grow utilization to 40% of enrolled employees by Q4
├── Primary KPI: Monthly Active Utilization Rate
│   ├── Supporting Metric: 30-Day Activation Rate (new members who complete first session)
│   ├── Supporting Metric: Weekly Active Members (rolling 7-day engaged users)
│   └── Supporting Metric: Sessions per Active Member (depth of engagement)
└── Guardrail: Employer Enrollment Accuracy (% of accounts with CSVs uploaded within 30 days)

Business Goal: Reduce member churn below 8% annually
├── Primary KPI: Annualized Member Churn Rate
│   ├── Supporting Metric: 30-Day Retention by Cohort
│   ├── Supporting Metric: Account Health Score (composite — see definition below)
│   └── Supporting Metric: At-Risk Account Count (accounts scoring below threshold)
└── Guardrail: Support Ticket Resolution Time (proxy for member frustration)

Business Goal: Reach $4.2M ARR by year-end
├── Primary KPI: Current ARR
│   ├── Supporting Metric: Net Revenue Retention (NRR)
│   ├── Supporting Metric: Employer Renewal Rate (trailing 12 months)
│   └── Supporting Metric: ARR Gap to Target (absolute $ and % remaining)
└── Guardrail: Average Contract Value Trend (ensure growth is not coming from discounting)