Data tables

Data tables

Why a data table design guide?

After a decade designing big data oriented enterprise applications, I still find highly-nuanced data tables to be a great source of confusion for designers, PMs, and engineers.

What's more - complex table design artifacts aren't simple to produce and so re-usable table components (Figma & Code) are essential to saving time and crafting more consistent user experiences.

Data table design guide preview

Overview

Data tables are everywhere. They are our primary tool for organizing information in the digital world, from spreadsheets and databases to enterprise applications and consumer products.

What is a table?

A table is a collection of records or values presented in rows and columns. Each row represents a record, and each column represents a field or attribute of that record.

Tables are often complex UI components that must balance density, scannability, and interaction. Good table design helps users find, compare, and act on data quickly.

Use cases

Most tables are designed to support 4 common user tasks:

  • find records
  • compare data
  • view/edit/add new records data
  • and take actions on records (eg change status)

Anatomy

Here's a breakdown of functional features commonly found in tables:

Essential elements

These are the core components required for a data table to function correctly.

  • Column headers
  • Rows
  • Cells
Essential table elements: column header, rows, and columns Simple essential data table example

Optional elements

These are additional components that extend a table with extra functionality or information.

  • Checkboxes
  • Pagination
  • Search
  • Filtering
  • Sorting
Optional table elements including filters, search, sorting, and pagination Full-featured optional data table example

Table features

Title header (and/or sub-title description)

Every table deserves a descriptive header so users can quickly identify the intended value before digging into dense details. A header tag can belong to the entire screen if the screen is centered around a table or can go directly on the table itself. Just don't leave tables floating half way down a screen without a title in sight.

Primary action

Some tables may allow users to create new table records. These screens typically revolve around the table and can leverage standard primary action buttons (vertically alignmed with table title).

Expanding rows

  • Expanding rows allow a user to quickly access additional row-level information without navigating off to a details screen.
  • This is a flexible i-frame to support a variety of content.

Filters

In large data sets filters allow users to narrow their table results down to a smaller set of records with some shared characteristic(s).

  • Table filters usually correspond to visible columns in the table but are not required to.
  • Each workflow will have different filtering needs, and not every column will always deserve a filter.
  • In more focused workflows or due to technical and performance related constraints it is possible to make specific filters mandatory and/or persistent for higher visibility. If a filter is mandatory, consider using a default selection or asking users to pick a filter preference before they load the table.
  • Filters are less helpful on columns with a high count of unique values; for example finding a unique ID when there are 100s of unique IDs is a task better suited for the table search tool.
  • Users may apply table filters at any time, either before or after a table search but keep in mind how applying filters may impact a user's current row selection.
  • It is important to make clearing all filters very easy

Saved searches

  • This advanced search feature is intended for repeate power users only - it is tucked subtly inside the search menu.
  • Users can save and quickly load a re-usable search configuration (search term + filters).
  • To create a saved search, conduct a normal table search and then use the 'save' option inside search menu.
  • Manage saved searches in a separate screen where they can be run with 1 click, re-named, or deleted.

Sorting

  • The currently sorted column is indicated by a dark bottom border and arrow in the column header which signals an ascending or descending order.
  • Ideally all columns should be sortable alphabetically, numerically, or by date (except for actions columns).

Row selection

  • The single checkbox in the multi-select bar can select/unselect the full active page of records with a single click
  • A ratio indicates the count of selected records over the total number of records across all pages
    • The example ratio below indicates 3/75 rows selected, however only 2 selected rows are in-view. This tells the user a 3rd selection is also active somewhere beyond the current page - an important piece of feedback when using pagination.
  • "Select all 75" ghost button allows user to select all records across all pages

* Special consideration for filters and search combined with selection : table filters and table search may alter a table selection. If a user has already selected some rows and then rows become narrowed further by applying a filter (or search), it's possible the selected records get filtered out of the table. In this case users should be notified before applying any irreversible impact to their working selection.

Table actions

  • Some actions in the toolbar buttons may apply only to selected records (example: delete selected record)

Row-level actions

  • Single row actions can be added to an actions column in the table.
  • Multiple single-row actions can be added into an actions overflow menus.

Bulk actions bar

  • The bulk actions bar is a default location for general table actions (example: download, or share)
  • Some bulk actions may apply only to the active user selection (example: delete, or archive).
  • All toolbar buttons should have icons. Also more compact icon only buttons may also work well depending on user context and icon choices.

Table settings

  • Users can configure the visible columns by selecting checkboxes on the left
  • Drag-and-drop the gripper icons in table settings drop-down menu to re-order table columns
  • Row sizing modes (compact, default, large designs in progress)

* Additional table settings TBD
Row sizing modes (compact, default, large)
Available filters

Pagination bar

  • The multi-select counter ratio in the bulk actions bar accounts for user selections across several pages of results (see example: Select all 75)

Items per page

  • Control the number of items shown on each page with a menu (10, 20, 30, 40, or 50) and view more items as needed or fewer items to limit the table and screen height when navigating longer lists.

Pagination controls

  • Table pagination can be applied to improve performance and prevent large tables from slow loading.
  • Pagination can also make long tables easier to navigate by breaking content into more manageable chunks.
  • When using pagination, product teams should consider the ideal table length for their use case and also allow enhanced user control with the "Items per page" control in the bottom left of the table.

Keyboard navigation

Top-level focus

  • The table component can be a single point of focus on the screen, separate from navigation or other page section.
  • The table should announce itself by the title, title description and table column headers (for example, 'Offers Table, filter, search and manage offers campaigns. Campaign name, status, start date, end date...')

2nd-level tabbing elements

  • Users can enter and navigate the following sub-components with arrow keys + enter, escape keys.
  • Upon focus, 2nd-level sub components like buttons, menus and search or text inputs should maintain their own standard keyboard controls.
  1. Primary action
  2. Filters (or search)
  3. Search (or filters)
  4. Table content

Table columns, rows, and cell content

  • Keyboard users should be able to enter and navigate core table data with arrow keys + enter, escape keys.
  • More information on data table accessibility learn how screen readers navigate data tables.
...you do not need to make each cell of a table focusable with a keyboard to aid navigation. If the cell contains a focusable and interactive element that's OK, but if it contains non-interactive content it is likely that you will make keyboard users work much harder to navigate the table than you intended. — Léonie Watson

Got feedback? Please contact alexwyrick.alexander@mastercard.com