If you have lots of data, there’s a strong likelihood that you will end up displaying it in a table. Tables are present in many workplace applications precisely because they are a compact way of showing a large multivariate dataset. However, big tables present challenges to both designers and users.
This article is part of a series that covers various aspects of designing usable tables:
- Common user tasks associated with tables and how to support them on desktop
- How to deal with tables that are too big for the screens on which they are displayed — including tables for mobile or variable-size viewports (as in responsive design)
Note: this article is primarily concerned with large data tables used in the workplace rather than with product-comparison tables (common on ecommerce websites).
Tables vs. Cards or Modules for Data Presentation
Tables are not usually winners of a UI beauty contest — they are a utilitarian part of our designs. To embrace their functional advantages over other, perhaps more aesthetically pleasing, forms of multivariate-data displays (such as collections of cards or dashboards with various information visualizations and data charts), we need to understand when to use tables and what kinds of user tasks are suited to them.
The primary advantages of a data table over other data-presentation options are:
- Scalability: It’s easy to increase both the number of rows and the number of columns in a table if your dataset changes.
- Support for comparison tasks: In a table, two adjacent data points are easy to compare because, unlike with a card-based UI, users don’t need to either move their eyes much or store information in their working memory, as they can see both items at the same time.
Main User Tasks in Tables
While the specific tasks carried out on a table will vary depending on applications or even users, the following 4 tasks are frequently performed and can be considered the core tasks to be supported by a table design:
- Find record(s) that fit specific criteria
- Compare data
- View, edit or add a single row’s data
- Take action(s) on records
Find Record(s) that Fit Specific Criteria
When users engage in this type of task, they may seek a specific item (whose name or other pertinent details they already know) or may look for several items that meet a few criteria they have in mind.
This process might involve filtering, sorting, using a search feature (or using the browser’s built-in CTRL-F feature on the page), or simply visually scanning down the table. The reasons users will choose one of those interactions can be hard to predict and it’s based on the specifics of the data table, as well as on their expectations of what will be the least effortful way to find what they’re looking for.
Designing to support this task involves a few different things:
- The (default) first column should be a human-readable record identifier instead of a “mystery meat” automatically generated ID. This design will allow users to scan and locate a record of interest.
- The default order of the columns should reflect the importance of the data to the user and related columns should be adjacent. In other words, once a user has located a potential record of interest, don’t force them to move their eyes back and forth between column 1 and column 20 because those are the most relevant columns.
- Filters need to be discoverable, quick, and powerful. Filter syntax should be transparent to users. Moreover, users should be able to easily understand that they are looking at filtered data (that is, there should be a clear visual indication that filters are active).
Compare Data
Tables are most effective when they allow users to easily compare data — whether this data is in two or more records or in different columns. Often, these comparisons aim to detect relationships between different variables or records, data ranges for a column, outliers or to simply explore what is typical for one or more variables.
There are two common issues that users encounter when performing comparisons in complex, big tables:
- Because of the sheer volume of data filling up the screen, it can be complicated to understand what each cell stands for and to which record it belongs.
- Sometimes the columns users wish to compare are far away from each other — with one being even perhaps off canvas and requiring horizontal scrolling to view. Not only is scrolling back and forth tedious, but users will also need to memorize data from one column, bring the other column into view, and compare what they remember with what they see.
- The same thing can happen with rows — if people need to compare data from nonadjacent rows, it can be difficult to move back and forth between them and also ensure that the user is looking at the right cell.
The primary design solutions ensure that:
- Users will always know what they’re looking at.
- Data points of interest can be brought in close proximity.
Here are some specific guidelines related to these two principles.
1. Locating Relevant Info
- Freeze header rows and header columns (if the table is larger than the screen).
- The visual design needs to enable users to keep their place as they move their eyes across the table. Borders, zebra striping, and hover-triggered highlighting of a record can all help.
2. Making Information Adjacent for Comparison
- Hiding and reordering columns must be easy to accomplish (low interaction cost and accessible for those that don’t use drag and drop interactions). These features should be discoverable and clear visual state indicators should signal to users that some columns are hidden.
- Hiding or reordering records and sorting after a particular variable should also be easy to accomplish. (This feature is often related to filtering, but is not exactly the same — the user should be able to manually hide one or more records.)
View, Edit, or Add a Single Row
Another common task in tables involves viewing, creating, or editing a single record. For all three cases, a tabular presentation of a single record can be challenging to read (and even more so to edit), especially when the table is wide and the user will have to scroll horizontally in order to access all the fields.
There are a variety of ways to present a single record as a complete unit, optimized for readability and editability. Each has different tradeoffs to consider:
- Edit in place (where the table row becomes editable). This solution works only if the table is narrow. Make sure that the row looks different in Edit mode, so that the user can clearly see what is editable to prevent accidental edits.
- Modal popup. The big downside with a modal implementation (and why we generally don’t recommend modals for deep editing work) is that it will cover adjacent records in the table and the user won’t be able to reference or copy data from a similar record. We routinely observe in testing that users refer to existing data in other records while they edit a record (as that helps them to recognize, rather than recall reasonable value ranges).
- Nonmodal panel or separate window. Either of these options will cover some of the table, but still allow users access to the table data.
- Opening the row as an accordion. While this presentation doesn’t obscure other parts of the table, a downside is that users don’t tend to clean up after themselves (i.e., close accordions when they are done with them) and they may end up with cluttered displays unsuited for the other core table tasks. More important, users will have difficulty referring to records that are not in immediate proximity of the one being edited.
Taking Action on Records
Another important task in a table is to take action on one or multiple records (beyond editing the record itself) — for example, deleting, sharing, or performing some other data-specific action (like sending out invoices, changing deadlines, etc.).
Traditionally, there are two ways to implement this task: single-record actions and batch actions.
Single-Record Actions
Placing the single-record actions inline within a table row can work if you just have one or two actions, but, when there are more, screen space becomes an issue. As a result, multiple single-record actions end up either:
- Crowded, with no text labels, and thus be hard to click and also hard to distinguish, or
- Hidden under a hover gesture or a generic Actions menu, and thus hard to discover (and potentially with low accessibility if a hover gesture is used).
Batch Actions
Batch actions usually involve a mechanism for selecting records (e.g., a checkbox for each record) and then a series of action buttons or menus above or below the table. This type of design allows for a space-efficient presentation of multiple options. If applying the same action to the full data set is a common need, it’s a convenient shortcut to have a single-click option to Select All.
Summary
Compared to modular presentations such as card-based displays, tables are space efficient and well suited for comparing records and for detecting patterns in the data.
Data tables must support the following frequent user tasks:
- Find record(s) that fit specific criteria
- Compare data
- View, edit or add a single row
- Taking action on records