Tables

Tables should be used to show real data that makes sense in rows and columns. They work best when users need to compare related information, such as dates, fees, office hours, or contact details. A table should make information easier to understand, not harder to read.

 

Use tables for real data

Use a table when the information has a clear relationship across rows and columns.

 

Common examples include:

  • office hours by day

  • tuition or fee comparisons

  • deadlines by term

  • contact information by department

  • program requirements by category

 

If the content does not need to be compared across columns, it may not need a table.

 

Do not use tables for layout

Tables should not be used just to line things up visually. If the goal is only to control spacing or place content side by side, use layout tools instead.

 

A table should only be used when the structure helps users understand the information.

 

Keep tables simple

Simple tables are easier to read and easier to maintain. Try to keep the structure clear and predictable.

 

Good practices include:

  • use a clear header row

  • keep the number of columns manageable

  • keep labels short and meaningful

  • avoid extra formatting that makes the table harder to scan

 

If a table starts to feel crowded, it may need to be simplified or broken into smaller tables.

 

Add clear headers

Every table should make it easy for users to understand what each column or row represents. Header cells help define the meaning of the data.

 

For example:

Day Hours
Monday 8 a.m. to 5 p.m.
Tuesday 8 a.m. to 5 p.m.

This is clearer than a table with no defined headers.

 

Use a table caption when needed

If a table needs a short explanation, add a caption or brief introduction before it. This helps users understand what the table is showing before they start reading it.

 

Example

 

Office hours for Student Services:

Day Hours
Monday 8 a.m. to 5 p.m.
Tuesday 8 a.m. to 5 p.m.

A short caption can be especially helpful when the table appears in the middle of a longer page.

 

Keep cell content brief

Try to keep the text inside table cells short and easy to scan. Tables are not a good place for long paragraphs.

 

If a cell needs several sentences of explanation, the content may work better as regular page text with headings or a list.

 

Avoid merged and split cells when possible

Complex tables are harder to read and harder to maintain. Avoid merged cells, split cells, or irregular structures unless they are truly necessary.

 

If a table becomes too complicated, consider:

  • breaking it into smaller tables

  • turning it into a list

  • moving supporting details into text below the table

 

The goal is clarity, not packing everything into one grid.

 

Think about mobile readability

Wide tables can become difficult to read on smaller screens. Before publishing, consider whether the table will still make sense on a phone or smaller device.

 

Ask yourself:

  • is the table wider than it needs to be

  • can some columns be removed

  • would a list work better

  • should the information be split into separate sections

 

A table that looks fine on desktop may still be frustrating on mobile if it is too wide or too dense.

 

Example: when a table works well

A table is a good choice when users need to compare information side by side.

 

Example

Program Application Deadline Contact
Nursing March 1 School of Nursing
Medicine October 1 Admissions Office
Graduate School Varies by program Graduate School

This works because users can quickly compare the deadline and contact for each program.

 

Example: when a table is not the best choice

A table is usually not the best choice for content like this:

Service Details
Counseling Our office provides a wide range of services to support student wellness, academic success, and personal development through multiple programs and appointments.

That kind of content is usually easier to understand as a short section with a heading and paragraph.

 

Before publishing

Use this quick review before adding or approving a table:

  • The table is being used for real data, not layout.

  • The information makes sense in rows and columns.

  • The table has clear headers.

  • The table is simple and easy to scan.

  • Cell content is brief and relevant.

  • Merged or complex cells were avoided when possible.

  • The table is still readable on smaller screens.

 

Related guidance: Lists, Content Development, Office Files, and Image Files.