Tables vs lists

Lists and tables can be quite visually similar and can sometimes represent the same data. This guide will outline content and user considerations in determining which pattern is the most appropriate.

Also known as:
Data TablesTabular DataCardsTilesRowsGrids
  • Tables also known as: Data Tables, Tabular Data
  • Lists also known as: Cards, Tiles, Rows, Grids

Need to know

Tables and lists have distinct patterns which shouldn't be mixed.

Tables

  • Tables are for presenting information which gives the user the flexibility to sort the data to find their own patterns
  • Tables must include column headers for sorting

Lists

  • Lists are for presenting grouped information into scannable patterns. The content within a list can be stacked to create hierarchy within the data
  • Lists are sortable by a ‘Sorted by’ Select, and do not have column header labels
  • A single row of a list should make sense in isolation

Tables

Tables display rows and columns of tabular data.

For the user

  • Tables help make it easy to scan large amounts of data
  • Tables make it efficient to find patterns in values
  • Data can be sorted by ascending or descending order using table column headers

For the designer

  • A table allows the user to assess and control the data to find their own patterns
  • Raw tabular data is where data is imported from a .csv and does not contain any styling and is identical to its source file, such as the Employee data import example

Structure

  • Tables must represent more than 1 row of tabular data, otherwise use a card to contain a small volume of data. (e.g. Tile / List)
  • For textual or numerical values, column cells can contain only 1 piece of information
  • Avatars can be considered as a data point and can be useful alongside a name to quickly scan for recognisable faces
  • Columns cells that require additional visual or interactive components (e.g. Avatar and name) can contain more than 1 piece of information:
    • Interactive components (such as Buttons or Selects)
    • Non-interactive elements with no natural grouping or order (such as avatars or icons)
  • Tabular data is structured into rows of cells of related information. Each row contains the same number of cells (although some of these cells may be empty), which provide values of properties of the thing described by the row. (Source: W3C)
  • If there is an action it should be included to the far right of the table row
  • Tables can have interactive elements (e.g. checkboxes) to provide functions such as multi-select and bulk actions
  • Tabular row content stays tabular even on small viewports. If you need to reflow and stack content responsively, use a List

Sorting

  • Tables must be sortable via table column headers
  • By default, one column must be sorted (e.g. chronological order or magnitude). Always present the user with the most relevant data first.
    • The sorted column should be easily distinguishable and in which direction it is being sorted
  • Sorting by a column reorganizes all the content in the table. The values across each row remain the same when the sort is applied

Recommendation

  • All content has the same weight and has equal visual emphasis. If there is key information that needs to be more prominent, consider the order of which the data is presented
  • Cells can contain links, but avoid linking whole table rows. If you need to link a whole row, use a List

Lists

Lists group and stack information into logical and hierarchical patterns.

For the user

  • A good way to browse and surface information. E.g. Looking for names, viewing favourable scores

For the designer

  • Lists prioritise content. Metadata small, key information bigger
  • Lists are a collection of objects of the same type (e.g. A set of questions, or a group of people)
  • For rich data (e.g. Data visualization, avatars, hero data)
  • Surfacing the most interesting information is more important than finding detailed data
  • Lists can be either stacked horizontal rows of Cards or gridded Tiles
  • Lists can also provide bulk actions
  • Lists must use a Select as a ‘sorting by’ function
  • On small viewports, the data in these lists can reflow and stack responsively. Design of the specific application of this is the responsibility of the designer
  • Lists cannot have column headers. Use a Table if you need to identify information with headings.
  • For guidance on how to link within lists, follow the same guidelines as Tiles
    • Single Action: Exactly one interactive element, so hover/focus/click interaction applies to the whole object. See also: Single action Tile
    • Multi-action: Multiple interactive elements inside the object container. See also: Multi-action Tile

See also

External links

Tables

Lists