Skip to content

Choose a chart

5 min read · Updated 3 Nov 2026

Choose charts after exploring the data and establishing Business Questions. Apply the semantic-layer and chart capability checklist for every build. For each view, state what readers should learn or do, then choose the encoding. A chart’s fields must preserve the question’s grain, units, filters and calculations.

  1. Name the task. Compare, rank, follow change, inspect a distribution, trace a flow or understand a relationship. Distinguish exploring an unknown pattern from explaining a finding.
  2. Check the data shape. Identify categorical, numerical and temporal fields, the number of categories, missing values and aggregation grain. A chart cannot supply a relationship that the data does not contain.
  3. Consider the audience. Decide whether readers need precise values, an overview or a pattern. Allow room for labels and explanation, especially for an unfamiliar form.
  4. Check available space. Estimate space per mark and value label from the container size and category count at each target viewport. If required labels cannot fit, change the form or layout, or use an explicitly stated narrower range that preserves the requested analysis. Do not rely on the chart to silently omit them.

This approach follows the Royal Statistical Society’s chart-selection guidance. From Data to Viz offers a complementary decision tree by input data shape and a catalog of chart-specific caveats.

These are candidates, not automatic selections. Astrato type names below link to their published references. Check the definition requirements against your actual fields and installed package before implementation; a catalog entry alone does not verify your configuration or result.

What readers need to understand Candidate forms Check before choosing
A headline and its context Number, compact comparison Unit, period and comparison meaning
Category differences or rank Bar, dot Meaningful order, readable labels and room for close values
Change over time Line, bar, combo Ordered dates, gaps and comparable periods; distinguish units on mixed measures
Spread, skew or outliers Histogram Observations and binning must match the intended population
Association between measures Scatter A consistent observation grain; association does not establish causation
Patterns across two categories Heat map Meaningful row/column order and a labelled colour scale
Parts within a whole or hierarchy Treemap, tree, pie, stacked bar A real hierarchy or meaningful whole; area is less suitable for fine comparisons
Movement between stages or groups Sankey Actual source/destination relationships and flow quantities
Contributions to a change Waterfall Contributions must reconcile with the start/end values
Profiles across several attributes Radar Comparable scales and a stable axis order; avoid dense overlapping profiles
Precise records for action Table Useful columns, ordering and access to the underlying detail

The Financial Times Visual Vocabulary groups chart choices by the relationship they communicate and explains their tradeoffs. The Astrato type catalog owns current availability. General chart galleries also contain forms that Astrato may not support.

Check a presentation requirement before declaring it unsupported

Section titled “Check a presentation requirement before declaring it unsupported”

Read the selected type’s complete definition reference and operation reference for the installed package. Look for the required behavior in the descriptions rather than relying on a guessed operation name. Consider another supported type that preserves the data shape and analytical meaning. Verify the candidate with representative data and check operation results before promising it. If the requirement remains unsupported, identify the unmet part and follow the chart rendering policy before considering custom rendering. An unsupported requirement alone does not authorize a fallback.

During design, consider at least one suitable candidate beyond KPIs, bars, lines and tables. Include it when it exposes a useful pattern or supports the app’s story. There is no quota: do not force an unusual chart into data that cannot support it.

For example, an order dashboard might show a delivery-time histogram instead of another average; a revenue page might use a waterfall to explain margin; a journey view might use a Sankey to show movement. A heat map can reveal repeated busy periods, while a treemap can show concentration in a hierarchy. Each adds a different analytical view rather than repeating the headline in another shape.

For a less familiar chart, give readers a short reading cue: what a mark represents, what size or colour means, and what finding to inspect. Pair it with exact values or detail on demand where needed. Test whether a reader can answer the intended question without guessing the encoding. This is a design recommendation: visual interest should preserve interpretability and accuracy.

  • When the choice is unclear, compare two plausible forms with representative data at the intended viewport. Check long labels, dense categories, small values and missing data.
  • Keep a bar chart to about 12 categories and show a Top N beyond that; keep a line chart to about 5 series and highlight or split the rest; offer a pie only for at most 5 parts of one whole. Show measures with different units in separate charts rather than on a dual axis.
  • Title a panel with what it measures and how it is split, such as “Net revenue by Region”, and give the unit, period and active filters in the subtitle: “USD · Last 12 months · EMEA”. Do not write a finding into a static title; it stops being true when the data or filters change.
  • Start magnitude bars at zero; expose units and denominators. Distinguish a ranked subset from the full population and explain excluded categories.
  • Stack only a measure that adds up across the stacked groups, such as a count or a total. Averages, rates, percentages and ratios do not add: two groups’ averages stacked draw a length that no group has. Compare such groups side by side, with grouped bars or a dot chart, and show each group’s count and the overall figure they are compared with. A bar with more than one dimension or measure can stack when no layout is set, so always set its layout with setBarChartLayout: groups for a side-by-side comparison, stacked only for parts that add up to a whole.
  • Preserve category colours across related views and add labels so colour is not the only signal.
  • Check supported filters, selections and operations for the chosen type. Do not silently discard query semantics or bypass a missing capability to obtain a particular appearance.
  • Use components for explanation and navigation, and consult an expert guide when its approach suits the audience. Finish with app verification.