Tables and Graphs: Give Readers the Values and the Pattern

If you are publishing monthly service counts, readers may need two things: the exact count for a particular location and a quick view of how activity changed. Publish a table for the lookup task and a graph for the comparison—not two competing versions of the data.

Tables organize values into rows and columns. Graphs encode values visually, using marks such as bars, lines or points. The useful choice depends on the question readers need to answer.

Choose the view by the reader’s task

Reader’s question	Useful starting view	What to preserve
What was the exact value for this location and month?	Table	Clear row labels, units and precision
Which location handled more requests?	Bar chart	Comparable categories and the same reporting period
How did requests change month by month?	Line chart	Chronological order and consistent time intervals
What changed, and what were the underlying values?	Graph plus table	Matching scope, filters and definitions

The UK Government Analysis Function makes the same basic distinction: tables support looking up and comparing values, bar charts compare categories, and line charts show data over time. It recommends choosing the message before choosing the visualization. See its guidance on choosing visualizations.

Start with one clean source table

Here is a fictional dataset, created only to demonstrate the workflow. Each row represents completed requests for one location in one calendar month.

month,location,completed_requests
2026-01,North,120
2026-01,South,90
2026-02,North,150
2026-02,South,95
2026-03,North,135
2026-03,South,110

Keep the publication file rectangular: one header row, one observation per row and one value per cell. Put the dataset title and explanatory notes outside the data rows. Avoid mixing a “Grand total” row into the observations; including it in a later aggregation could count the same requests twice.

Before making a graph, check:

• Row meaning: is each row a location-month, an individual request or something else?
• Uniqueness: does each month-location pair appear only once?
• Numeric values: are counts stored as numbers rather than labels such as 120 requests?
• Missingness: distinguish a confirmed zero from an unknown or unreported count.
• Coverage: do all locations use the same reporting periods and definition of “completed”?

For temporal fields, follow the separate guidance on dates and time zones in public data tables.

Build the graph from the question, not the file layout

Suppose the question is: Did total monthly activity increase? Sum the locations within each month:

Month	Completed requests, both locations
2026-01	210
2026-02	245
2026-03	245

A line chart would show an increase from January to February, followed by no change in March. The original table still lets readers see that North fell in March while South rose.

If the question is instead Which location handled more requests over the quarter?, aggregate by location: North has 405 and South has 295. A bar chart fits that comparison.

These are different views of the same 700 requests. Label them accordingly: “Completed requests by month, both locations” and “Completed requests by location, January–March 2026.” A generic title such as “Requests” leaves the aggregation unclear.

For these positive-count bar charts, start the numeric axis at zero. Bar length represents magnitude, so cropping the baseline exaggerates differences. Line charts can use a cropped axis when needed to reveal a trend, but prefer zero when the trend remains clear and make the scale explicit. The ONS axis guidance explains this distinction.

Publish both with enough context to interpret them

Use only data cleared for public release. Do not upload private request records, names or other sensitive information to a public dataset page. If you publish this sample, keep its fictional-data label visible.

As of October 19, 2026, TablePage’s homepage describes uploads of CSV, TSV, XLSX and XLS files that generate a public shareable page with a filterable table and automatic charts, including bar charts, histograms and scatter plots. Treat an automatic chart as a candidate: check that its variables and aggregation answer your intended question. This does not assume that every chart type discussed above is available in the product.

Alongside the published view, provide:

• A title identifying the measure, population and period.
• Units and a definition of each important field.
• The underlying source and release or update date.
• Notes on exclusions, missing values and transformations.
• A short description of the graph’s main pattern.

Keep the values accessible rather than relying on a chart image alone. W3C’s guidance for complex images recommends descriptions that convey relevant scales, values, relationships and trends. For a fuller documentation structure, use the public dataset datasheet template.

Finally, reconcile the published views: the six source rows total 700, the monthly summary totals 700, and the location summary totals 700. Check a few exact values in the public table and confirm the graph uses the stated scope. Readers should be able to move from the visible pattern back to the numbers that support it.