F3.01.3relative visual weightdesignresearch

Weight is relative and meaningless out of context

Aliases: relative weight · local contrast coding · context-bound weight

What it is

The same 18 px medium-weight line “Account & security” is the heaviest type on a nearly empty settings screen, and does not even rank as a subhead beside a news homepage hero. The type size, weight and colour frozen in the component library did not change. The neighbours did. Visual weight is a relative quantity: it names the contrast of this object against whatever else is on stage, not a sticker you can peel off and carry. Copying a component to a new page and expecting the same rank treats a relative quantity as an absolute.

Why it happens

Cells that encode luminance, size and isolation perform local normalisation: the output is roughly “how much lighter / larger / more isolated than the surround,” not candelas or pixels as absolutes. In an empty surround a middling stimulus can peak; once a larger, brighter, more isolated neighbour is present, the same stimulus is pressed into background. A component spec can freeze absolutes (18 px / Medium / #1A1A1A). It cannot freeze rank after normalisation. That is why “this heading is Title 2 in the system, so it is second-level on every page” fails as perception: Title 2 is a production label, not the peak order on that frame.

Studying it

Mount the same component in at least two hosts: a sparse page (settings, empty state) and a crowded one (feed, workbench). Hold the component spec fixed, swap only neighbours, and record first naming or first fixation. The independent variable is host density and the strongest neighbour’s weight; the dependent variable is the component’s rank. Rank that moves with the host is relativity made visible. Reviewing the heading on a white component canvas measures absolute spec, not in-use weight.

Where it stops holding

Relativity is not “anything can rank anywhere.” Push the difference to the ends of the display range — near-white large type on near-black, or the reverse — and rank holds across a wide span of hosts, because no neighbour can physically outrun it. A full-screen modal temporarily clears neighbours, so a middling heading inside it suddenly feels heaviest; dismiss the modal and rank returns to the page underneath. Readers who enlarge type change absolute sizes across the page; relative order usually survives unless enlargement pushes objects out of the viewport and the neighbour set itself changes.

Applying it

  • Do not review a component only on a white canvas. Paste it into the emptiest page and the densest page and read its rank on each.
  • Reusable modules (card headers, list titles, badges) should not promise a fixed grade across pages. Promise a relative slot inside a named host.
  • When a module moves to a new host, find the current strongest object on that page first, then decide whether the module should lose weight or gain it. Do not paste unchanged.
  • Check: two screenshots, pixel-identical component, hosts an empty settings page and a dense feed. Five people write the first-look object on each. If it is first on settings and drops out of the top three on the feed, treat that as relativity: add channels on the crowded host, or accept that it is not first there. Do not file a bug against the component.

Related

  • Same group: F3.01.1 Size, luminance, colour, position and whitespace jointly set visual weight · F3.01.2 A difference on one dimension is easily cancelled by another
  • Nearby: F3.02.2 More levels compress the step between them · F3.07.1 Visual hierarchy must match content priority · F2.07 Information density
  • Search terms: relative visual weight · local contrast · centre of interest · context

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/F3.01.3