Data Dashboard Intelligence

Data Dashboard Intelligence

This skill teaches you how to turn normalized event data into dashboards that look and feel premium — not generic template outputs. It works on field semantics (what the data looks like), not platform names (where it came from). By the time you use this skill, platform skills have already normalized fields into universal types like status, duration_ms, cost, and timestamp. The core idea is simple: every field in a dataset has a shape (numeric, categorical, temporal, textual) and a semantic (it measures time, money, status, identity, etc.). The shape tells you which component to use. The semantic tells you how to aggregate it and what to call it. Together, they produce a dashboard that tells a story instead of just displaying numbers.

1. Field-to-Component Mapping

When you see a field from getEventSamples or analyzeSchema, pick the right component based on what the field is, not what it's named.

• Timestamp with < 5 distinct dates → MetricCard fallback (sparse timeseries look broken)
• Categorical with exactly 1 unique value → skip entirely (no information content)
• Numeric with identical values in every row → static MetricCard with "Constant value" note
• Categorical with > 6 values → BarChart, never PieChart (pie charts become unreadable past 6 slices)

2. Aggregation Selection

The reason aggregation matters is that the same field can tell completely different stories depending on whether you count it, average it, or sum it. Getting this wrong produces dashboards that say "Total Duration: 847,291ms" instead of "Avg Duration: 4.2s" — technically correct but useless.

3. Dashboard Story Structure

Premium dashboards tell a story in layers. Users scan in an F-pattern (top-left → across → down-left → across), so the most important information goes top-left and the detail goes bottom.

The One-Page Dashboard Story

Row 1: THE HEADLINE (Hero Stat) + Supporting KPI Cards (3-4 cards)
        → User knows "are things good or bad?" in 2 seconds
Row 2: THE TREND (TimeseriesChart, full width)
        → User sees direction over time in 5 seconds
Row 3: THE BREAKDOWN (BarChart left + PieChart right, half width each)
        → User sees what's driving the numbers in 10 seconds
Row 4: THE DETAILS (DataTable, full width)
        → User investigates specific records in 30+ seconds

This is the progressive reveal principle from data storytelling: start with the conclusion (hero stat), show the evidence (charts), then provide the raw material (table). Never put the table first — it forces users to do the analysis themselves instead of giving them the answer.

Component Ordering

4. Hero Stat Selection

The hero stat is the single number that anchors the entire dashboard. It should be the first thing a user reads and immediately tell them whether things are going well. Choose it based on the domain, which you detect from the field names — not the platform name.

5. Data Quality and Graceful Degradation

The most common failure mode for AI-generated dashboards is showing broken charts when data is sparse or missing. This section prevents that by teaching you to assess what you have before deciding what to show.

Minimum Data Thresholds

Fallback Chains

When a primary component can't render well, fall back to simpler alternatives instead of showing a broken chart:

• TimeseriesChart → BarChart (grouped by date) → MetricCard (total count)
• PieChart → horizontal BarChart → MetricCard (dominant category %)
• BarChart → DataTable (sorted by count) → MetricCard (unique count)

Field-Level Degradation

6. Component Headlines

Every component needs a title that a non-technical person can understand. The reason this matters is that agency clients show these dashboards to their clients — a label that says "execution_id COUNT" makes the agency look amateur.

Formulas

Vocabulary Normalization

When writing titles, translate platform-internal terms into universal dashboard language. This keeps dashboards clean regardless of source platform:

7. Chart Type Decision Tree

When choosing between chart types, follow this logic:

What kind of data?
├─ Categorical (string, enum)?
│  ├─ 2–6 unique values → PieChart / DonutChart
│  ├─ 7–15 values → horizontal BarChart
│  └─ 16+ values → DataTable (too many for any chart)
│
├─ Temporal (datetime)?
│  ├─ ≥ 5 data points → TimeseriesChart (line)
│  └─ < 5 data points → BarChart by date or MetricCard fallback
│
├─ Numeric (continuous)?
│  ├─ Comparing across categories → vertical BarChart
│  ├─ Single summary value → MetricCard
│  └─ Distribution → BarChart with ranges
│
└─ No good match → DataTable column

For detailed chart configuration patterns (axis labels, color assignments, responsive sizing), see references/chart-patterns.md.

References

These files provide domain-specific depth when needed. Read them when the SKILL.md guidance isn't specific enough for the task at hand.