Designing tables with lots of data

Short version: a big data table works when people can find a row, compare values down a column and keep their place while scrolling. That means a readable identifier in the first column, right-aligned numbers, a header that stays put, and sorting and filtering that are visible rather than hidden. The rest of this post, and the checklist below, fill in the details.

Designing data-rich tables can be a daunting task. But with the right approach, it can be achieved. We have previously shared tips on how you can design data-heavy UIs.

Now let’s take a look at how to design data-rich tables.

Define the Purpose

Let’s start with the basics. The first step is to identify the purpose of the table. What information needs to be conveyed? Once you know what the table is meant to show, you can start to design it. Make sure you also design for the worst-case scenario (e.g., when you have long names and numbers) and the empty state.

Visual Hierarchy

The columns of the table should be designed to show the most important information first. The data should be sorted in a logical order. The table should be easy to scan and the information easy to find.

Aesthetic Usability

The table should also be visually appealing. The colors and fonts should be chosen to make the table easy on the eyes. The table should be balanced and symmetrical.

User Controls

The table should be easy to use. The user should be able to sort the data and filter it to find the information they need. The table should be interactive and user-friendly.

Accessibility

The table should be accessible to everyone, and for tables that mostly comes down to markup. The W3C’s tables tutorial asks for real header cells (<th>) with a scope of col or row, a <caption> that says what the table is, and id/headers pairs only for genuinely complex tables. With that in place, a screen reader announces the column and row headers as the user moves between cells, which is what makes a 40-column table usable without sight. Never use a table for layout.

Shareability

The table should be easy to share. For data-heavy tables that usually means a link that preserves the current sort, filters and visible columns, plus an export (CSV for people who will work with the numbers, print or PDF for people who will read them). Print styles should repeat the header row on every page.

Responsive Design

The table should be responsive. On small screens there are three honest options: let the table scroll sideways with the first column frozen, drop low-priority columns and let users add them back, or turn each row into a card when people look at one record at a time rather than comparing across rows. Most importantly, when designing for mobile, decide which columns you’d like to drop i.e., not show on the mobile screens.

Checklist for tables with lots of data

Use this before handing a data table to development. Most items come from Nielsen Norman Group’s data table research and the GOV.UK table component.

• First column is a human-readable identifier, such as a name or order number, not an internal ID nobody recognises.
• Columns are ordered by importance, with related columns next to each other.
• Numbers are right-aligned (and use tabular figures) so digits line up for comparison; text is left-aligned. More on this in our post on table cell alignment.
• The header row stays visible when scrolling, and so does the first column if the table scrolls sideways.
• Rows are easy to track with subtle borders, zebra striping or a hover highlight.
• Sorting is obvious: the sorted column and direction are marked in the header. See using up and down arrows for sorting.
• Filters are visible and show when they are active, with a one-click way to clear them.
• Columns can be hidden and reordered without relying on drag and drop alone.
• Density can be adjusted: compact rows for experts scanning hundreds of records, comfortable rows for everyone else.
• Long and empty values are designed for: truncation with the full value on focus or hover, and a clear dash or “None” rather than a blank cell.
• Editing a record does not hide the table: a side panel keeps the rows the user is comparing against in view, where a modal would cover them.
• Markup is real table markup with a caption, <th> and scope.

Conclusion

Designing data-rich tables can be a daunting task. But with the right approach, it can be achieved. By following the steps outlined above, you can create a table that is both functional and visually appealing. If you’d like more tips on the data tables, check out the video on this page.