Fifty-four ways to draw your numbers, and what each one needs

Start at zero when length carries the comparison; use a horizontal orientation for long names.

Takes: a two-column table, one category column and one number column, with up to a dozen rows. Name one row in highlight and it takes the accent while the rest recede.

Keep units and group order consistent; many groups are easier to read in separate charts.

Takes: a table with a category column, a group column and a value column. That means the same categories measured under two or three conditions, such as regions across years.

Only the first component has a common baseline, so use grouped bars when precise middle-component comparisons matter.

Takes: a table with a category column, a part column and a value column, where the parts of each category add up to a meaningful whole, such as cost by team and category or headcount by office and function.

Order the rows intentionally; a decorative stem is not a confidence interval.

Takes: the same two-column table as a bar chart, but with many rows or long labels. The thin stem keeps a ranked list of twenty items legible.

Show the measurement basis; a score without its rubric is not a recommendation.

Takes: a ranked table of names and one number, when you want the numbers read as a list as well as compared. That fits a leaderboard, a vendor shortlist or a benchmark.

Check whether raw counts or within-cohort percentages answer the question; unequal cohort sizes can dominate the picture.

Takes: a table with an age band or tier column, a two-value side column and a count. That is a population pyramid, or any two cohorts mirrored around a centre.

Keep rows in the same unit on a shared axis; put dollars, percentages and days in separate exhibits.

Takes: a table of metrics, each with an actual value and a target. That is the quarterly scorecard, where every row is a measure against its goal.

A card needs its period and denominator nearby; it should not replace the evidence behind the number.

Takes: a single line or a one-row table naming a metric, its current value and its target. That is the one number the page is about.

A line joins the supplied points; sparse observations do not establish what happened between them.

Takes: a table with a date column and one or more numeric series columns, or a long table of date, series, value, such as weekly actives, monthly revenue or daily latency.

Keep a meaningful zero; a cash balance alone cannot establish runway without a spending basis.

Takes: a date column and one cumulative or volume measure, such as total storage, cumulative signups or cash balance, where the filled area reads as the amount.

The moving baseline helps show the mix but makes exact cross-period values harder to compare; use lines when precision is the priority.

Takes: a long table of date, category and value with several categories per date, such as share of attention, traffic by channel or tickets by product, when the story is how the mix shifts.

Say whether it is a forecast interval, observed spread or scenario range; Flow does not infer its statistical meaning.

Takes: a date column with a low and a high column, and optionally a central value, such as a forecast with its confidence band, a temperature range or a p10/p90 spread.

Keep the unit, period and scale context in the title or nearby text because the display is deliberately small.

Takes: a short date-and-value table meant to sit beside a sentence, such as a week of latency or a month of signups, shown without axes as a glance.

The gap and direction matter; it cannot show the path or volatility between endpoints.

Takes: a table with exactly two time points per item, such as before and after or this year and last, where the steepness of each line is the finding.

Define the ranking method and ties; moving from second to first says nothing about the size of the underlying gap.

Takes: a table of period, competitor and rank. That is the league table at each point in time, when the story is who passed whom.

Preserve chronological order and both units; the connecting path is a trajectory, not a regression fit.

Takes: a table of period, x-measure and y-measure for one entity, such as price against volume by year or spend against growth by quarter, where the path shows the trajectory.

Check the time zone, sampling window and units; it is not an investment recommendation.

Takes: a table of date, open, high, low and close. That means market prices, but also any daily range with a start and an end, such as queue depth or token spend.

Missing days need explicit treatment; a quiet day is not necessarily a zero or a day when a system was available.

Takes: a long table of date and count, such as commits, dictation minutes or support tickets per day, over months, when the weekly rhythm matters as much as the totals.

Check the arithmetic and distinguish totals from changes; a missing movement cannot be repaired by the chart.

Takes: a table of named steps and signed amounts, from an opening figure through additions and subtractions to a closing one, such as a revenue bridge or a headcount reconciliation.

State the denominator; use bars for close values, many categories or overlapping groups.

Takes: a short table of parts and their share. That means five or fewer slices that add to a whole, such as revenue by segment or time by activity.

Angles are harder to compare than lengths; keep exact amounts available in a table or paired bar chart.

Takes: the same parts-and-share table as a pie, when a headline number belongs in the centre or the chart sits inline beside text.

Explain the period and magnitude; radius and area can give different visual impressions, so keep the underlying values available.

Takes: a table of cyclical categories and a magnitude, such as hours of the day, months or compass directions, where a polar layout shows the cycle.

Define each score and direction, use comparable scales and inspect the table; polygon area is not a defensible overall score.

Takes: a table of criteria, option and score, such as a vendor evaluation or a skills matrix, with two or three options scored on five to eight axes.

Bars represent the entered schedule; they do not prove work started or that a dependency is satisfied.

Takes: a table of tasks with a start date, an end date and an owner or phase, such as a project plan or release schedule written as rows.

Label both units and investigate outliers; association does not establish cause.

Takes: a table with two numeric columns per row, and optionally a category and a size, such as accounts by seats and spend or models by latency and quality.

Keep the points visible and avoid causal language or predictions beyond the observed range.

Takes: the same two numeric columns as a scatter, when you want the fitted trend drawn through them, such as ad spend against signups or effort against score.

Bin choices change the visible shape; state the sample size and unit and do not treat an empty bin as missing data.

Takes: a single numeric column with many rows, such as response times, deal sizes or document lengths, which the chart bins for you.

Smoothing and small samples can create or hide peaks; check individual observations before naming distinct populations.

Takes: one numeric column, optionally with a group column. It is the same data as a histogram, smoothed, when two groups need overlaying.

State whether equality counts, name the sample size and remember that this is a sample proportion.

Takes: one numeric column, optionally grouped. Use it when the question is “what share finished within N seconds”, read straight off the curve.

The box hides the individual pattern; a strip plot can be better for a handful of observations.

Takes: a category column and a numeric column with several rows per category, such as deal size by segment or score by cohort, summarised as median, quartiles and outliers.

Check sample size and smoothing; a suggestive shape is not evidence for a user persona.

Takes: the same category-and-value table as a boxplot, when the shape of each distribution, such as bimodal or skewed, is the point.

Repeated values may overlap; check the count and use the source table when exact individual values matter.

Takes: a category column and a numeric column with a modest number of rows per category, when every individual point should stay visible.

Name both endpoints; this before/after layout does not establish what caused a change.

Takes: a table with a category, a condition and a numeric value, with two rows per category. The before and after values appear as two dots joined by a line.

Use one explained colour scale, distinguish missing from zero and keep the scale comparable across panels.

Takes: a table with two category columns and a value, such as hour by weekday, feature by segment or team by month, where colour carries the number.

Treat arrows as an authored process; they do not execute an approval or send a message.

Takes: a numbered list of steps with decisions written as questions, such as a process, an approval path or a troubleshooting guide.

Name the boundary and failure path; the diagram is a scenario, not a trace captured from a live system.

Takes: prose or a list describing who sends what to whom, in order, such as an integration, a support escalation or an approval exchange between people or systems.

Keep state names distinct from actions and account for endings or reversals.

Takes: a list of states and the events that move between them, such as a document lifecycle, an order status or a subscription.

Multiplicity and ownership should have a defined meaning; this is an illustrative model, not Flow source code.

Takes: a description of the nouns in a system and how they relate, such as the data model behind a product, with fields and one-to-many relationships.

Confirm cardinality with the data owner; a diagram is not a database migration.

Takes: a list of tables with their keys and how rows reference one another, such as a database schema or a CRM’s objects.

This example is separate from the chart Gantt; neither proves a planned task completed.

Takes: a list of tasks with durations and dependencies, in sections. That fits a project plan written as prose, when you want milestones and “after X” dependencies rather than fixed dates.

Say whose experience the ratings describe; this sample is not a user-research result.

Takes: a walkthrough of what a person does, step by step, with how each step felt, such as research synthesis, a support transcript or an onboarding review.

It is authored data; the chart-fence pie is the choice here when values must bind to a local source.

Takes: a short list of labels and amounts. It is the same material as a chart pie, when you want it inside a diagram-only document or rendered on GitHub.

The placement is a judgment to review; a quadrant label is not a prioritization algorithm.

Takes: a list of items each rated on two axes, such as effort and impact, risk and reward or urgency and importance, the prioritisation matrix.

Distinguish planned dates from observed events and do not treat this fictional history as a Flow release record.

Takes: a list of dated events, such as a company history, a release log or an incident’s sequence.

Branches are authored associations, not an automatically maintained knowledge graph.

Takes: an outline, a nested bulleted list of topics and subtopics, such as meeting notes, a brainstorm, or a document’s structure.

The commits below are fictional labels; the diagram does not inspect or operate a repository.

Takes: a description of branches, merges and releases, such as a release process or how a feature landed.

Check units and flow conservation; these numbers are embedded in the diagram and do not update from a source table.

Takes: a table of source, target and amount. It shows where traffic, money or people flow from one stage to the next, such as a funnel or an energy balance.

Keep units compatible and identify each series in the surrounding prose.

Takes: a date-and-value table when the document must render on GitHub as well as in Flow. It draws a bar-plus-line over months without the chart fence. Bars show signups; the line shows activated accounts. Both use account counts, not percentages.

Keep arrows labelled or obvious and avoid implying that visual proximity is a connection.

Takes: a description of components and how they sit beside and connect to each other, such as an architecture sketch or a deployment layout.

A satisfies arrow records an assertion, not completed compliance or test evidence.

Takes: a list of requirements with identifiers, risk and verification method, and which components satisfy them. That fits a compliance or safety document. These are fictional requirements and components, not verified Flow guarantees.

Keep the level of detail consistent and state the system boundary before drilling into components.

Takes: a paragraph naming the system, the people who use it, and the external systems it talks to. That is the top of an architecture document.

Moving a card in text changes this document; it does not update an external project-management system.

Takes: a task list grouped by status. That is the sprint board as columns of cards with owners.

The picture records an intended arrangement; it neither provisions infrastructure nor proves a privacy boundary.

Takes: a list of services, the stores they use and the edges between them, grouped by where they run. That is a deployment diagram.

State field widths and total size; do not use this sample as an actual Flow file-format specification.

Takes: a field-by-field layout of a binary record or header, with bit offsets, such as a protocol note or a file-format spec.