Table design system

Advanced table features optimized for scale and usability; click and test features below in the playground or navigate to each section for more detailed design considerations.

Why a table design guide?

With dozens of micro-components and countless edge cases, a solid table system is expensive to design well (for scale) and develop (without bugs). An intuitive design guide and configurable component code-base can dramatically reduce design and engineering time, prevent bugs, and create more consistent end-user experiences.

Tables are also more nuanced than they appear, creating confusion for designers, PMs, engineers, and end-users alike. After a decade of designing enterprise applications—and reviewing dozens of solutions for individual table features—I’ve hand-picked these patterns to balance scale, usability, and consistency.

Table users

Data tables support 4 common user tasks:

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

Anatomy

Client-side React component with demo search, filtering, bulk-actions, pagination and more. Numbers 1–3 are the core pieces every table needs; 4–12 are optional features that extend it.

Table features

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 (align vertically with the table title).

Filters

In large data sets filters can help users narrow the table view down to a smaller set of records that share some confined 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

Table search

• A table search tool can help users find unique values within a long data table quickly. Columns containing unique values like names and addresses are great candidates to make searchable.
• A table search can index all cells of an entire table or if the table is particularly large with many free text values, the search function can be restrict to specific columns of user interest.
• Consider how changing search terms (or applying new filters) may impact a row selection and be sure to warn users before any selection is lost by loading new search results.
• Save and load searches (details below) can be made available in the search bar drop-down menu.

Pro-tip : Allowing recent searches, or trending searches with just one click inside the search menu can be an incredibly helpful enhancement to any search bar.

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.

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.

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 (5, 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.

Page navigation

• Given a longer list of items, pagination controls allow users to skip to different pages including the first page, previous page, an exact user typed number page input, the next or the last page.
• The total number of pages is clearly indicated, and the exact range of items visible on the current page.

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

Accessible 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