Design a Dashboard Table Readers Can Check

Suppose you are publishing a monthly service-request dashboard. Readers need to find their district, compare results and check the numbers behind a headline. The table should let them do those jobs without opening a spreadsheet.

Good dashboard data table design starts with the question and row structure—not colors or compact spacing. Build a clean dataset first, then decide which measures and controls belong on the public page.

Start with a row readers can explain

For this dashboard, define each row as one district in one month. Do not mix individual requests, district summaries and citywide totals in the same table: readers could mistake them for comparable records or add them together.

Here is an illustrative dataset, not real service-performance data:

District	Month	Requests received	Resolved from those requests	Resolution rate (%)	Median resolution days
North	2026-09	90	72	80.0	4.2
Central	2026-09	60	45	75.0	5.1
South	2026-09	50	40	80.0	—

Define the measures beside the table:

• Requests received: requests opened during the stated month.
• Resolved from those requests: requests in that same group resolved by the reporting cutoff.
• Resolution rate: resolved requests divided by requests received, multiplied by 100.
• Median resolution days: median elapsed time for requests in the group resolved by the cutoff.
• —: not reported, not zero.

State the reporting cutoff, too. Otherwise, a reader cannot tell how much time September requests had to reach resolution. When comparing months, explain any differences in follow-up time: a newer group may have a lower rate simply because it has had less time to resolve. A month with no requests has no defined resolution rate—not a 0% rate.

In the upload file, keep the median-days field numeric and leave the unreported cell empty; explain that convention in the page notes.

Give the table a clear place in the dashboard

A useful layout for this example is:

1. Title and reporting context: topic, period, cutoff and source.
2. Summary measures: requests received, resolved requests and overall resolution rate.
3. Optional chart: a quick district comparison.
4. Table controls and data: the values readers can inspect.
5. Definitions and provenance: calculation rules, missing values and source details.

Give the table enough width to show meaningful labels and values. Carbon’s design guidance recommends placing data tables in the main content area rather than cramped containers, with a title explaining their purpose and an optional description providing source context. Carbon data-table guidance

For the sample, the summary measures are 200 requests, 157 resolved and 78.5% resolved. Calculate the overall rate as 157 / 200 × 100, not as the unweighted average of district percentages. Do not average the district medians to produce a citywide median; calculate that from the underlying resolution times or omit it.

If the dashboard has both charts and tables, explicitly decide whether filters affect all of them. Label a fixed card “All districts” rather than allowing it to look like a summary of a filtered table. If the rate card follows filters, recalculate it from the matching resolved and received counts.

Choose controls that answer real questions

For a public, read-only dashboard, prioritize finding and comparing records over editing or batch actions.

Reader task	Design choice
Find a district	District filter, or search if there are many districts
Compare workload	Numeric sorting on requests received
Compare outcomes	Sorting on resolution rate, with request counts still visible
Review another period	Month filter with the selected period visible
Recover from an empty result	“No matching rows” message and a clear-filter action

Use a purposeful default order—for example, requests received descending—and make the active sort visible. Sort across the matching dataset before dividing it into pages, rather than merely rearranging the currently displayed page. If pagination is needed, show the matching row count and current range.

These are design requirements to check in your chosen publishing tool, not assumptions about its controls. Avoid adding filters for every column when a district and month selector will serve the task.

Make scanning and accessibility work together

Left-align labels and right-align numbers. Use consistent decimal precision, put units in headers and keep the counts beside percentages. Do not truncate district names or essential definitions just to fit more columns.

Color can reinforce a status, but it must not carry the meaning alone. Use a text label such as “Not reported” or “Below target” alongside any color coding. This follows WCAG’s requirement that color not be the sole visual means of conveying information. W3C guidance on use of color

A visually bold header is not enough for accessibility: the rendered table needs structural relationships between headers and data cells. Add a descriptive caption and check the published output. W3C tables tutorial

For a custom implementation, W3C’s sortable-table example uses buttons in sortable headers and aria-sort on the currently sorted header. Treat it as an implementation reference that still requires assistive-technology testing, not production-ready code. W3C sortable-table example

On a narrow screen, retain access to the identifying column and all essential measures. If horizontal scrolling is necessary, make it discoverable rather than hiding columns silently. For help writing the surrounding context, use the guide to accessible table captions and summaries.

Prepare and check the public page

Export a flat table with one header row, consistent month values, numeric measures and no embedded subtotal rows. Keep source attribution and reporting notes with the published dataset. Review reuse rights and remove sensitive information before uploading; this is a public-data workflow.

As of October 29, 2026, TablePage’s homepage describes uploading CSV, TSV, XLSX or XLS files to generate a public dataset page with a filterable table and charts. TablePage

After publishing, check the page—not just the spreadsheet:

• Find one district and compare its values with the source file.
• Check that numeric sorting, where available, treats numbers as numbers.
• Confirm that missing values remain distinct from zero.
• Verify what happens to summaries when filters change.
• Test keyboard navigation, screen-reader header announcements and the narrow-screen view.
• Make sure the reporting period, cutoff and source remain easy to find.

The acceptance test is concrete: can a reader find a district, interpret its rate and reconcile the displayed counts with the dashboard summary?