A table is a surface for comparing attributes, not for reading a single record

What it is

A table lines the same attributes of many records into rows and columns so the eye can compare down a column and assemble one object across a row. It is a comparison surface, not a layout for browsing a single story. The question it answers is which row is larger, newer, or more expensive on this column — not whether this record reads well. Stuffing content that should be read as a piece (an article, a thread, a product story) into a grid does not borrow the alignment advantage; it only slices a narrative into cells that are hard to read.

Why it happens

Comparison lives on alignment. When one attribute shares a column, a unit, and a decimal place, differences are seen as position rather than read as text — once the high digits line up, the standout row is almost preattentive. Lists and cards make each object its own block, so comparison is a memory match between blocks, and working memory fills up as attributes accumulate. A table turns that match into spatial alignment, at the cost of immersive reading: cells break sentences and row height compresses, so story-shaped content has nowhere to sit. “Pick a machine whose memory and price both fit” is a table task. “Understand this review” is a card or detail task. Using the wrong container is not a style mistake; it is putting the comparison channel and the reading channel on each other’s jobs.

Studying it

Present the same dataset as a table, a card stream, and a master-detail, then run two tasks: compare a named attribute across records, and read one record and recall the point. Independent variables: number of attributes, number of records, whether attributes are alignable numbers. Dependent variables: comparison accuracy, time, recall completeness, scrolls and jumps. If comparison is faster on the table and reading is worse on the table, the container-task match is measured. “Looks professional” is not a reason to use a table; that is a style preference, not a comparison advantage.

Where it stops holding

With one or two records and few attributes, alignment has not started to pay, and the header and grid are empty overhead. Timelines, conversations, and step-by-step procedures have a serial structure that a table will break. On a phone, a few extra columns shatter the comparison surface with horizontal scrolling, and the table’s advantage may not survive — that is a different problem of restructuring. Experts who live in one sheet remember column positions as muscle memory, so the table also becomes navigation; a newcomer facing twenty columns may lose the comparison gain to locating cost.

Applying it

• Write the user’s question. If it contains “which row is more … on this attribute,” use a table. If it is “what is this record,” do not.
• Make columns only of attributes that will actually be compared. Put long descriptive prose in an expanded row or a detail, not in a column that cannot align.
• When both comparison and reading are required, use master-detail: the table compares, the pane reads. Do not force reading into cells.
• How to check: time real tasks. If comparison still requires opening every row, the table is idle. If reading requires stitching cells sideways to recover a sentence, the content should not be in a table.

Related

• Within the group: E4.03.2 Right-align numeric columns and left-align text columns · E4.03.3 Column width should follow the type of content · E4.03.4 Narrow viewports need a restructured table, not a uniform scale
• Adjacent: E4.01 Cards · E4.02 List items · E4.08 Split views and master-detail
• Search terms: data table · attribute comparison · information layout