Flow Charts

Flow and composition charts

Two questions that ordinary bar charts answer badly: where did the money move and how does the mix break down across two dimensions at once.

Sankey — movement between states

Bands whose width encodes magnitude, flowing left to right between nodes.

The two that earn their place in finance

Cash flow. Sources on the left, uses on the right.

Collections ─────┐
                 ├──► Cash ──┬──► Payroll
Financing ───────┘           ├──► Vendors
                             ├──► Capex
                             └──► Ending balance

Instantly answers "where did the money go" in a way a table of the same numbers does not.

Customer movement between periods. The single best chart for retention dynamics:

Start-of-period ──┬──► Retained (same tier)
                  ├──► Upgraded
                  ├──► Downgraded
                  └──► Churned
New              ─────► End-of-period

Shows all four ARR-bridge components and their relative magnitudes and their destinations at once. Where the bridge shows net movement, the Sankey shows the flows behind it.

Rules

• Widths must be exactly proportional and must conserve. Inflow to a node equals outflow. If they do not, the diagram is wrong — the same footing discipline as bridge-charts.
• Cap at ~15 nodes. Beyond that it becomes a hairball. Group small flows into "Other" — and per the usual rule, "Other" must be smaller than the smallest named flow.
• Order nodes to minimize crossings. A Sankey with many crossing bands is unreadable regardless of correctness.
• Label bands with values, not just names. Width comparison is approximate; the reader needs the number.
• Colour by source or by category, consistently — never by band, or the eye tries to find meaning in it.
• Do not use a Sankey for a simple two-level split. That is a bar chart.

There is no Sankey primitive in chartkit. Compute node positions and band paths yourself: node height is proportional to throughput, and bands are cubic Béziers between the two node edges.

Marimekko — two dimensions at once

Column width encodes one measure (segment size), column height splits by another (mix within segment). Area therefore encodes the product.

        │ Enterprise │ Mid-mkt │SMB│
        ├────────────┼─────────┼───┤
Platform│            │         │   │
        ├────────────┼─────────┤   │
Services│            │         ├───┤
        ├────────────┴─────────┴───┤

Excellent for "which segment is big, and what do they buy". A grouped bar chart cannot show both.

Rules:

• Label both dimensions clearly. A marimekko is unreadable without knowing what width means, and readers do not assume it means anything.
• Show the width values along the top — segment totals.
• Limit to about 5 columns and 5 rows. It degrades fast.
• Only for parts of a whole. If the columns are not a complete partition, the widths lie.
• Accept that precise comparison of non-adjacent cells is impossible; this chart is for the pattern.

Stacked bars and areas — and their real limitation

The limitation people forget:

Only the bottom band sits on a common baseline. Every band above it is measured from a moving start, so middle bands cannot be compared reliably across categories.

Consequences:

• Put the series you most want compared at the bottom. That is a design decision, not a default.
• Two or three bands is where stacking works well. Beyond about five, switch to small multiples or a line per series.
• Consistent order across every bar, always. Reordering by size per bar destroys comparability.
• Never use stacked bars to compare a middle series across categories. That is what small multiples are for.

Stacked vs 100% stacked

100% stacked hides the total entirely. A segment can be growing in absolute terms while its share falls; on a 100% chart it looks like decline. If the total matters at all, show it — a total line above the chart, or a companion chart.

Treemap

Nested rectangles, area encoding value. Good for hierarchical composition at one point in time — spend by department then category, revenue by region then product.

• Never for change over time. Treemaps show a snapshot; a reader cannot compare two treemaps reliably.
• Area is judged poorly — people underestimate large areas. Precise comparison is not available; label values.
• Two levels maximum. Deeper nesting is unreadable at any realistic size.
• A ranked bar chart beats a treemap for a flat list. Use a treemap only when the hierarchy itself is the point.

Pie — the narrow legitimate case

Genuinely fine for two or three parts of a whole, where the split is roughly even and precision is not needed. "Recurring vs non-recurring revenue" as a two-slice pie is clear.

Beyond three slices, or with a dominant slice and a long tail, use sorted horizontal bars. Angle comparison is unreliable and ordering is invisible.

Never a donut with a number in the middle. The reader reads the number; the ring is decoration. Show the number.

Choosing among them

That last row matters: composition charts are frequently reached for when the real question is net change, which is a bridge.

Related skills

• bridge-charts — the net-change alternative, and the same conservation discipline
• cohort-charts — layer cake, the stacked-area cousin
• chart-selection — the wider decision
• svg-charting — building band paths
• ui-antipatterns — pies, treemaps and stacking failures