Flow follows the weight sequence, not positional order

What it is

A sign-up row lays out email, password, create-account left to right, and the designer treats that positional order as the flow. The right half holds a product illustration larger than any of the three controls. In a five-second test the first thing written down is often the illustration; the form trails. Flow is the visit sequence ranked by weight, not sequence on the grid. Positional order becomes the default path only when the blocks are close in weight. Treating “left to right / top to bottom” as a finished flow mistakes a weak default for an outcome.

Why it happens

Attention repeatedly picks the currently heaviest object that has not yet been processed enough. The sequence is therefore visits in descending weight, plus a little proximity stickiness: a slightly lighter neighbour near the current fixation can cut in. Positional order (source order, grid numbering) does not enter that choice unless you deliberately let position contribute weight (start side, top). The illustration wins on size, detail density, often saturation; it is item one in the sequence, and the email field waits even if it is first in source order. Flow can be designed. The method is ranking weight, not writing “the user will proceed left to right” in a note.

Studying it

Have the designer mark a hoped-for 1-2-3 on the comp, then collect actual sequence from five-second writing or eye tracking, and count inversions between the two. The independent variable is which object is artificially weighted (larger illustration, more saturated button, larger title); the dependent is whether inversions rise with that object’s weight. If the hoped-for sequence is positional and the actual sequence is by weight, the position hypothesis for flow is falsified. Do not substitute task success for sequence — the task can complete with the flow still reversed.

Where it stops holding

A strong task goal (“I came here to change my password”) lets people hunt controls from memory and the weight sequence is overwritten by a task schema. Keyboard tab order is not visual flow: assistive tech follows source order, sighted pointer users follow weight. Motion that ramps an object from zero to high weight reroutes flow in time, and a still comp’s predicted sequence goes stale. On a sparse page with no illustration, position and weight often coincide, which breeds the illusion that position is flow. That is uniform weight, not a different mechanism.

Applying it

• Write the weight sequence before layout: which object is first look, second, third. Then implement that sequence with size, luminance and isolation. Position is a weak assistant.
• If a large illustration, wordmark or decorative motion is not item one, drop its size or contrast below the task objects. Do not add a line that says “please fill in the left first.”
• Keep source order aligned with the task for keyboard and assistive tech. Do not assume it will pull gaze.
• Check: write the hoped-for 1-2-3 on paper. People who have not seen the file look for three seconds and write three names in the order they saw them. More than one inversion: lower the actual first’s weight or raise the hoped-for first’s, until the written sequence matches the paper. Do not move the illustration to a “more left-to-right” slot at the same size — it will usually remain first.

Related

• Same group: F3.05.2 Equal-weight foci fork the flow · F3.05.3 Flow should match the order of the task
• Nearby: F3.04.2 Structured pages are scanned by jumping to visual weight · F3.09.2 Positional rank can be overwritten by stronger visual weight · F2.14 Content-first layout order
• Search terms: visual flow · visual weight · centre of interest · scanpath