SaaS Data Table & List View UX: Examples & Patterns (2026)
The data table is the workhorse of almost every SaaS product — the contacts list, the deals pipeline, the invoices, the users admin, the rows a team scans and acts on all day — and it is where dense information either becomes usable or becomes a wall. This guide covers the core table and list patterns, when a table beats a card or board view, and the details (column control, sticky headers, row density, inline actions, sorting, selection, pagination vs infinite scroll, empty and loading states) that decide whether a table helps people find and act on the right row — each shown with real SaaS screenshots instead of mockups.
Open almost any SaaS product and you will land on a table. The CRM opens on a list of contacts; the billing tool opens on rows of invoices; the project app opens on a list of issues; the admin console opens on a table of users. The data table is the surface where a team spends most of its time — scanning, sorting, filtering, and acting on rows — and it is the single most information-dense control most products ship. That density is exactly why tables are so easy to get wrong: cram in too many columns and every row becomes a wall of text; strip them down too far and users cannot find what they came for; forget the states around the table and a first-run account or a slow query turns the core screen into a blank, confusing void.
This guide treats the data table as a designed workspace rather than a grid of cells. It covers when a table is the right view at all, the core patterns for structuring columns and rows, how users control what they see, the actions they take on rows without leaving the list, and the supporting details — sorting, selection, pagination, empty and loading states — that separate a table people trust and work in all day from one they fight. Every one of these is easier to get right when you can see how shipped SaaS products handled it, so study real screens alongside the principles below.
A table is for scanning and comparing rows — pick it deliberately
Before designing the table, confirm the table is the right view. A data table earns its place when users need to scan many records, compare them across the same attributes, sort and filter to find a subset, and act on one or many rows — the classic list-of-things-with-shared-fields job. When the primary task is instead following a status through stages, a board or kanban view often fits better; when each record is rich and visual, a card grid reads better than rows; when there is a single record to study, a detail page beats any list. The strongest products offer a table as one of several views over the same data and let users switch, but they still design the table for its real job: fast scanning and comparison of many rows, not as a dumping ground for every possible field.
Structure columns for the scan, not for completeness
The most common table failure is treating every available field as a column. A record might have forty attributes; a useful table shows the five or six that let a user identify the row and make the next decision, and pushes the rest to the detail view or to optional columns. Lead with the column users read to recognize a row — usually a name, title, or ID — and keep it in the leftmost, often sticky, position so it stays visible as the table scrolls sideways. Order the remaining columns by how often they drive a decision, right-align numeric and currency columns so figures line up for comparison, and give status its own column with a clear visual token rather than burying it in text. The goal is a row a user can parse in one horizontal glance, not a spreadsheet export.
Let users control columns and density
Different users of the same table care about different fields, so mature tables let people choose which columns show, reorder them, and resize them — and remember that choice. Pair column control with a density toggle: a comfortable row height for reading and a compact height for power users who want more rows on screen at once. These controls turn one table into many, letting a support agent, a finance lead, and an admin each shape the same data around their own scan without the product having to guess a single perfect column set.
Keep headers and key columns in view
Long tables scroll, and the moment the header row disappears the table becomes unreadable — users cannot tell which column a value belongs to. Sticky headers that stay pinned as the body scrolls are close to mandatory for any table longer than a screen, and for wide tables a sticky first column keeps the identifying name visible while the user scrolls through secondary fields. This is a small structural detail with an outsized effect on trust: it is the difference between a table users can navigate confidently and one where they lose their place on every scroll.
Sorting and row selection are core, not extras
Two interactions turn a static grid into a working table. The first is sorting: clicking a column header to reorder rows by that field, with a clear indicator of which column is sorted and in which direction. Sorting is how users answer "which is largest, oldest, most overdue" without leaving the list, and it must be obvious which header is active. The second is selection: a checkbox per row plus a select-all in the header, so users can pick a set of rows and act on them together. Selection is the bridge from a table to bulk actions — once users can choose rows, they expect to do something with the whole set at once.
These two patterns rarely stand alone. A table users work in all day is usually a table plus a filter-and-sort layer plus a bulk-action bar, and the three are designed together: filter and sort to narrow to the right rows, select to choose them, act to change them. Treating the table as the static base and layering controlled filtering, sorting, and selection on top is what separates a report from a workspace.
Put common actions on the row
Users should be able to act on a row without opening it. The mature pattern gives each row a small set of inline actions — often revealed on hover or behind a compact overflow menu at the end of the row — for the operations people repeat constantly: open, edit, duplicate, archive, delete. Keep the one or two most common actions directly visible and tuck the rest into the overflow menu so the row stays scannable. For destructive row actions, apply the same care any dangerous operation deserves: make delete distinct from the benign actions, and prefer an undo or a confirm over an instant, silent removal, so a mis-click on a dense list does not quietly destroy a record.
Handle scale: pagination, infinite scroll, and virtualization
Tables grow, and how a product handles thousands of rows shapes the whole experience. Classic pagination — numbered pages with a clear total — gives users a sense of the data set size and a stable position they can return to, and it suits tables where people jump around and reference specific pages. Infinite scroll or a load-more control keeps users in a single continuous flow and suits exploratory scanning, but it hides the total and makes it hard to return to a spot, so pair it with strong filtering so users narrow rather than scroll forever. Under either pattern, large tables need virtualization — rendering only the visible rows — to stay fast, because a table that stutters as it scrolls feels broken no matter how good the columns are. Whichever you choose, always show where the user is: a row count, a page indicator, or a "showing X of Y" summary so the scale is never a mystery.
Design the empty and loading states, not just the full table
A table is only full for established accounts. For a brand-new user it is empty, and for everyone it is briefly loading — and those two states are where tables most often fail. An empty table should never be a bare grid with headers and no rows; it should explain what will appear here, why it matters, and offer the action that creates the first row, doubling as onboarding. A loading table should use a skeleton of placeholder rows that matches the real layout rather than a centered spinner, so the structure is visible immediately and the content settles into a shape the user already understands. Distinguish the true empty state ("no records yet") from a no-results state ("your filter matched nothing") — the first invites creating data, the second invites clearing the filter — because conflating them strands users who simply over-filtered.
The details that separate a trusted table from a frustrating one
As with most SaaS patterns, the structure is the easy part; the trust lives in the small behaviors around it. These are the details mature tables get right.
- A sticky header, and a sticky identifying column on wide tables, so users never lose which column a value belongs to as they scroll.
- Right-aligned numbers and consistent formatting, so figures line up and are instantly comparable down a column.
- A clear sort indicator showing which column and direction is active, updated the moment a header is clicked.
- Row selection with select-all, wired to a bulk-action bar, so choosing many rows and acting on them together is a first-class flow.
- Inline row actions for repeated operations, with the common one or two visible and the rest in an overflow menu, and destructive actions clearly set apart.
- A visible scale indicator — page numbers, a row count, or "showing X of Y" — so the size of the data set is never hidden.
- A skeleton loading state that mirrors the real row layout, not a spinner over a blank area.
- Distinct empty ("no data yet, here is how to add it") and no-results ("nothing matched, clear your filter") states.
- User-controlled columns and a density toggle, remembered between sessions, so each role shapes the same table around its own scan.
Common data table mistakes
- Showing every available field as a column, turning each row into an unscannable wall of text.
- No sticky header, so scrolling a long table detaches values from their column labels.
- Sorting that gives no visible indication of which column is active or in which direction.
- A spinner over a blank table instead of a skeleton that shows the coming structure.
- A bare grid with headers and no rows for new users, with no explanation or first-row action.
- Treating a no-results filter state as an empty state, so over-filtered users think their data is gone.
- Row-level actions that require opening each record, forcing users into and out of detail views for routine edits.
- Instant, silent row deletion from a dense list with no confirm or undo, making mis-clicks costly.
- Loading thousands of un-virtualized rows so the table stutters and feels broken as it scrolls.
Frequently asked questions
When should a SaaS product use a table instead of cards or a board?
Use a table when users need to scan many records that share the same fields, compare them across those fields, sort and filter to find a subset, and act on one or many rows — the classic list-of-things job like contacts, invoices, or users. Reach for a board or kanban view when the primary task is moving items through stages, a card grid when each record is visual and rich, and a detail page when there is a single record to study. The strongest products offer a table as one of several views over the same data and let users switch, but they still design the table specifically for fast scanning and comparison rather than as a catch-all for every field.
How many columns should a data table show?
Show the five or six columns that let a user identify a row and make the next decision, and push the rest to the detail view or to optional, user-enabled columns. Lead with the column people read to recognize a record — a name, title, or ID — keep it leftmost and often sticky, order the remaining columns by how often they drive a decision, and right-align numeric fields so they compare cleanly. Then let users choose, reorder, and resize columns and remember that choice, so a support agent and a finance lead can each shape the same table around their own scan instead of the product guessing one perfect set.
Should a data table use pagination or infinite scroll?
Use classic pagination when users need a sense of the total data set and a stable position they can return to or reference — numbered pages suit tables people jump around in. Use infinite scroll or a load-more control for continuous exploratory scanning, but because it hides the total and makes returning to a spot hard, pair it with strong filtering so users narrow rather than scroll forever. Under either approach, virtualize large tables so only visible rows render and scrolling stays smooth, and always show scale — a row count or "showing X of Y" — so the size of the data set is never a mystery.
How should an empty data table be designed?
Never ship a bare grid of headers with no rows. An empty table should explain what will appear here, why it matters, and offer the action that creates the first record, so it doubles as onboarding for new accounts. Keep this distinct from a no-results state: when a filter matches nothing, say so and offer to clear the filter, rather than showing the same "nothing here" message that implies the data is gone. Conflating the two strands users who simply over-filtered, while a true empty state should be pointing brand-new users toward creating their first row.
Study real SaaS data tables in the SaaSUI library
Every pattern above is easier to apply when you can see how real products solved it. Browse real data tables and list views from shipped SaaS applications in the SaaSUI.Design library — real screenshots, not mockups — to study column structure, sticky headers, row density, sorting indicators, selection and bulk-action bars, inline row actions, pagination, and empty and loading states, and see how mature products turn dense rows into a workspace teams trust.
Interested in sponsoring SaaSUI.Design? Learn about sponsorship options →