Detail-reading information belongs at the expected fixation point, change cues belong where periphery can reach them
Aliases: foveal placement · peripheral placement
What it is
Interface content splits into two kinds based on which visual capability it needs. One kind must be read clearly — text, icon detail, a precise value — and can only be processed where the fovea reaches. The other only needs to be noticed — a new message, a status change — and works fine even sitting in peripheral vision. This is a layout rule: put the first kind where the user is expected to fixate, and put the second kind somewhere peripheral vision can cover without requiring the user to look straight at it.
This is not a new capability finding; it directly translates two already-established boundaries — the fovea is strong at identification but weak at coverage, and the periphery is strong at detection but weak at identification — into a judgment about what content goes where.
Why it happens
Violating this rule wastes effort in two directions. Forcing content that needs precise identification into a peripheral position (putting a key value in a screen corner and expecting a glance to register it) fails outright because peripheral resolution is insufficient — the user must redirect their gaze to actually read it, effectively creating an extra eye-movement cost that was never budgeted for. Conversely, styling a status cue that only needs to be noticed as something that requires direct fixation to spot (buried among dense text, with no feature peripheral vision can pick up) means it goes unnoticed until the user happens to scan that exact spot — throwing away the free detection capability peripheral vision could have provided.
Both wastes share the same root cause: deciding "where on screen does this go" separately from "what level of visual processing does this need," when the two must actually be matched. Placement should follow from first working out whether a piece of information genuinely needs foveal identification, or only peripheral detection.
Where it stops holding
- Both needs can coexist in a single piece of information: a notification both needs "to be noticed as new" and eventually "to be read in full." The correct approach here is a two-layer design — a peripherally-discriminable salient feature (icon, colour block, motion) handles the noticing layer, and once the user shifts their gaze, nearby text at the expected fixation point handles the reading layer. No single visual element should be expected to satisfy both requirements at once.
- "Expected fixation point" changes with the task; it is not a fixed screen coordinate. In reading tasks it advances along the line of text; in editing tasks it tends to hover near the cursor. Different regions of an interface serve different tasks, and assuming "the centre is always the most important spot" will misjudge where the real expected fixation point is.
- This entry only covers the typical case of a single user in a single session. If the same interface is shared across task modes (a dashboard used both by someone doing focused work and someone monitoring it peripherally), the expected fixation point drifts by mode and needs separate designs rather than a compromise position.
Applying it
- List every piece of information on the interface, decide first whether it needs "identification" or only "noticing," and only then decide placement — rather than laying out the composition first and fitting content into it afterward.
- Content that needs identification (values, body text, states that must be judged correct or wrong) belongs near the user's current expected fixation point, with font size and contrast checked against visual-acuity discriminability standards — never assume "the user will lean in anyway."
- Content that only needs noticing (a new-message cue, background task completion, a non-urgent status change) belongs where peripheral vision can reach it, given a feature peripheral vision can actually pick up (shape outline, colour block, positional change) — don't require the user to deliberately scan over to find it.
- Split information that needs both into two layers: a peripheral layer that lets the user know something happened, and an identification layer that presents the actual content once the user looks over — the two can be different states of the same component (a collapsed badge versus its expanded detail).
- How to check: test separately whether users can notice that the information exists without looking directly at it (peripheral detectability), and whether users who do look directly at it can read it within the expected time (identification feasibility). Verify the two independently — don't use a single test to render a blanket judgment on "is this piece of information well designed."
Related
- Same group: A1.02.1 The fovea delivers high resolution but covers a tiny angle · A1.02.3 Periphery can signal presence but not convey detail · A1.02.5 Foveal and peripheral vision cooperate in natural viewing through a "peripheral detection, foveal confirmation" two-stage process
- Nearby: A1.01.3 Interface elements outside the effective field of view require an eye or head movement
- Search terms:
foveal placement·peripheral placement·information layout·glanceable
Cards in the same group
- A1.02.1The fovea delivers high resolution but covers a tiny angle
- A1.02.2Peripheral vision has low resolution but is sensitive to motion and luminance change
- A1.02.3Periphery can signal presence but not convey detail
- A1.02.4Peripheral flicker forcibly captures attention
- A1.02.5Foveal and peripheral vision cooperate in natural viewing through a "peripheral detection, foveal confirmation" two-stage process
- A1.02.7Requiring central and peripheral vision to monitor two independent streams creates resource competition
- A1.02.8A slow peripheral change is easily missed entirely after prolonged fixation on one point