A methodology box for a data story is a short boxed note that tells readers where the numbers came from, what period and population they cover, how you analysed them, what you left out, and where the data falls short. Writing one well takes about 30 minutes once the reporting is done, and it is the single cheapest way to earn trust with a sceptical audience.
The odd part is how few people treat it as a real piece of reporting. Most method notes get bolted on at the end, written in the same jargon the analysis used, and buried under a graphic where nobody on a phone will ever find it. A good box is drafted early, written in plain sentences, and placed where the reader meets the chart.
Below is the process I use: gather the audit trail first, draft around the reporting question, strip out anything that needs a statistics degree, then test it with someone who did not work on the story.
What You Need
You cannot write an honest methods note from memory three days after publication. Everything below has to be in front of you before you start, because the box is a summary of decisions you already made, not a place to make new ones.
The reporting question, in one sentence. What question does this story answer? If you cannot write that down, the box has nothing to anchor to.
The scope details. Population covered, geography, date range, reporting period, and the unit of analysis. A count of incidents is not the same as a rate per 100,000 people, and readers need to know which one they are looking at.
The source list. Every dataset, official release, internal record, interview and observation used, plus where each one came from and when it was accessed. If a number came from someone who asked not to be named, say that explicitly rather than leaving a vague “sources” line.
The cleaning log. Every duplicate you removed, every inconsistent date you dropped, every unit conversion, every record you excluded and why. This log is usually a spreadsheet you already built. It becomes the exclusions paragraph almost verbatim.
The definitions you used. What counted as a “confirmed case”, a “closure”, a “resident”, a “complaint”? These terms carry the whole argument, and readers deserve them spelled out.
The uncertainty picture. Sample sizes, margins of error, confidence intervals, seasonal adjustments, revisions pending, and any modelling step you ran. If the data is provisional, say so here rather than in the body copy where it gets lost.
A named contact or corrections route. Somewhere for a reader to send a challenge: an email address, a corrections policy link, or a form.
Step-by-Step: How to Write a Methodology Box for a Data Story
Start with the reporting question and scope
Open with the question the story answers, in the words a reader would use. Not “this analysis examines the relationship between X and Y” but “how many serious crashes happened on the same roads, and where”.
Then bound it. State the population, the place, the date range and the unit. Four sentences is plenty: what we looked at, who or what it covers, when, and what counts as one occurrence.
If the story uses a subset of a larger dataset, say so here. “Figures cover the 14 metropolitan authorities with a combined population above 250,000; the remaining authorities are excluded because their reporting systems changed in 2024” tells a reader more than a footnote buried at the end ever will.
Describe the data sources and selection process
Name each source specifically, with the publisher and the date you pulled it. “Public data from the national statistics agency” is not a source. A named release, a table number, or a linked file is.
Then explain how you chose between sources. If two agencies count the same phenomenon differently, say which one you used and why. If you supplemented an administrative dataset with interviews, say how many and why the records were not enough.
Describe cleaning in plain verbs: what you merged, what you deduplicated on which field, what you excluded. Do not describe your software at length. Readers care that you removed 214 duplicate entries keyed on a case reference number, not whether you used one spreadsheet package or another.
Explain the analytical method in reader-friendly terms
This is where method notes usually break. The goal is enough precision that another reporter could rebuild your figures, without reproducing every technical step.
Define every calculation that appears in the story. If you normalised for population, say so and give the divisor. If you compared year-on-year changes, state whether you adjusted for seasonality and how. If you coded open-text responses into categories, give the categories and note that one person coded them all, which is honest and useful to a reader weighing the result.
A useful test: could a colleague who was not on the story reproduce the headline number from what you wrote? If not, a step is missing.
Add definitions, exclusions and limitations
Gloss the terms the story leans on hardest. One line each, in the reader’s vocabulary rather than the dataset’s. “A closure is recorded when a case reaches a final outcome in the case management system, not when the outcome letter is sent.”
Then list exclusions and their reasons. Silent drops are the thing readers fear most, because they assume the worst. Naming them takes one sentence each.
Handle uncertainty directly. Where a figure is a survey estimate, give the margin of error and the confidence level in the same sentence as the number. Where a series is revised, note the revision history and that later figures may differ. Where you could not test an assumption, say that too.
Be specific about what the data does not measure. A dataset of reported incidents measures reports, not crimes. Seasonality, reporting behaviour and population changes can all move a trend without anything real changing on the ground, and saying that in advance costs you nothing.
Draft, test and publish: finishing a methodology box for a data story
Use this skeleton, which fits most stories in 100 to 200 words:
How we did this — We examined [population] in [geography] over [date range], using [named sources, publisher, accessed date]. We [cleaning steps]. We excluded [what and why]. Figures are [rates/ counts] per [unit]. [Uncertainty: margin of error, revisions, seasonality]. [What the data cannot show]. Data and code: [link]. Corrections: [contact].
A filled version, for a housing story:
How we did this — We analysed 1.2 million residential sale records for England and Wales from January 2019 to December 2025, published by the national statistics agency and downloaded on 14 September 2026, to test whether first-time buyers are being priced out of lower-priced postcodes. We excluded 8,400 records with missing or duplicated transaction dates and 1,100 records flagged as new builds, which are reported separately. Prices are transaction prices, not asking prices, and are not adjusted for inflation. Where the source publishes a standard error, we show it in the tooltip; the full uncertainty range is roughly plus or minus 1.4 percent on national figures. The data records completed sales only, so it cannot show sales that fell through or households that rented. Corrected figures are posted on this page with a dated note.
Now test it three ways. Read it aloud: if you stumble, a reader will too. Ask someone outside the reporting team what question they still have afterwards. Then check every number in the box against your published chart, because copy-paste errors in method notes are common and embarrassing.
On placement, use the box, not a footnote, when the story relies on more than a single data point. Keep it directly under or beside the graphic it explains, not at the foot of a long scroll. On mobile it must collapse cleanly and must never cover a chart axis, label or legend. Label it plainly — “How we did this”, “Methods” or “About this data” all work; an unlabelled grey box reads as legal fine print and gets ignored.
After publication, treat the box as a living document. Corrections to methods go in the same box with a dated entry, not as a silent edit. If the source revises its data, update the figures, note the revision, and date the box so readers can tell which version they read.
Common Mistakes
Writing it last. A box drafted the day of publication is a summary written from memory, and memory drops the exclusions that matter most. Draft it while the cleaning log is still open.
Hiding the caveats. Burying limitations in a linked methods page is not transparency. If a number could be over-read, the warning belongs beside the number.
Keeping the jargon. “Aggregated by ward-level boundary changes using ONS 2021 codes, normalised by mid-year population estimates” tells a reader nothing actionable. Write “we compared like-for-like areas after the 2021 boundary change and adjusted for population” and keep the technical version in your documentation.
Using vague sourcing. “Official statistics”, “public records” and “our analysis” are placeholders. Name the publisher, the release and the access date.
Overloading the box with process. Not every reader needs your toolchain. If a detail would not change how someone interprets the finding, leave it out.
Skipping the inconclusive result. When the analysis found nothing, or the data turned out to be too flawed to support the original hypothesis, say so plainly and explain what you can and cannot conclude. Publishing a null result with a clear method note is stronger journalism than quietly dropping it.
Failing to link the underlying data. If you can release the data, the code, or a notebook, link it from the box. Where licensing blocks you, say that instead of leaving readers guessing.
Frequently Asked Questions
How do I write a methodology?
Write it in five moves: state the reporting question and its scope, name every source with publisher and access date, describe the cleaning and calculation steps in plain verbs, list exclusions and uncertainty, then give readers a route to challenge or reproduce the work. Draft it while your cleaning log is still open, not the day you publish, and cut anything that would not change how a reader interprets the finding.
What is a methodology box in a narrative report?
It is a short boxed section attached to a story that tells readers how the reporting was done: which data and records were used, what period and population they cover, how they were analysed and cleaned, what was excluded, and where the limits are. Its job is to let readers judge the findings themselves, not to describe your software or prove how much work the story took.
What is an example of a methodology?
A plain example: we analysed residential sale records from January 2019 to December 2025, published by the national statistics agency and downloaded on 14 September 2026. We excluded 8,400 records with missing or duplicated transaction dates, compared prices per head of population, and note that the data captures completed sales only, so it cannot show failed or private rentals.
How to structure a methodology section?
Use a fixed order so readers always know where to look: question and scope first, then sources, then method, then exclusions and limitations, then uncertainty, then links and a corrections contact. Headings beat paragraphs, because a reader who wants only the caveats can find them without reading the rest. One hundred to two hundred words covers most stories; anything longer belongs in a linked methods page.
How long should a methodology box be?
Aim for 100 to 200 words for a standard chart or interactive, and stay under 400 words even for a complex investigation. The limit is a test of relevance: if a detail would not change how a reader interprets the finding, it belongs in your documentation or a linked methods page rather than in the box. Length matters less than placement, so keep it beside the graphic it explains.
How do I disclose data limitations without losing readers?
Put each limitation next to the specific finding it affects and phrase it as what the data cannot show, not as an apology. State uncertainty in the same sentence as the number, give the margin of error and confidence level for survey estimates, and flag provisional or revisable series with a date. Readers forgive a caveated finding far more readily than an unqualified one.
Conclusion
Start before you feel ready. Write the reporting question and the scope in two sentences, then open the cleaning log and list what you dropped and why. Everything after that is assembly work, and a reader who can follow those two steps will trust the rest of the numbers.
