Data Visualization

Data Visualization

When to Use

• Choose chart types that match the analytical question and audience decision
• Apply design principles: honest axes, labels, color, hierarchy, small multiples
• Meet accessibility needs: colorblind-safe palettes, contrast, alt-text guidance
• Design executive summaries and operational monitoring dashboards (layout and viz layer)
• Build actuarial/insurance views: loss triangles, trend panels, distributions, scenario bands
• Audit or fix misleading charts (truncated axes, dual-axis abuse, cherry-picking)
• Write viz specs for engineers (data bindings, encodings) or slide narrative outlines
• Review matplotlib, plotly, ggplot, or BI tool outputs for clarity and integrity

When NOT to Use

• Full exploratory analysis, modeling, A/B tests, or MLOps → data-scientist
• Narrative arc, key messages, and storytelling without chart design focus → storytelling
• Cloud cost allocation, CUR analysis, or FinOps cadence → finops-analyst
• Dashboard SQL, KPI definitions, cohort/funnel queries, or BI tool admin → bi-analyst
• dbt marts, warehouse modeling, tests, and lineage → analytics-data-engineer
• Assumption selection, governance packs, or change control → assumption-setting
• ETL/ELT pipeline build, orchestration, or data quality frameworks → data-warehouse-engineer
• Interactive HTML dashboard products with filters and deployment → route to frontend or product skills if present; pair with bi-analyst for metric definitions

Related skills

Core Workflows

1. Frame message, audience, and medium

1. State the decision or question the viz must support 2. Identify audience (exec, ops, regulator, engineer) and medium (slide, dashboard, report, spec) 3. List metrics with definitions; confirm numerator/denominator with bi-analyst if unclear 4. Note uncertainty (ranges, confidence, scenarios) before choosing encodings 5. Pick one primary message per view; defer secondary points to appendix or drill-down

See `references/data_visualization_scope.md`.

2. Select chart type and encoding

1. Map question type (comparison, trend, distribution, relationship, composition, geography) to chart family 2. Prefer simplest chart that carries the message; add small multiples before exotic forms 3. Document encoding: x, y, color, size, facet, and sort order 4. Flag when tables beat charts (exact lookup, many dimensions, audit trails)

See `references/chart_selection_and_message.md`.

3. Apply design and accessibility

1. Set axis baselines, units, and tick density; justify log scales 2. Choose color for meaning (not decoration); test colorblind and contrast 3. Write labels, titles that state the insight, and source/refresh footnotes 4. Provide alt text or long descriptions for static exports

See `references/design_principles_and_accessibility.md`.

4. Design dashboards and executive views

1. Apply visual hierarchy (F-pattern, KPI strip, drill paths) 2. Limit density; separate monitoring vs exploratory layouts 3. Add context: targets, prior period, benchmarks, annotations for events 4. Specify interactions only when they change decisions (filters, drill, alerts)

See `references/executive_and_dashboard_design.md`.

5. Actuarial and insurance visualization

1. Use standard loss triangle layouts; label development and valuation periods 2. Show trends and distributions with explicit basis (accident year, calendar year) 3. Present scenarios as bands or small multiples—not false point precision 4. Coordinate labels with assumption-setting and actuary for technical definitions

See `references/actuarial_insurance_visualization.md`.

6. Ethics check and handoff

1. Run misleading-viz checklist before publish 2. Produce engineer spec (data schema, encodings, refresh) or slide outline (headline per chart) 3. Separate exploration drafts from production assets

See `references/misleading_viz_and_ethics.md`.

Output standards

• One primary insight per chart; title states the takeaway
• Axes labeled with units; zero baseline when magnitude comparisons matter
• Source, as-of date, and filters documented on every external-facing viz
• No fabricated data or smoothed series without disclosure
• Accessibility: do not rely on color alone; meet contrast targets for text and UI chrome
• Specs list fields, aggregations, sort, and edge cases (nulls, small n)

When to load references

Actuarial and insurance visualization

Table of contents

1. Audience and rigor 2. Loss development triangles 3. Trend and experience panels 4. Distributions and large losses 5. Scenarios and sensitivity 6. Coordination with actuarial skills 7. Regulatory and external reporting

Audience and rigor

Never simplify away basis (accident year vs underwriting year vs calendar year).

Loss development triangles

Standard heatmap triangle

• Rows: accident (or underwriting) period
• Columns: development age (12, 24, 36 months…)
• Cell value: incurred, paid, or case outstanding—state which
• Color: magnitude; use sequential scale; label diagonal and latest column

Link ratio triangle

• Show age-to-age factors adjacent to dollars triangle or on separate tab
• Highlight volatile cells with annotation, not only color

Annotations

• Mark large losses or one-time events in footnotes
• Note restatements and valuation date
• Distinguish gross vs net of reinsurance

Technical fitting and selection belong to actuary; this skill covers layout and labeling.

Trend and experience panels

Always show volume (exposure, claim count) alongside rates.

Distributions and large losses

• Histogram of claim size: log x-axis often required; cap axis with disclosure
• Pareto view: cumulative % of loss vs % of claims
• CAT events: separate layer or annotation; do not smooth into trend
• Outliers: table appendix with policy/claim IDs per governance rules

For tail risk, prefer exceedance curve or return period chart with explicit modeling source.

Scenarios and sensitivity

Rules:

• Label assumption set version; link to assumption-setting
• Show ranges, not false point estimates
• Separate best estimate from stress visually

Coordination with actuarial skills

Regulatory and external reporting

• Match prescribed layouts when filings mandate forms
• Include methodology footnotes and data sources
• Suppress small cells per confidentiality rules; document suppression
• Version charts with model run ID and assumption effective date

Charts support filings; legal wording and sign-off sit outside this skill.

Chart selection and message

Table of contents

1. Start with the question 2. Question-to-chart map 3. Composition and part-to-whole 4. Ranking and comparison 5. Time and trends 6. Distribution and uncertainty 7. Relationship and correlation 8. Geography 9. When tables beat charts 10. Anti-patterns

Start with the question

Write one sentence: "After seeing this, the audience will ___."

If the sentence needs two unrelated verbs, split into two views.

Question-to-chart map

Composition and part-to-whole

• Stacked bar: parts sum to 100% or total; max ~5 segments
• Pie / donut: last resort; max 3–4 slices; label values directly
• Treemap: exploration, not executive proof; label large cells only
• Waterfall: explain variance bridge (budget, revenue walk)

Always show absolute and rate when stakes are high (claims, revenue).

Ranking and comparison

• Sort bars by value or business priority, not alphabetically
• Dot plot beats bar when many categories (12+)
• Slope chart for exactly two periods per category
• Dumbbell for range between two values (before/after)

Avoid dual y-axes; see ethics reference.

Time and trends

Use log scale only when multiplicative change matters; label axis as log.

Distribution and uncertainty

• Histogram: bin width matters; try consistent bins across facets
• Box plot: show median and IQR; explain outliers
• Violin: density estimate—disclose method for technical audiences
• Error bars: define CI vs SE vs SD in caption
• Fan chart / ribbon: scenarios or prediction intervals

Never imply false precision (four decimal places on noisy estimates).

Relationship and correlation

• Scatter with transparency or jitter for overplotting
• Color third dimension only when pattern survives without color
• Regression line: state functional form and exclusions
• Heatmap of correlation: order variables logically; diverging scale centered at 0

Correlation charts are not causation—pair with storytelling for narrative if needed.

Geography

• Choropleth for rates (per exposure, per capita), not raw counts
• Use consistent projection; avoid extreme color breaks
• Offer table backup for small regions suppressed in map

When tables beat charts

Use tables when:

• Exact values required (regulatory, accounting, audit)
• Many dimensions (>2) without a single comparison story
• Mixed units or footnotes per row
• Small n where chart implies false continuity

Enhance tables with heat scales on numeric columns sparingly.

Anti-patterns

Data visualization scope

Table of contents

1. Purpose 2. In scope 3. Out of scope 4. Deliverable types 5. Tool posture 6. Quality bar

Purpose

Turn verified data into honest, decision-ready visuals. The skill owns what to show and how to encode it—not upstream modeling, pipeline build, or narrative-only comms.

In scope

Out of scope

Deliverable types

Tool posture

Guidance is tool-agnostic. Map concepts to the user's stack:

Prefer the team's standard palette and template when one exists.

Quality bar

Before delivery:

• [ ] Primary message stated in title or callout
• [ ] Definitions aligned with metric owner (bi-analyst if needed)
• [ ] Axes and units correct; transformations disclosed
• [ ] Sample size and suppression rules documented
• [ ] Ethics checklist passed (references/misleading_viz_and_ethics.md)
• [ ] Accessibility: color + non-color cues; contrast checked for exports

Design principles and accessibility

Table of contents

1. Visual hierarchy 2. Axes, scales, and units 3. Color 4. Typography and labels 5. Small multiples 6. Accessibility checklist 7. Alt text and long descriptions 8. Export and print

Visual hierarchy

1. Most important metric or chart top-left (LTR layouts) 2. Use size and weight before extra color 3. Limit dashboard to 5–7 primary elements per screen 4. De-emphasize gridlines and borders; emphasize data ink 5. One accent color for the story metric; neutrals elsewhere

Axes, scales, and units

Annotate events (launch, rate change, storm) sparingly on time series.

Color

Semantic use

Colorblind-safe palettes

Prefer:

• Okabe–Ito or ColorBrewer qualitative sets
• Test with deuteranopia/protanopia simulators
• Redundant encoding: shape, pattern, labels, position

Avoid:

• Rainbow scales for continuous data
• Red-green only pair for critical distinction

Contrast

• Text on background: target WCAG AA (4.5:1 body, 3:1 large text)
• Chart lines thick enough for projection rooms (≥2px at slide scale)

Typography and labels

• Titles state insight: "Loss ratio rose 3pt YoY driven by CAT" not "Loss ratio chart"
• Subtitles carry definition or filter: "US P&C, accident year 2024, ex reserve releases"
• Direct labels on final series when ≤4 lines; legend only when necessary
• Footnotes: source, refresh, suppression, FX basis
• Avoid rotated axis labels when horizontal bar or transpose fixes readability

Small multiples

Use when:

• Same chart type, same scale, different segments (region, LOB, product)
• Comparing shape of distribution or trend across groups

Rules:

• Shared axes across panels when comparison is goal
• Consistent ordering of categories in every panel
• Panel titles = segment name; super-title = overall message

Accessibility checklist

• [ ] Color is not the only differentiator (shape, label, pattern)
• [ ] Palette checked for colorblind safety
• [ ] Contrast sufficient for text, lines, and UI controls
• [ ] Interactive tooltips have keyboard path or static fallback
• [ ] Motion/autoplay disabled or user-controlled
• [ ] Alt text or long description provided for static images
• [ ] Data table available for screen-reader users when feasible

Alt text and long descriptions

Alt text (short): chart type + main trend + key number.

Example: "Line chart: monthly active users rose from 1.2M to 1.8M Jan–Dec 2025."

Long description (report appendix): axes, filters, outliers, and caveats in prose.

For dashboards, link to accessible table export or documented filter state.

Export and print

• Slide exports: minimum font 18–24pt for axis labels at 16:9
• Print: test grayscale legibility
• Embed fonts or outline text when brand requires
• Include as-of timestamp on operational PDFs

Executive and dashboard design

Table of contents

1. Executive vs operational 2. Executive summary layout 3. Operational monitoring layout 4. KPI design 5. Interactions and drill 6. Refresh and trust 7. Slide vs live dashboard 8. Handoff to BI

Executive vs operational

Do not paste operational dashboards into board decks without redesign.

Executive summary layout

Suggested zones (top to bottom):

1. Headline strip — 3 KPIs with delta vs plan and prior period 2. Primary chart — one trend or bridge answering the meeting question 3. Supporting chart — breakdown or driver (small multiple or ranked bar) 4. Risks / actions — bullets, not another chart 5. Appendix link — detail tables and definitions

Rules:

• One ask per page (continue, investigate, approve spend)
• Show ranges or scenarios when decisions are sensitive to assumptions
• Footnote definitions; align with finance or actuarial owners

Operational monitoring layout

1. Alert banner — breaches only (color + text) 2. Throughput KPIs — volume, error rate, latency, backlog 3. Time series — last 24h / 7d with event markers 4. Breakdown — top contributors to current anomaly 5. Drill — to entity list (account, claim, service)

Avoid:

• More than two accent colors for status (ok / warn / critical)
• Charts without defined owner and runbook link

KPI design

Each KPI tile documents:

Visual:

• Large number, small comparison line
• Sparkline optional when trend adds decision value
• Red/green only with numeric sign and icon

Coordinate definitions with bi-analyst.

Interactions and drill

Add interaction only when it changes action:

Spec default filter state and empty state behavior.

Refresh and trust

Display on every dashboard:

• Last refresh timestamp (timezone labeled)
• Data latency (T+1, near real-time)
• Known gaps (missing region, partial day)

If refresh fails, show stale badge—do not show silent old data as current.

Slide vs live dashboard

For slides, deliver section intent + chart type + headline; full visual design may sit with brand or design skills.

Handoff to BI

Viz spec minimum for bi-analyst or BI implementers:

## View: [Name]
**Audience:** [role]
**Refresh:** [cadence]
**Filters:** [list + defaults]

### KPIs
| KPI | Source field | Aggregation | Comparison |

### Charts
| # | Type | Title (insight) | X | Y | Color | Sort | Notes |

### Edge cases
- Null handling:
- Suppression rules:
- RLS / scope:

Pair with metric definitions from bi-analyst before build.

Misleading visualization and ethics

Table of contents

1. Principles 2. Pre-publish checklist 3. Truncated and manipulated axes 4. Dual axes and indexing 5. Cherry-picking and survivorship 6. Aggregation traps 7. Uncertainty and significance 8. Review workflow

Principles

1. Show the data the audience needs for the stated decision—no more, no less 2. Do not distort perception through scale, cropping, or encoding tricks 3. Disclose filters, exclusions, transformations, and uncertainty 4. Separate exploration drafts from certified external views 5. Escalate when pressure requests cosmetic exaggeration—document and refuse

This is ethical communication guidance, not legal advice.

Pre-publish checklist

• [ ] Title matches what the data actually shows
• [ ] Axis baselines and units correct; log/discontinuities labeled
• [ ] Comparisons use consistent definitions and periods
• [ ] Denominators shown for rates; exposure changes visible
• [ ] Outliers and one-time events called out
• [ ] Color does not imply unsubstantiated good/bad
• [ ] Sample size and suppression documented
• [ ] Source and as-of date on the visual
• [ ] No hidden filters or post-hoc segment cuts without disclosure

Truncated and manipulated axes

If truncation is required for readability, flag prominently in title or footnote.

Dual axes and indexing

Dual y-axis (two scales): invites viewers to infer correlation between unrelated series.

Prefer:

• Two panels stacked with shared x-axis
• Indexed lines (rebase to 100 at start) with one y-axis
• Scatter if relationship is the claim

If dual axis is mandated by template:

• Label both scales clearly
• Do not imply causation in title
• Add correlation disclaimer in footnote

Cherry-picking and survivorship

Document why any subset was chosen.

Aggregation traps

Pair with data-scientist when statistical validity is in question.

Uncertainty and significance

• Show intervals or scenario bands when estimates are noisy
• Avoid implying precision beyond measurement (four decimals on volatile KPIs)
• Do not use chart icons or icons only for material deltas
• For experiments, route design to data-scientist; viz shows CI, not just uplift arrow

Review workflow

1. Author completes checklist above 2. Peer (analyst or actuary) verifies definitions and filters 3. Stakeholder sign-off for external/board packs 4. Archive spec + data snapshot ID with published chart

When asked to "make it look better" by distorting scale:

• Propose honest alternatives (context line, indexed view, annotation)
• Record request and response in ticket or memo
• Route narrative pressure to storytelling without bending axes