Hierarchy is carried by visual weight rather than position

What it is

Which button is primary is read from visual weight—fill, contrast, saturation, type weight—not from sitting on the left or right, top or bottom. Position answers where the hand reaches and where the eye enters; weight answers which action is encouraged. Parking a primary in the lower right while rendering it as an outline twin of Cancel does not express a recommendation. Conversely, a filled high-contrast control remains primary even if platform convention places it on the left.

Why it happens

In a scan, position supplies an entry; weight supplies a place to stop. High-contrast mass attracts the eye, after which nearby controls are parsed as companions. That path is not the same as left-to-right reading: a left-start writing system makes the left side seen first, but does not promote the left control to “the” action. If a product encodes importance as position (“the right-hand one is primary”), the code reverses when another platform puts confirm on the left or a narrow layout stacks the pair. Weight travels: fill versus outline, high versus low contrast, still points at the same role after a left-right swap, a vertical stack, or RTL. Position should cut pointing cost and match platform convention; it should not quietly carry the meaning “this is the recommendation.”

Studying it

Swap layouts: one pair distinguishes confirm/cancel by fill while following platform order; another pair looks identical and marks primacy only by left/right or top/bottom. Add RTL and stacked conditions.

Independent variables: presence of a weight difference, whether position matches the user’s everyday OS, writing direction. Dependent variables: wrong-choice rate, time, and reports such as “I hit the right-hand one so it should be correct.”

Measuring position coding only in Windows-native or only in macOS-native samples inflates the position effect. Cross-platform sampling, or pretesting each person’s confirm-button habit, is what separates position from weight.

Where it stops holding

Reach cost still belongs to position: a phone’s bottom is easier than its top. That fact is not about which control is primary, and weight cannot excuse a key the thumb cannot reach. Extreme size can briefly beat weak weight—a huge outlined control on the left will be hit before a tiny filled one at the lower right, because size is itself weight. The failure is an insufficient weight gap, not a duty to ignore position. Gamepads and TV focus navigation mark the current item with a focus frame rather than fill; the hierarchy channel is focus, not button mass.

Applying it

• Mark the primary with fill, contrast, and type weight. Use position for platform confirm/cancel order and thumb reach, not as the sole cue for primacy.
• Check RTL, stacked narrow, and desktop row variants: the primary must remain the heaviest control under all three placements.
• Do not patch weak styling with copy that says “the one on the right submits.”
• Verify by swapping the pair left-right and top-bottom. With position memory blocked, people should still name the high-weight control as the one that actually submits, not “whichever sits on the right.”

Related

• Within the group: E1.01.1 A view should contain only one primary button · E1.01.2 Secondary and text buttons carry parallel and exit actions · E1.01.4 Several equal-weight buttons erase the recommended path
• Adjacent: F3.09 Position and hierarchy · E1.10 Button order · E1.18 Button order and platform conventions
• Search terms: visual weight · button hierarchy · visual prominence