Design patterns
Data table UI design with AI: comparison, sorting and actions
Design a useful table with stable row identity, clear sorting and reviewable selection behavior. Includes a supplier-list example.
Decide what users compare across rows
A table is useful when people need to compare records along shared attributes. For an illustrative supplier list, the important columns might be supplier name, next delivery, outstanding amount and status. Put related values close enough to compare and keep their units explicit.
Start with the decisions rather than every database field. An internal identifier may be essential for support but unnecessary in the default view. Use a detail view for information that does not help the primary comparison.
Specify sorting and selection before styling
Name the default order and how users change it. Sorting a date by its formatted text can produce a misleading sequence; the implementation needs the correct underlying value. Define where missing dates go. Keep the active sort recognizable after a refresh if the product promises to preserve it.
If the table supports selection, decide whether “Select all” means the visible page or every matching record. Show enough context before a bulk action that the person can understand its scope. Stable record identity matters when sorting, filtering or refreshing changes the row order.
Plan the narrow layout around the task
A dense desktop table may need horizontal scrolling, a smaller column set or a different presentation on mobile. Choose based on which comparisons must remain possible. Converting every row into a tall card may make cross-row comparison harder.
In Taste, collect examples for headers, row actions and density. Explain which attribute relationships must survive. Keep actual column names and long supplier names in the example; short placeholders conceal wrapping and alignment problems.
An implementation brief for a supplier table
Use native table semantics for genuinely tabular data. W3C’s tables guidance explains the relationship between data cells and headers. A visually aligned collection of generic containers does not provide that structure automatically.
Implement the supplier list with name, next delivery date, outstanding amount and status. Define the default sort and missing-date behavior. Reuse existing table and action components. Use my Taste references for comparison density, not for new branding. Keep selection tied to record IDs, state the scope of Select all, and preserve filters after returning from detail. Include long names, zero amounts, unknown dates, no results and failed loading. Review the narrow layout and header semantics.
Review with a difficult dataset
Test two suppliers with identical names, a very long name, missing data and records changing while the page is open. Confirm row actions still affect the intended record after a sort. Check that amounts include enough currency context to be interpreted correctly.
A table can be visually neat and operationally dangerous if selection shifts when data changes. Verify those behaviors before tuning row height, zebra striping or hover effects.