Pie charts: when proportions help and when they mislead

The storm outage pie. Picture the morning after a big windstorm. The utility's operations dashboard has a pie chart of outage causes: trees on lines, broken poles, blown transformers, animal contact, and ten more. That's fourteen slices, several in similar shades of blue. The director walks in, glances at the big screen, and asks, "So what caused most of these outages?" Nobody in the room can answer from the chart without squinting and hovering over slices. The data was right. The chart choice was wrong. Pie charts are one of the most requested charts, and one of the most misused. In this lesson you'll learn exactly when a pie helps a busy reader and when it quietly hides the answer.

What you will learn. Here's the plan for the next few minutes. First, you'll learn what a pie chart actually communicates and the two conditions your data has to meet before a pie makes sense. Second, you'll walk through configuring a pie chart in ArcGIS Dashboards so it stays readable, including grouping small slices and labeling with percentages. Third, you'll learn the patterns that make pies mislead, such as too many slices, slices of nearly equal size, and values that don't add up to a whole, and which element to use instead. By the end you'll be able to defend your chart choice to a skeptical manager.

A pie shows part of a whole. A pie chart answers one question: what share of the whole does each category make up? A share, or proportion, is just the category's count divided by the total. Think of a pizza cut among friends: the slices only mean something because together they make one whole pizza. That gives us two conditions. First, the values must add up to a meaningful whole, with every record counted exactly once, like all water main breaks this year. Second, there must be only a few categories, roughly two to six. Human eyes are good at spotting "about half" or "about a quarter," but poor at comparing two thin wedges.

Building a pie in Dashboards. In ArcGIS Dashboards, you add a pie chart like any other element. Pick the data layer, say the water main breaks layer from your utility's hosted feature service. Choose how categories are made, usually grouped values of a field like pipe material. Choose the statistic: count of features, or a sum of a numeric field such as customers affected. Then look at two settings people skip. The grouping percentage folds any slice below a threshold into one slice labeled Other. And the label options let you show percentages instead of raw counts, so readers see shares directly. The official documentation shown here covers every option.

Worked example: main breaks. Let's see what the grouping percentage does with a hundred main breaks by pipe material. There are six materials: cast iron fifty eight, ductile iron twenty two, P V C twelve, asbestos cement five, steel two and copper one. We set the grouping percentage to five. Steel at two percent and copper at one percent fall below it, so they fold into one slice labeled Other, with three percent. Asbestos cement sits at exactly five percent, and five is not below five, so it keeps its own slice. The result is clean: five slices, one dominant. Anyone glancing at this pie sees immediately that more than half the breaks are on cast iron pipe, which is exactly the message the asset manager needs for next year's replacement budget.

When slices look alike. Now what happens when the categories are close in size? Here are last month's three one one service requests across seven request types, each between twelve and eighteen percent. As a pie, these become seven wedges that all look roughly the same, and the ranking vanishes. As a bar chart, sorted from largest to smallest, the order is obvious, and potholes clearly lead. Bars work because our eyes compare lengths along a shared baseline far more accurately than angles or areas. In Dashboards, the bar chart is called a serial chart, which is the Dashboards element for bar and line charts. So the rule of thumb is simple: if the point is ranking or small differences, use a bar chart, a serial chart in Dashboards, not a pie.

When there is no whole. The second way pies mislead is quieter: the numbers don't form a whole at all. Suppose someone builds a pie of average response time by district. Averages don't add up to anything, so the slice sizes are meaningless, even though they look like shares. The same happens when one traffic incident can carry several contributing factors, so it's counted twice and the "whole" is inflated. And a pie driven by a filtered view can show sixty percent of something without telling the reader what the sixty percent is of. Before building any pie, ask yourself: what exactly is the total, and is every record in it once?

Making pies honest. When a pie does fit, a few habits keep it honest. Keep it to six slices or fewer, using the grouping percentage for the long tail. Sort slices by size, largest first, so the reader's eye lands on the biggest one first. Give each category a distinct color, and use the same color everywhere on the dashboard, so storm damage is always orange in the pie, the list and the map. And always show the total, either in the chart title or in an indicator right beside it, like "412 outages since midnight." A share without its total leaves the reader guessing whether it's a big or small problem.

Common mistake: pies side by side. The most common mistake is putting two or three pies side by side to compare them, for example outage causes in the north district versus the south district. Now the reader has to compare angles across separate circles, which is even harder than comparing slices within one. Worse, if the north has three hundred outages and the south has sixty, a quarter of each looks identical but means very different counts. The fix is a grouped or stacked bar chart, built as a serial chart in Dashboards: set the district as the category, and use the split by field option on the cause field so each cause becomes its own series. One chart, a shared baseline, and honest comparison.

Recap. Let's recap. A pie chart shows each category's share of one real whole, so the values must add up to something meaningful with every record counted once. It works well with about two to six slices that differ clearly, especially when one category dominates, like cast iron pipe in the main break example. When slices are similar, when there are many categories, or when you need to compare groups, switch to a sorted or grouped bar chart, which Dashboards builds as a serial chart. With those three checks, you'll never leave a director squinting at fourteen blue slivers again.

Your exercise. Here's your task before the next lesson. Open a dashboard, or create a new one, using a layer with a category field, such as utility outages by cause, traffic incidents by type, or service requests by category. Build a pie chart and write down two things: how many slices it has, and what the total actually is. Then apply a grouping percentage, sort the slices, and switch the labels to percentages. Finally, build the same data as a sorted bar chart. Put them side by side, decide which one answers your manager's question faster, and write one sentence explaining your choice. That sentence is this whole lesson in practice: pick the chart that answers the question at a glance.