UI Design · Layout

Card vs. Table vs. List: Choosing the Right Layout for the Data You Have

The layout question isn't a style preference — it's a question about how many attributes users need to compare across items at once.

Jaymin Maheta 6 Mar 2026 7 min read

Share:

Dashboard showing card and table layout options

The real question is attribute count, not aesthetics

Teams often pick a layout because it "looks modern" (cards) or "looks serious" (tables), and only discover the mismatch once real data and real comparison tasks show up. The actual decision variable is simpler: how many attributes does a user need to compare across multiple items at the same time, and how many items are they looking at?

Get that answer first, and the right layout becomes close to obvious.

A working framework for the choice

Tables: many attributes, many items, real comparison

Five-plus columns of data users sort, filter and compare across dozens of rows — an invoice list, a staff roster. Tables are the only layout built for that kind of side-by-side comparison.

Cards: few attributes, visual identity matters

A handful of fields per item, where an image, color or visual identity is part of what the user is recognizing — a client roster with logos, a document library with previews. Cards give that visual weight room to matter.

Lists: sequence and single-attribute focus

A notification feed, an activity log, a simple task list — one primary attribute per item, order matters more than side-by-side comparison. Lists are the leanest layout for that shape of data.

Cards on mobile, tables on desktop, same data

A responsive strategy that switches layout by viewport — not just reflowing the same table — respects that comparison tasks genuinely change shape on a small screen.

Don't force a table into a card, or a card into a table

A "card" that's really eight labeled fields stacked vertically is a table wearing a costume — genuinely harder to scan than the table it's avoiding. If it needs a table's structure, use a table.

Let users choose when both are genuinely valid

Some data genuinely supports either view depending on the task — a document library browsed visually vs. sorted by date. A toggle between card and table view serves both without forcing a compromise.

Ask the comparison question before the visual question

Before opening a design tool, write down: how many attributes, how many items typically shown at once, and does the user compare across items or just scan sequentially? Those three answers point to card, table or list far more reliably than "what would look good here" — and they prevent the expensive rebuild that happens when a card grid meets a user who actually needed to sort by six columns.

The takeaway

Tables for many attributes and real cross-item comparison; cards for few attributes where visual identity matters; lists for sequence and single-attribute focus. Answer the comparison question — how many attributes, how many items, compared or scanned — before the visual one, and the right layout becomes close to obvious.

Let's talk about your product