How to Design Data Tables People Can Actually Use

If you design B2B software, admin panels, or internal tools, you'll design a lot of tables. They're often treated as a solved problem — drop in a component, list the database columns, ship it. The result is usually a table that technically shows everything and practically helps nobody.

A well-designed table lets people scan, compare, find, and act on records quickly. These are the rules that make the difference.

Know what people do with the table#

Tables support a handful of core tasks:

• Scanning to get an overview.
• Finding a specific record.
• Comparing values across rows.
• Acting on one or many records.

Different tables emphasize different tasks. A list of invoices is mostly about finding and acting. A list of server metrics is mostly about scanning and comparing. Knowing the primary task shapes every decision that follows.

Choose columns deliberately#

The biggest improvement you can make is usually removing columns. Every column competes for width and attention.

• Show the columns people need to identify and decide on a record.
• Move secondary details to a detail view or expandable row.
• Put the most important identifying column first — usually a name or title.
• Order remaining columns by importance, not by database order.
• Consider letting users show, hide, and reorder columns for complex tables.

If people regularly scroll horizontally to find the information they need, the default columns are wrong.

Align content correctly#

Alignment makes tables scannable:

• Text: left-aligned.
• Numbers: right-aligned, so digits line up and magnitudes are easy to compare.
• Dates: left-aligned, in a consistent format.
• Status badges and icons: left-aligned or centered consistently.
• Headers: aligned the same way as their column content.

Use tabular figures for numbers so every digit has the same width, and keep decimal places consistent within a column. A column where some values show two decimals and some show none is surprisingly hard to read.

Pick the right density#

Row height affects how much fits on screen and how easy rows are to read:

• Compact rows work for experienced users who scan large datasets.
• Comfortable rows are better for occasional users and touch devices.

Offering a density toggle is a good option for products with both types of users. Whatever the density, maintain enough padding that rows don't feel crushed and enough contrast that each row is distinguishable.

Help the eye track rows#

In wide tables, it's easy to lose your place when reading across a row. Help with:

• Subtle row dividers or zebra striping.
• A hover highlight on the full row.
• Keeping the first column fixed when scrolling horizontally.
• A sticky header when scrolling vertically, so column names stay visible.

Format values for humans#

Raw database values are rarely the best display format:

• Show relative dates such as "2 hours ago" for recent activity, with the exact timestamp available on hover.
• Abbreviate large numbers where precision isn't needed.
• Use status badges with text labels, not color-only dots.
• Truncate long text with an ellipsis and show the full value on hover or in the detail view.
• Show a clear placeholder, such as an em dash, for empty values instead of leaving a blank cell.

Make sorting obvious#

Sorting is one of the most used table features:

• Indicate which columns are sortable.
• Show the current sort column and direction clearly with an arrow icon.
• Choose sensible defaults — often most recent first, or most urgent first.
• Keep the sort when users navigate away and come back.

Design filtering and search together#

For large tables, people need ways to narrow results:

• A search field for finding specific records by name or ID.
• Filters for common attributes like status, owner, or date range.
• Visible active filters with a clear way to remove each one.
• A result count, so people know how many records match.

When filters return no results, explain that clearly and offer a way to clear filters rather than showing an empty table with no message.

Row actions#

Actions on individual rows should be easy to find without cluttering every row:

• Make the whole row clickable to open the detail view when that's the primary action.
• Place one or two common actions directly in the row if they're used constantly.
• Group less common actions in an overflow menu at the end of the row.
• Keep destructive actions out of the way and confirm them, or better, offer undo.

Avoid showing ten icon buttons on every row. It turns the table into visual noise and makes each action harder to find.

Bulk selection and actions#

When people need to act on many records at once:

• Add checkboxes in the first column, with a select-all checkbox in the header.
• Show a bulk action bar when items are selected, including the count of selected items.
• Clarify whether "select all" means the current page or all matching results.
• Keep selections stable while users scroll or change pages, if that's supported.

Pagination, infinite scroll, or load more#

Each approach has trade-offs:

• Pagination is best for tables where people need to find their place, share links, or reach the end.
• Load more works for browsing when people rarely go far.
• Infinite scroll suits feeds more than data tables, because it makes it hard to reach footers and return to a position.

For most business tables, pagination with a page size selector is the most predictable choice. Show the total count and the current range, like "1–25 of 340."

Loading and empty states#

• Show skeleton rows while loading so the layout stays stable.
• For first-time empty states, explain what the table will contain and how to add the first item.
• For filtered empty states, explain that nothing matches and offer to reset filters.
• For errors, explain what went wrong and offer a retry.

Tables on small screens#

Wide tables don't fit on phones. Options include:

• Horizontal scrolling with a fixed first column.
• Converting each row into a card that shows the most important fields.
• Showing fewer columns on small screens, with full detail in the record view.

Choose based on the task. For comparing values across rows, horizontal scrolling preserves the table structure. For finding and acting on individual records, cards are often easier.

Accessibility#

Tables need proper structure to be accessible:

• Use real table markup, with header cells associated with their rows and columns.
• Make sortable headers keyboard-accessible buttons that announce sort state.
• Ensure row actions and checkboxes have accessible labels.
• Maintain sufficient contrast for text, borders, and status indicators.

Tables are tools#

A good table feels like a precise instrument: the right columns, aligned for scanning, with fast ways to sort, filter, find, and act. Spend time understanding what people do with the data, remove what they don't need, and design every state. It's not glamorous work, but in many products, the table is where users spend most of their day.