Designing Data Tables: The Unglamorous Workhorse of Product UI
Nobody puts a data table on their portfolio cover. Tables are dense, constrained and stubbornly resistant to visual flair — and yet, in B2B software, admin panels and internal tools, they're where users spend most of their working hours. A well-designed table can make a support agent, an accountant or an operations manager measurably faster every single day; a bad one generates a steady drip of errors and frustration. Table design rewards rigour over inspiration, and it deserves far more craft than it usually gets.
Start With the Job, Not the Data
The most common table mistake happens before any pixels: dumping every available column onto the screen because the data exists. Users come to tables with jobs — find a specific record, compare a few items, spot outliers, work through a queue. Each job implies different priorities.
Interview or observe before designing. If users mostly look up a single order by number, search and a strong detail view matter more than column count. If they scan for anomalies, sorting and visual emphasis on the deviant values matter most. Choose a default column set that serves the primary job, and let users add the long tail of columns through a column picker. A table with nine thoughtful columns and customisation beats one with twenty-three that requires horizontal scrolling to see the status field.
Alignment, Formatting and the Craft of Scannability
Small typographic decisions compound across ten thousand cells:
- Right-align numbers and give them tabular (fixed-width) figures, so magnitudes line up and comparison happens at a glance. Left-aligned or proportionally spaced numbers turn every comparison into arithmetic.
- Left-align text, including headers, matching their columns' content alignment.
- Format for the scan. Show "2.4M" where precision doesn't matter and 2,412,384 where it does; render dates consistently and consider relative forms ("3 hours ago") for recency-driven work.
- Don't over-ink. Zebra striping, vertical rules, horizontal rules and cell borders are all separators; using them all at once buries the data in scaffolding. Generous row spacing plus subtle horizontal dividers is usually enough. Density should fit the audience — expert daily users generally want more rows per screen than designers first assume.
Status columns benefit from redundancy: colour plus a label or icon shape, never colour alone, both for colour-blind users and for anyone printing or screenshotting.
Interaction: Sorting, Filtering, Selecting
A table's interactive layer is where designs most often fray. Sorting should be available on any column where it's meaningful, with a visible indicator of the current sort — users routinely misread tables because they didn't notice an old sort was active. Filtering deserves prominent, persistent display of active filters; the classic support ticket "my data disappeared" is usually a forgotten filter.
Row-level actions raise a layout question with a reliable answer: keep the one or two most frequent actions visible (or revealed on hover with a keyboard-accessible fallback), and fold the rest into an overflow menu. Bulk operations need checkboxes, a select-all that's explicit about scope ("all 50 on this page" versus "all 3,214 matching"), and a persistent action bar showing what's selected.
For large datasets, pagination versus infinite scroll isn't a matter of taste. Work tables — where users need position, return trips and a sense of completeness — favour pagination or virtualised scrolling with a scrollbar that reflects true size. Infinite scroll suits feeds, not queues.
Responsive Tables: The Honest Options
Tables hate small screens, and pretending otherwise produces the worst outcomes. The honest strategies are: prioritise columns and hide the rest behind a row-expand; reflow each row into a card with labelled values; keep a key column pinned and let the rest scroll horizontally with a clear affordance; or accept that some workflows are desktop workflows and design the mobile experience around lookup and approval rather than full manipulation. What never works is shrinking a twelve-column grid until every cell truncates into "Lo...".
The States Nobody Designs
A table isn't done when the happy path looks good. It needs a loading state (skeleton rows beat spinners for perceived speed), an empty state that distinguishes "no data yet" from "nothing matches your filters" — the two need entirely different messages and actions — an error state with a retry, and sensible handling of extremes: the 400-character product name, the row with every field missing, the user with 80,000 records. Test with production-shaped data early; lorem ipsum tables have a perfect record of hiding real problems.
Conclusion
Data tables are where design's quieter virtues — hierarchy, typography, consistency, restraint — earn their keep hour after hour. Learn the job the table serves, sweat the alignment and formatting, make the interactive layer legible, and design the unhappy states with the same seriousness as the demo screenshot. Your users won't call the result beautiful. They'll call it fast, and in a working tool, that's the higher compliment.