Charts and Graphs: How to Pick the Right One and Read It Correctly

A chart is a picture of numbers. The type you pick decides what the reader notices first, so the rule is simple: match the chart to the question, not to the data. If you are comparing amounts across categories, use a bar chart. If you are tracking a value over time, use a line chart. If you are looking for a relationship between two numbers, use a scatter plot. If you are showing how a total splits into parts, use a stacked bar (and only reach for a pie chart when there are two or three slices). If you are showing distribution, use a histogram or a box plot. Those six cover the large majority of real business and analysis work.

The words "chart" and "graph" are used interchangeably in everyday speech, and that is fine. Strictly, a graph is a chart that plots values on axes (line, bar, scatter), while "chart" is the broader family that also includes things without numeric axes, like org charts, flowcharts and Gantt charts. Nobody will correct you either way. What matters far more is whether the chart you chose lets a reader answer the question in about three seconds without reading the axis labels twice.

The quick selection table

Why bars beat pies almost every time

Human perception ranks visual encodings by accuracy. People judge position along a common scale best, then length, then angle, then area, then colour intensity. A bar chart uses position and length. A pie chart uses angle and area. That is why a pie with seven slices of 11 to 16 percent is unreadable: nobody can tell 14 from 16 by eye, so readers fall back on the data labels, and at that point you have made a table with decoration around it.

Pies survive in one honest case: two or three parts where the split is dramatic and the point is "roughly this share of the whole". Sixty-eight percent versus thirty-two percent works. Anything past three slices, switch to a horizontal bar chart sorted descending, and your reader gets the ranking for free.

The axis rules that decide whether a chart is honest

Bar charts must start at zero. The whole meaning of a bar is that its length is proportional to its value, so truncating the axis at 90 breaks the encoding and inflates a 4 percent difference into a visual doubling.

Line charts do not have to start at zero. Lines encode change through slope, not length, and forcing a zero baseline on a stock price or a satisfaction score compresses every real movement into a flat wiggle at the top of the frame. The obligation with line charts is different: choose a range that shows real variation without exaggerating noise, and label the axis clearly enough that a reader knows they are looking at 4.1 to 4.4, not 0 to 5.

Two more that get broken constantly. Dual axes invite false correlation, because you can slide either scale until two unrelated series appear to move together. If you need two units on one chart, prefer indexing both to 100 at a common start date, or use two stacked charts sharing an x-axis. And never use a 3D chart. The perspective makes back bars look smaller than front bars of the same value, which is a distortion with no compensating benefit.

Worked example: the same data, three ways

Say a support team logged these ticket volumes by channel last quarter: email 4,120, chat 3,880, phone 1,240, in-app 890.

Plot it as a pie, and email and chat look like near-identical halves of a big blob. The reader learns "email and chat dominate" and nothing more precise.

Plot it as a horizontal bar sorted descending, and three facts land at once: email leads slightly, chat is effectively tied with it, and phone plus in-app together are less than either of the top two. That third fact is the one that changes staffing decisions, and only the bar chart surfaces it, because equal baselines let you mentally add lengths.

Now add time. If the actual question is "is chat overtaking email?", the bar chart is the wrong tool entirely, because it shows one frozen moment. A line chart with weekly volumes for both channels answers it: two lines converging over thirteen weeks, and you can see the week the lines cross. Same numbers, different question, different chart.

Where the simple answer breaks

Too many categories. Fifteen bars is fine if sorted. Fifty is not. Either group the tail into "other" with a note on how many items it contains, or switch to a chart designed for many small values, like a lollipop chart or a small-multiple grid.

Time series with gaps. A line implies that values existed between the plotted points. If your data is monthly snapshots of something that jumps discontinuously, or if a month is missing entirely, use bars or explicitly break the line. A smooth interpolation across a data gap is a claim you did not verify.

Parts of a whole that change over time. A stacked area chart looks elegant and is genuinely hard to read, because only the bottom band sits on a flat baseline. Every band above it is measured off a wobbly floor, so readers cannot judge whether the third band is growing or just being pushed around. If the shares matter more than the total, use a 100 percent stacked chart. If individual trends matter, use small multiples: one small line chart per category, same axes, arranged in a grid.

Averages hiding the distribution. "Average response time is 4 hours" can mean everyone waits four hours, or that most people wait twenty minutes and a handful wait three days. A histogram tells you which. For operational metrics, plotting the median with the 90th percentile alongside is usually more informative than any single average.

Small samples dressed as trends. A line chart of a conversion rate calculated from eleven visitors a day will swing violently for reasons that are pure chance. If the underlying counts are small, either widen the time buckets or plot the raw counts as bars beneath the rate line so the reader can see how thin the evidence is.

Colour doing work it cannot do. Colour is excellent for categorical distinction up to about seven values, and poor for encoding quantity precisely. If a reader has to compare two shades of blue to answer the question, move that variable to position or length. Also check the chart in greyscale: if it stops working, colourblind readers are already struggling.

Labelling, in order of importance

1. The title states the finding, not the topic. "Chat volume overtook email in week 9" beats "Ticket volume by channel". If the title cannot state a finding, ask whether the chart is worth showing.
2. Units on the axis, always. Dollars, thousands, percent, per user. Ambiguity here invalidates everything below it.
3. Sort deliberately. Descending by value for rankings, chronological for time, and keep the same order across charts on the same page so readers can move between them.
4. Direct labels beat legends. Putting "Email" at the end of the email line removes an eye movement per lookup.
5. Say what the data excludes. "Excludes internal test accounts" in small text under the chart prevents an entire class of argument.

When the numbers live in different systems

Most charting advice assumes the data is already in one clean table. In practice the number you want to plot is spread across a CRM, a billing system, a support desk and a production database, and the slow part is not drawing the chart but assembling the row.

Skopx connects to nearly 1,000 SaaS tools plus direct databases, so you can ask a question in chat and get an answer with citations back to the source records, and a chart drawn from the joined result rather than from a spreadsheet somebody exported last Tuesday. If the same view is one people need repeatedly, its Internal Apps feature turns a sentence into a small internal console that reads live from those systems, with any action gated behind a button someone clicks and confirms. One caveat worth keeping in view: business intelligence tools connect to databases and modelled sources, so evidence that lives as a sentence in a Slack thread or an email is outside what they can see, and that context often explains the shape of the chart better than the chart does.