Row height trades viewport comparison against how hard a row is to hit

What it is

The vertical size of a list row does two jobs at once: it decides how many items can be seen together, and how easy that item is to hit. The list-row height tradeoff is those two forces pulling on the same pixels. Taller rows are kinder to a thumb and shrink the set of neighbours that can be compared without scrolling. Shorter rows raise the count on screen and raise the chance of missing, or hitting the row next door. Density here is not a visual mood. It is a comparison window competing with a hit window.

Why it happens

Visual comparison wants candidates on stage at the same time. Choosing which mail is newer, or which contact fits, needs the rivals inside one glance; anything scrolled away has to be held in working memory, which runs out fast. Each extra line of height shrinks the candidate set in the viewport, and comparison turns from a glance into “remember, then scroll back.” Hitting the row is a different path: height enters Fitts's law as target width, so a short row costs more time and produces more neighbour errors. On a touchscreen the finger’s contact ellipse is often taller than a compact row, so the system inflates the hit region into the gap and two rows start to share a border. A mouse can live with denser rows; a thumb cannot inherit that density.

Studying it

Give the same roster two tasks: find items that match several attributes (needs on-screen comparison) and tap a sequence of named rows (needs pointing). Vary row height and record accuracy, scroll count, neighbour errors, and time. Independent variables: row height, device (mouse versus thumb), whether identifying fields repeat. Dependent variables: visible set size, mis-selection, scroll amplitude. Eye tracking shows whether comparison finished inside the viewport or rode on back-and-forth scrolling. A rating of “looks cramped” is not a substitute — cramped, failed comparison, and wrong taps are different events.

Where it stops holding

Queues that are barely compared (a playlist tapped in order) tolerate tall rows; admin lists that combine attributes across dozens of items starve without on-screen count. Keyboard users move with arrow keys, so height barely changes pointing precision, but it still changes how much context a glance holds. Dynamic type can turn a once-tappable row into two wrapped lines plus a truncation, so the task shifts from “which row” to “is this still the same item.” A landscape or unfolded screen suddenly enlarges the comparison window for the same row height, and a density chosen for a short portrait viewport looks empty.

Applying it

• Choose height from the task: lists whose job is compare-and-filter should keep a comparable set on screen; lists whose job is open-one-item can grow until they are comfortable to hit.
• On touch, build hit height into the row structure; do not add visual padding that lets two hit regions overlap.
• If the product offers comfortable versus compact density, measure errors and scrolling at each stop rather than scaling one layout.
• How to check: on the target device, run “find the row that matches two attributes among twenty” and “tap ten named rows in a row.” Too much scrolling on the first task means shorten; neighbour misses on the second mean grow.

Related

• Within the group: E4.02.2 Put the identifying information on the first line and do not truncate it · E4.02.3 Priority between row actions and a whole-row click must be explicit
• Adjacent: E4.05 Inline and bulk actions · E4.18 Virtualized long lists · E1.07 Button hit targets
• Search terms: row height · information density · Fitts's law