Functional design for tables

Good table design means that your information will be communicated quickly and accurately. By carefully designing the components of a table, you can ensure that the table is easy to understand both textually and visually.

Consider the data when structuring a table

When deciding how to arrange content in a table, consider:

• the amount of data
• the number of categories and number of sets of quantitative values
• the number of characters in each data cell for each category
• sequences and relationships in the data
• subsets or groupings within the data.

Tables can be structured in 2 main ways (see tables below):

• unidirectionally – categories are arranged in 1 direction, either across the columns or down the rows
• bidirectionally – categories are arranged in 2 directions, both across the columns and down the rows.

The categories themselves become the column or row headings.

When you are dealing with smaller tables (few categories and a small amount of data), there is more flexibility to arrange the data either way, although it is more conventional to arrange categories as column headings and list the data down the columns. If you have a large amount of data in each category, this may be your only option, because the table is then more likely to fit on a conventional page or screen.

If you have a large number of categories but a small dataset for each, it may be best to arrange the categories as row headings and list the data across the table.

If the data cells for some of your categories contain lengthy text, you may be better off restructuring the table by transposing the row and column headings. Then only some columns need to be wide, and text content will be easier to read, with a more appropriate column width: 

Another issue to take into account is which orientation will ensure that comparable sets of data appear close to each another. Also, screen readers will read a table from left to right across each row (see Table accessibility), so consider how this will work with your data layout.

Use sequences to order your data

Identify whether your dataset can be arranged into a hierarchical or meaningful order. Examples of meaningful order include chronological (time series), sequential (steps or advances), alphabetical, by rank or importance or significance, and by value (smallest to largest or vice versa).

If some data are derived from other data, the subordinate data should follow (either to the right of, or below) the data from which they were derived. Keep the order the same across a series of related tables.

Some hierarchical or sequential arrangements have associated display conventions. For instance, time series are best displayed horizontally (time advancing across columns), whereas rankings are best displayed vertically (most important in the top row to least important at the bottom). 

Use groups and breaks to focus attention

Grouping parts of your table into smaller chunks or subsets of data can help to direct users to analyse certain parts of the data in isolation. Breaking a table up can also be necessary because of page or screen limitations. When grouping or breaking up tables, it is important to do so logically, and with good design practices in mind:

• Visually group or separate parts of the table using white space, and minimal lines or shading (e.g. use a light rule under the last row of a group but no separating lines within the grouped rows).
• Repeat column headers at the start of each new page for a long table.
• Do not use heading rows that span the table – restructure these either as a new left column or break the table into smaller tables (see Table accessibility regarding use of subheadings).
• Do not vary the structure of the table from group to group (e.g. using a different quantitative dataset or units partway down a column) – if this seems necessary, they should be separate tables.
• If you want users to analyse a group of data in isolation, consider putting it in a separate table. 

Use clear column headings

The following principles are recommended, illustrated in the tables below:

• Include column headings for all columns, even if it seems obvious to you or the heading is generic, such as Item or Characteristic.
• Left-align the heading in the left-hand column (above the stub).
• For columns of numerical data, centre the headings above the columns of numbers. For columns of text data, left-align the headings.
• Align column headings to the bottom of the cell.
• Keep column headings brief, and use sentence case (initial capital only for the first word and proper nouns).
• Use only 1 level of headings, if possible, and not more than 2; if you have more than 2 heading levels, consider restructuring the table.
• Separate headings from subheadings by a rule (cell border).
• All text should be horizontal, where possible. If necessary, you can make it oblique (rotated 90°), but never vertical (i.e. with letters the right way up but stacked underneath each other) (see the tables below).
• Include the unit of measure in parentheses at the end of the column heading (unless it is the same for all results columns, in which case it can appear in the title). Use unit multipliers as appropriate (see Numbers), and make sure these are used consistently across similar tables.

Visually define columns and rows

White space is the least distracting means of visually separating columns and rows. In other words, lines may not be needed – your eye automatically sees the structure, without the need to add any distracting and superfluous elements. This allows the eye to concentrate on the data and browse easily from item to item.

Garish, high-contrast ‘zebra’ striping of tables and heavy gridlines are more likely to deter users than improve ease of reading. Therefore, rules (gridlines), shading and other dividers or guides should be minimised. Vertical rules at the edges of a table to separate the first or final column from adjacent empty space are unnecessary.

However, if your table is very large or complex, so that some data cells are a distance from the table headers, consider using subtle lines or shading to help guide the eye. In these cases, dividers or guides should run in only 1 direction, either dividing rows or dividing columns, not both (this would form a grid). The guides should run in the most logical direction to link cell data in the appropriate related information string, generally horizontally.

If your table is structured bidirectionally, the guides should run horizontally, because this is the predominant reading direction.

Rather than applying rules or shading to the entire body of a table, consider using these features to group or highlight subsets of data, such as summary rows. If alternate shading of rows is necessary, keep the shading subtle (pale) and low contrast (e.g. white alternating with a 10% tint of your chosen colour). Text can also be emphasised or highlighted by applying bold or italics to selected cells, such as totals; keep all body text in a single colour.

Although spacing is often enough to visually group or separate data, do not insert blank rows or columns to achieve that spacing – instead, use cell margins and good formatting to ensure sufficient space between data.

Try to fit the table on a page

If a table can fit on a single page, do not allow it to break across pages – move it to the next page to keep it whole.

For a large or complex table that breaks across pages, try restructuring the table by transposing the rows and columns or breaking the table into multiple smaller tables (see examples below). Alternatively, or for larger datasets, it may be necessary to:

• insert a landscape-oriented page, placing the table (with table name and any notes) on this page and continuing the text flow on the next portrait page
• rotate the table (with table name and any notes) by 90° (anticlockwise) so that it sits sideways on a portrait page
• span the table across a 2-page spread – it may be necessary to repeat the stub on the second page or add line numbers to both the left and right ends of each row to ensure that users can follow the data across the page break or gutter
• insert a larger page.

If your dataset is so large that it requires any of these options, consider how this will affect the reading flow, pagination and print production of the document. For example, users may display an online PDF in single-page view, which would make a spanned table difficult to view and comprehend; inserting a larger page that needs folding is likely to increase the cost of print production. Consider placing a large table at the end of the publication as an appendix, or even providing tables as a separate document. Also consider whether the data could be presented as a graph or other figure type, with a reference to the table or data source.