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 (image source):
The Google Material Design guidelines suggest that tables should only be used when there are three or more columns. Side-by-side lists or any other text control can be used for a simple two-column comparison.
How to Use Data Tables
- Use a header row with descriptive titles. (macOS Human Interface Guidelines)
- Let people click column headings to sort a table view if it provides value. (macOS Human Interface Guidelines)
- 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. (GNOME Human Interface Guidelines)
- Alternate row colors for large tables. This is often referred to as “zebra striping”. (macOS Human Interface Guidelines)
- Checkboxes should accompany each row if the user needs to select or manipulate data. (Google Material Design guidelines)
- 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. (GNOME Human Interface Guidelines)
- 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). The Google Material Design guidelines offer some specifications for padding and spacing within tables. You can give users the option to change the display density (as shown here), but don’t use this an 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 scrolling 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. You can see some table filter examples here.
- 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. (A List Apart)
Types of Data Tables
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 (KDE Human Interface Guidelines).
Most table variations exist for the purposes of showing additional data for a specific row. This is done to avoid forcing the user to visit a new page and losing context.
This article on designing better data tables shows examples of this variation, including:
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.