Telling a story with city data means taking what a city already collects — 311 service requests, permits, budgets, crash records, tree inventories — and turning it into a narrative with a point, a visual, and a reason for someone to care. Most city data fails at the last two. It arrives as a dashboard nobody opens, a CSV with forty undocumented columns, a map that technically works and says nothing.
The workflow below is the one I keep coming back to. Start with a question a resident would actually ask, find the data that answers it, aggregate to the geography where the pattern actually lives, and then build the smallest possible visual with enough context to change someone’s mind. It takes an afternoon for a first pass and it scales up to a full briefing.
I’ll walk through what to gather, the seven steps, and the mistakes that quietly wreck an otherwise good analysis. Updated for 2026.
Table of Contents
- What You Need
- How to tell a story with city data step by step
- 1. Start with a human question
- 2. Find the insight before you open the chart
- 3. Check the limits of the data
- 4. Build a simple narrative arc
- 5. Match the visual to the claim
- 6. Add context that gives the numbers meaning
- 7. Present the takeaway and the next action
- Common Mistakes
- Frequently Asked Questions
- What is the best way to tell a story with city data?
- Which city-data visualization should I choose for my story?
- How do I explain missing or incomplete city data without misleading readers?
- Can a city-data story prove that one policy caused a change?
- How should I compare neighborhoods or districts fairly?
- What sources should I include with a public-data visualization?
What You Need
Before you open a single portal, gather four things. Missing any one of them is why most city data stories stall halfway.
A question with a person in it. “Where are tree pits missing?” is a question about a place. “Show me tree canopy data” is a request for a file. The first one can become a story; the second can only become a chart.
The data, plus its paperwork. Pull the dataset and then hunt down the data dictionary or metadata page: field definitions, collection method, date range, update frequency, and whether anything was estimated rather than measured. City data is unusually badly documented, and the definition of a single field can reverse your conclusion. A “closed” 311 case in one city may mean the work got done, while in another it means the request was cancelled.
Context layers. What happened around the numbers? A policy change, a budget cycle, a re-zoning, a new facility opening. Practitioners report consistently that context layers — what happened, why, what changed — are what turn a dashboard into something people remember.
An audience and a channel. A council briefing, a neighborhood meeting, a blog post, a grant application, and a scrollytelling page are four different products built from the same analysis. Decide which one before you start, because it decides the length, the vocabulary, and how much you can assume.
A simple planning template keeps you honest. I use five lines in a plain text file: the question, the geography, the source dataset and date range, the one comparison the story rests on, and the decision or conversation the story should start. If you cannot fill in the last line, you are making a dashboard, not telling a story.
On tools, you need less than you think. A spreadsheet handles small extracts, an open data portal and a mapping tool handle the rest, and anything with an embed option covers the publishing side.
How to tell a story with city data step by step
1. Start with a human question
Narrow a broad dataset by place, population, time period, and lived experience until you reach something specific. A question about bus reliability becomes more pointed when you attach a consequence: are late buses behind people missing medical appointments in a specific part of the city?
That version works because it names who is affected and why the timing matters. “How reliable are our buses” would have produced the same dataset and no story at all.
Success check: you can say your question out loud in one sentence, and a resident could tell whether the answer changed anything for them.
2. Find the insight before you open the chart
Most people open the charting tool first, then hunt for something interesting. Reverse that. Read the data as text first: sort it by time, by geography, by category, and look for patterns, outliers, gaps, and step changes.
The key move is to ask what the pattern means before asking how it looks. If pothole repairs cluster in two districts after a budget change, the story is about allocation, not about potholes. That framing decides which visual you need and what the headline says.
Success check: you can state the insight in one sentence that contains a number, a place, and a time period.
3. Check the limits of the data
Every city dataset has edges. Read the metadata for definitions, collection method, time coverage, and missing values, then look hard at geographic boundaries and sampling.
Watch for the classic artifacts: records geocoded to a city hall address instead of a home, categories that were renamed mid-series so the trend line breaks, duplicated reports from one household, and small samples dressed up as neighborhood percentages. A census tract with very few residents can produce a 100 percent change on the basis of two people.
Success check: you can name two things this dataset cannot tell you. If you cannot, you have not read the metadata.
4. Build a simple narrative arc
Every city data story runs on four beats: what we expected, what the data shows, who is affected, and what could change. That is a narrative arc whether you write it as prose or as scrollytelling steps.
A three-paragraph outline is usually enough. Paragraph one sets the expectation, with a baseline or a prior commitment. Paragraph two delivers the finding, plainly and with the comparison that makes it matter. Paragraph three connects it to people and names the decision that follows.
Success check: each paragraph has one job, and a reader who only reads paragraph two still gets the point.
5. Match the visual to the claim
Use a map when location is the argument. Use a line chart when time is. Use a bar chart when the comparison between named categories is. Use small multiples when you want readers to see the same pattern across many places at once.
One visual should make the central comparison obvious. That is the whole test. If the reader has to study the chart, hunt the legend, or wonder what they are supposed to notice, the visual is doing too much.
Success check: the chart title states the takeaway rather than naming the metric — “Pothole repairs concentrated in two districts over the past three years” beats “Pothole repairs by district.”
6. Add context that gives the numbers meaning
A bare number is unreadable. Add population totals so readers can judge scale, percentages alongside counts so a small place is not confused with a big one, dates so a reader knows how current it is, and a baseline such as a prior average or a council target.
Take tree canopy as a worked example. “18 percent canopy” means nothing on its own. “18 percent canopy in the north side, against 41 percent citywide, in tracts with the fewest owner-occupied homes” tells the reader this is a gap between neighborhoods and hints at who it affects. Now the same number carries an argument.
Success check: every figure has a comparison within two inches of it on the page or in the caption.
7. Present the takeaway and the next action
Close with a plain-language sentence stating what the data shows, bounded tightly enough that nobody can accuse you of overclaiming. Follow it with the specific decision, intervention, or conversation the story should start — reallocate repairs, move a capital project, change an inspection schedule.
Then write the three pieces of text that carry the story: a headline with the takeaway, a subhead that adds the place and time period, and a caption that names the source dataset, the agency, and the date range. Add the limitations line while you are at it. Practitioners on r/dataisbeautiful and similar communities reward honest caveats and punish unsourced claims every time.
Success check: someone who reads only your headline and your source note gets an accurate picture of the finding.
Common Mistakes
The decorative map. A shaded map of every variable in the dataset tells the reader nothing. Fix it by picking one comparison and colouring only that measure.
Correlation written as causation. Two lines rising together is not proof one caused the other, especially in city data where investment, policy, and demographics all move together. Fix it by writing “coincides with” or “follows” and naming what else changed at the same time.
The misleading scale. A y-axis starting at 95 turns a one-point difference into a cliff. If you need a truncated axis, label it loudly; more often, plot the change instead of the level.
Comparing unequal geographies. A ward with 12,000 residents next to one with 90,000 produces a chart about population size. Fix it by normalising to rates per 1,000 residents, and say that you did.
Missing context. A chart with no source, no date range, and no definition is the fastest way to lose a skeptical reader.
Ignoring whose voices are missing. Resident-generated data under-represents the people least willing to engage with institutions. Harvard Data-Smart’s write-up of San Diego makes the point plainly: an absence of 311 reports does not mean an absence of conditions. Fix it by saying who is likely underrepresented, or by triangulating with a source that captures them, such as a health indicator or a survey.
A story with no decision attached. If nothing changes after the analysis, it was reporting. Say what the data should change and who has the authority to change it.
Publishing once and forgetting it. A city data story dated 2026 with a data range from two years ago reads as abandoned. Note the update cadence on the story itself, and refresh it when the source refreshes.
Two editing habits do most of the work. Read the headline alone on its own — if it overstates, rewrite it until it does not. And give every chart to someone outside the project for thirty seconds with no explanation; whatever they say first is what your visual actually communicates.
Frequently Asked Questions
What is the best way to tell a story with city data?
Start with a question a resident would ask, not with a dataset. Then narrow to a place, a population, and a time period, find the one dataset that answers it, and aggregate to the geographic unit where the pattern lives. Pick a single visual that makes the central comparison obvious, write context around it, and close with the specific decision the story should start.
Which city-data visualization should I choose for my story?
Use a map when location carries the argument, a line chart when change over time does, a bar chart when comparing named categories, and small multiples when you want the same pattern visible across many places. Avoid dual axes and 3D effects. The test is simple: a reader should grasp the central comparison without reading the legend.
How do I explain missing or incomplete city data without misleading readers?
State what is missing and who it likely excludes, in plain language, next to the chart rather than buried in a footnote. Resident-reported data such as 311 requests under-represents people who do not trust or engage with institutions, so a quiet map can mean disengagement rather than absence. Name the gap, say how you handled it, and avoid extrapolating beyond the coverage.
Can a city-data story prove that one policy caused a change?
Rarely, on its own. City datasets are observational, and investment, demographics, and policy often shift at the same time. You can show that a change follows a policy date and looks different from previous years, which is useful and honest. To say a policy caused it, you need a comparison group or a stronger design, and you should describe your method.
How should I compare neighborhoods or districts fairly?
Normalise before you compare, using rates per 1,000 residents or percentages rather than raw counts, so a large district does not outrank a small one purely on size. Use one geographic unit consistently across every district, and note where boundaries change between datasets. Where a sample is thin, say so on the chart instead of publishing a percentage built on a handful of records.
What sources should I include with a public-data visualization?
Name the dataset, the publishing agency, and the date range on the chart or directly beneath it, and link to the original portal record rather than a screenshot. Add the definition of any field whose meaning is not obvious, such as what a closed case means in that agency. A link to the underlying data or the code lets someone reproduce your result.
If you do one thing this week, take the question you keep being asked at meetings and try to answer it with a single dataset, one map, and one sentence about what should happen next. The question is the hard part, and it is also the part that makes the rest worth doing. Check the source note, keep the caveats visible, and let the reader see the same thing you saw.
