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:

Note: this article is primarily concerned with large data tables used in the workplace rather than with product-comparison tables (common on ecommerce websites).

In This Article:

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:

  1. Scalability: It’s easy to increase both the number of rows and the number of columns in a table if your dataset changes.
  2. 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.
A card-based display of data, with each card requiring a lot of eye movement and short term memory burden to compare
A card-based presentation of multivariate data requires users to spatially reorient each time they move their eyes from one card to another, making comparison tasks cognitively effortful and slow.

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.

An eye tracking visualization of a user looking horizontally across table rows for comparison tasks
An eyetracking gazeplot shows a participant fixating back and forth between the table’s data and the filters above. At one point, the participant engages in a hierarchical search of the table, moving his eyes between the first column, second column, then skipping to the fourth and sixth columns before moving to the next row of data and repeating the procedure. 

Designing to support this task involves a few different things:

  1. 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.
  2. 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.
  3. 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:

  1. Users will always know what they’re looking at.
  2. 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.)
Frozen header row and first column enables easier recognition of which row the user is investigating.
A frozen header row and first column, light borders, and zebra striping all support visual scanning behaviors and help users to keep their place as they look around and compare data. The subtle use of a drop shadow suggests that that the frozen first column and header row are floating “above” the rest of the table’s data, assisting with spatial orientation.
A dropdown menu for hiding table columns
An easily noticeable menu for hiding columns, that clearly indicates the current state (15 columns are currently hidden). Reordering columns here can be done in two ways: (1) dragging and dropping the column headers themselves (which has relatively low discoverability and poor accessibility, but is an efficient accelerator once learned) or (2) dragging and dropping from the list of columns in this visible menu.

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:

A modal popup for data editing that obscures the underlying data in the table
A modal popup for editing obscures information on the table.
  • 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.
A non-modal panel on the right side allows the user to edit but still review the underlying table data.
A nonmodal side panel allows for the full display (and editing) of a single record while still allowing the user to view the rest of the table’s data.

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