Data Table UI Design: Sorting, Filtering and Row Density

The main job of a table

A table in a CRM or admin panel exists for two things: scanning and comparing data, and acting quickly on records. Test every design decision with one question: did it become easier to find the right row and do something with it?

Basic rules:

• text aligns left, numbers align right;
• important columns come first;
• the header stays visible while scrolling;
• actions are available without extra navigation.

Alignment and formatting

For numbers, use tabular figures (font-variant-numeric: tabular-nums), a consistent number of decimal places and thousands separators. Align a column header the same way as its content.

A status must not rely on color alone: add text or an icon so people with color vision deficiencies can tell statuses apart.

Column priority

• Put first the column people identify the record by: client name, order number.
• Next, what people make decisions on: status, amount, date.
• Technical fields (ID, created date) go last or are hidden by default.
• Let people customize visible columns, and remember their choice.
• Truncate long text with an ellipsis and show it in full on hover or in the record view.

Sticky header and first column

During vertical scrolling the header should stay in place, otherwise people forget what a column means. In wide tables, also pin the first column so horizontal scrolling does not lose track of which record is which.

th { position: sticky; top: 0; background: var(--surface); z-index: 1; }
td:first-child, th:first-child { position: sticky; left: 0; background: var(--surface); }

Sticky cells need a background — without one, scrolled content shows through underneath.

Density modes

Different people need different density: an operator who works in the table all day wants it compact; a manager who checks in occasionally wants more room.

• Compact — more rows on screen, less padding.
• Default — the balanced standard.
• Comfortable — easier to read, better on touch screens.

Row height changes, but font size and tap targets should not become too small. Zebra striping or row dividers help the eye follow a row across wide tables.

Sorting and filtering

• Sort by clicking a header, with a clear direction arrow on the active column.
• Sortable columns should look different from non-sortable ones.
• Filters live above the table or in column headers; show active conditions as chips that can be removed.
• Keep sort and filter state in the URL so a view can be shared by link.

Inline actions and bulk selection

Place inline actions (edit, open, delete) in the last column. The frequent action gets a visible icon; rare ones go into a "⋯" menu. Showing actions only on hover fails on touch screens and for keyboard users.

Bulk selection:

• a checkbox in the first column and "select all" in the header;
• selecting rows reveals an action bar with the selected count;
• if there are more records than on the page, clarify whether the page or all results are selected;
• confirm dangerous bulk actions, and offer undo for reversible ones.

Pagination, loading and empty states

For working tables, pagination with a rows-per-page choice is usually best. Design the states too: loading (skeleton rows), empty (what to do next) and error (how to retry).

Tables on mobile

A wide table cannot simply be squeezed. Options:

• Cards: each row becomes a card with 2–4 key fields and a link to details.
• Horizontal scroll with a pinned first column — when comparing across columns matters.
• Column selection: only priority columns show on narrow screens.

For a CRM on a phone, cards usually work best: people typically need to find a record and take one action, not analyze dozens of columns.