Priority between row actions and a whole-row click must be explicit

What it is

A list row often offers two families of action at once: tap the empty part of the row to open, and use trailing controls to delete, pin, or overflow. Row-action versus row-open precedence is not about how the hit regions are drawn. It is about which task the row treats as default. Someone who came to open and instead pinned, or who came to process items and is sent into detail every time, is meeting an undeclared default. Nested clicks on a card are a geometry problem. On a list row the problem is a template-level promise, repeated on every row.

Why it happens

A list is a repeating template. After two or three rows, people freeze “tap here, this happens” into a habit and stop reading icons. If the row is painted as one clickable surface, trailing icons read as decoration. If trailing buttons are high-contrast chips, the whole-row promise is ignored. Swipe-to-reveal moves processing onto a gesture channel so that a tap can remain “open”; if tap and swipe both open, the inline buttons become a dead zone. Selection mode has to retarget the whole promise: once checkboxes appear, a tap should select, not open, or a bulk task is interrupted by detail pages. A screen reader walks controls in order; if “open” and “delete” are not named with a primary, the first link becomes the default even when the visual default was the row.

Studying it

Give the same list three precedence schemes — tap opens, tap selects, tap does nothing and only buttons act — and run two tasks: find and read a detail, and mark three rows processed. Record wrong actions, task switches, and whether errors drop after the third screen (habit formation). Independent variables: default action, number of trailing buttons, presence of selection mode. Dependent variables: hit rate for the intended action, returns from detail to finish the action. Asking “what did you think tapping the empty part would do?” exposes the promise better than a satisfaction score.

Where it stops holding

A read-only list with no row actions has no precedence problem. On desktop, hover-revealed trailing buttons keep the second family off-stage during still scanning, so the two habits are staggered in time and clash less. Touch has no hover; both families are present and precedence is harder. Switch and voice access have no “tap the empty part”; every action is named, so precedence must live in the names, not in position.

Applying it

• Write one default sentence per list: “tap row = open / select / do nothing.” Selection mode must rewrite that sentence and change the row’s appearance.
• Keep only one or two inline actions that do not fight the default; park the rest in overflow or in the detail so three peer buttons are not competing on the same row.
• Split channels: tap opens, swipe processes, or the reverse — but do not put open and process on the same channel.
• How to check: without briefing, ask someone to process five rows and open five. Count first-action errors. Test each list template; inbox habits do not transfer to a settings list.

Related

• Within the group: E4.02.1 Row height trades viewport comparison against how hard a row is to hit · E4.02.2 Put the identifying information on the first line and do not truncate it
• Adjacent: E4.01 Cards · E4.05 Inline and bulk actions · E1.08 Links versus buttons
• Search terms: row actions · default action · list item click