Data Table Guidelines
Data tables, also called table views, tables, and data grids use columns and rows to display related information in a grid.
Tables are readable and familiar when designed appropriately.
For very simple tables the guidelines are easy to follow. The challenge comes as the data becomes too much to parse at a glance. When you start adding ways to filter, sort, search, and act on the data the waters get a lot muddier.
When to use data tables
Data tables are best used for numerical data and lists of objects of the same type.
Here is a typical numerical data table:
Tables, like the one below, with actions, links, and buttons are common in enterprise, CRM, and other business applications:
The Google Material Design guidelines suggest that tables should only be used when there are 3 or more columns. Side-by-side lists or any other text control can be used for a simple 2-column comparison.
How to use data tables
- Use a header row with descriptive titles.1
- Let people click column headings to sort a table view if it provides value.1
- Clicking once on a column heading should apply "natural" sort order (e.g., alphabetical, smallest number first, earliest date first, checked items first) and show a down arrow. Clicking again should reverse the order and show an up arrow.2
- Alternate row colors for large tables.1 This is often referred to as "zebra striping".
- Checkboxes should accompany each row if the user needs to select or manipulate data.3
- For actions that can only be applied to one row at a time (e.g., edit, view details), standard practice is to provide a link or icon in the last column of the table.
- Use the <THEAD> and <TH> HTML tags for header rows for accessibility and easier visual styling.
- Left-align text and right-align numbers.
- If you have numeric data, keep the level of precision appropriate. The fewer decimals, the less time it takes to scan and understand the data.
- Show only the information that users really need to see, but provide the ability to dig deeper into details if needed. Use Inlays, Overlays, and tooltips for showing details on the same page with the table to maintain user’s flow.
- Consider using floating (i.e., "sticky") header rows for long tables.
- Provide the ability to search within long tables.2
- Pay attention to display density. Having the data too close together makes it hard to read, yet using too much spacing means more scrolling (and more time to find what the reader is looking for). You can give users the option to change the display density (as shown here), but don't use this as an excuse not to pick a good default.
- Pagination is useful for large data sets, but don't immediately assume that it's needed. Studies have shown that users don't mind scrolling4 in many cases and showing all the information on one page means that users can search and sort more easily to find what they're looking for.
- If you use pagination, make sure to show the total number of pages or results. The ability to choose how many rows to show on a page is also useful.
- Actions that users can perform on the data should be placed around the edges of the table (as shown in the example below). Pagination is usually placed at the bottom, while filtering, sorting, and multi-row actions are often placed in the top-left and/or top-right.
- If you provide a way to filter or otherwise limit the data, make sure to clearly indicate that a subset of the data is being shown.
- Use color and decoration sparingly. It can be useful to highlight unexpected data (such as extreme/outlying values or failed actions), but can detract from overall readability.5
Tables don't have states like other UI controls, but some have cells which can be changed from read-only to editable. In the case of editable cells, they should be visually distinct through a lowered bevel or thicker border.6
One common variation is the expandable hybrid table/tree view. This is used to avoid forcing the user to visit a new page and losing context. See the further reading section below for more table variation examples.
These details-on-demand variations should be reserved for complex data tables. It is overkill for cases where the user is primarily browsing. A better choice is to carefully consider which information the user needs to see and provide only that data.
- macOS Human Interface Guidelines
- GNOME Human Interface Guidelines
- Google Material Design guidelines
- UX Myths
- A List Apart
- KDE Human Interface Guidelines
- <THEAD> and <TH> HTML tags
- Design better data tables by Andrew Coyle
- Web Typography: Designing Tables to be Read, Not Looked At (A List Apart)
- Table Filter Design Pattern