Data Table
A grid of rows and columns for scanning, comparing and acting on records — the screen most B2B users spend their day inside.
UI ComponentsA data table is not a list with lines. It is a workspace with five jobs layered on one component: scanning many records, comparing values down a column, finding a specific row, acting on one row, and acting on many. Each job pulls the design a different way, and a table built for only the first — the one that looks best in a portfolio shot — collapses the moment somebody has four thousand rows and a deadline.
The decisions that matter are unglamorous. Which columns are visible by default and can the user change that. Whether numbers are right-aligned and tabular so a column can be scanned. What happens to a 90-character string in a 200px cell. Whether sort, filter and pagination state survives a refresh and is in the URL. Whether row actions live in a menu at the end of the row or appear on hover — and what hover means on a touch screen.
Density is a real decision, not a default
Comfortable rows look better in a mockup. Compact rows let an analyst see 40 records instead of 12 and are what that user actually wants. Offer both and remember the choice. If you can only ship one, ship the dense one — the people who live in the table outrank the people evaluating a screenshot.
In practice
An ERP vendor's order table loaded all 12,000 rows and ran filtering in the browser. It took 4.5 seconds to become interactive and froze on sort. Moving sort, filter and pagination to the server and rendering 50 rows at a time dropped it to 340ms. The visual design did not change at all; users described it as “the redesign”.
Where teams get it wrong
- Filter and sort state that lives in component state, so a refresh or a shared link loses it. Put it in the URL.
- Centre-aligned numbers, or proportional figures, which makes a column impossible to scan for magnitude.
- Bulk selection with no answer for partial failure — 200 rows selected, 3 fail, and the UI says “Done”.
- Horizontal scroll with no frozen identifier column, so the user scrolls right and no longer knows which row they are on.
- Row actions only on hover, which do not exist on touch and are invisible to keyboard users.
Learn more
You may ask
Frequently Asked Questions
When should I use a data table instead of cards?
Use a table when people compare values across records — dates, amounts, statuses. Use cards when each record is consumed on its own and has an image or a long title. If a user ever asks “which of these is the biggest”, they need a table.
How many rows should a table load at once?
As many as the server can return in a few hundred milliseconds, usually 25–100, with sorting and filtering done server-side. Loading everything to filter in the browser works until the first customer with real data volume.
Should data tables use pagination or infinite scroll?
Pagination, in almost every B2B case. People need to know how many records exist, return to “the one on page 3”, and reach the footer. Infinite scroll suits browsing feeds, not working through records.
Related terms
All terms- Pagination (UI)Splitting a long list across pages with controls to move between them — the alternative to infinite scroll and load-more.
- Filter (UI)Controls that narrow a set of records — and the much harder job of keeping what was narrowed visible.
- Bulk ActionsSelecting many records and doing one thing to all of them — and designing what happens when it works for most but not all.
- Empty StateWhat a screen shows when it has no content yet — the first screen every new account sees, and usually the last one anybody designs.
Defined by Mara Last reviewed .
Let's talk about your product.
Happy to look at what you're building and say where design would move the needle.
Contact Us