I1.04.2latency as heavinessdesignresearch

Delay is perceived as interface heaviness

Aliases: sluggish UI · dull feel · perceived mass

What it is

Scroll a beat late and people rarely say “40 ms of delay”. They say the page is heavy, the slider dull, the list won’t drag. Input latency is subjectively translated into heaviness: the object feels more massive, more frictional, the machine more strained. That is perceptual attribution, not a change in physical mass. The same pixels, a longer input-to-photon time, and material judgement drops from “light” to “cheap and heavy”.

This leaf is not about how short delay must be to track. It is about the word delay is coded into once it is felt. Get the word wrong and optimisation looks in the wrong place — shadows and type weight, not frames.

Why it happens

People carry mass expectations for moving things: light things follow the hand, heavy things lag. Visual lag is everyday evidence of mass, and interfaces borrow the heuristic. Delay is therefore reported as a materials problem, not a clock problem. A second layer is effort: the hand applied force, the object moved a half-beat later, and the brain reads the remainder as “resistance still to overcome” — hence “won’t drag”.

Attribution leaks. One poorly tracking scroll can make icons on the same page look “thicker” and motion look “cheaper”, with those assets untouched. Performance is experienced as visual design; visual design takes the blame.

Studying it

Inject delay into one interface and use semantic differentials: light–heavy, fast–dull, expensive–cheap, glued-to-finger–slipping. Do not only ask “did you feel delay”; that trains people as engineers.

Independent variables: added delay, whether it comes with dropped frames, object size. Dependent variables: heaviness and related ratings, whether people can still correctly say “it was slow” rather than “it was ugly”.

When people compare “this theme” to “that theme”, delay differences are often narrated as skin differences. Shuffle the skin in the experiment or the heaviness attribution will not come apart from visual design.

Where it stops holding

Deliberate physical simulation (inertia, damping, spring) also produces lag, but it is lag inside the model, with a coherent acceleration curve. Input delay is lag outside the model, the curve does not cohere, and the heaviness feels dirtier. Users on low-end devices may blame “this machine”, not the app; the same app suddenly heavy on a flagship is when attribution hits the product. Lengthened animation (a 300 ms ease) is a design choice and is read as “unhurried” rather than “heavy” — provided the gesture itself already tracked, and the ease runs only after lift-off.

Applying it

  • Treat “heavy / dull / won’t drag” as a latency signal, not a brief to increase visual weight.
  • When tracking is poor, do not “support” the motion with heavier shadows or thicker strokes; that writes the wrong attribution into the skin.
  • Inertia and friction of a physical scroll can be designed, but while the finger is down the object must stick to it. Inertia starts after lift-off.
  • How to check: same skin, two devices, one with 50–80 ms of injected input delay. Listen to the words. If they are heavy, dull, stuck — not “I dislike this theme” — delay has been coded as mass. Remove the delay and listen again; the words should walk back.

Related

  • Same group: I1.04.1 Drag-follow latency thresholds sit far below click response · I1.04.3 First-input delay and steady-state delay must be measured separately
  • Nearby: I1.05 Latency jitter · I4.09 Tempo and interaction rhythm
  • Search terms: perceived heaviness · sluggish UI · input lag

Cards in the same group

Quick Actions

Share

Share this page

ios_share

https://hci.top/en/handbook/I1.04.2