Discrete UI refresh without a transition causes changes to be missed
Aliases: hard cut · state-driven re-render
What it is
The default way interfaces render is a discrete state swap — the old state is simply replaced by the new one, with no frames in between. This "hard cut" is functionally identical to the blank frame inserted in the classic change-blindness flicker paradigm: no blink or saccade is needed, because there is no continuous imagery across the change for the automatic orienting signal to latch onto in the first place — it never existed.
This makes a transition-free UI refresh the single most common trigger of change blindness in real products, more common than any physiological interruption like a blink or saccade — it happens on every re-render, regardless of what the user's eyes are doing at that moment.
Why it happens
Declarative UI frameworks, and most state-driven rendering pipelines, work by default like this: take the new state, recompute the visual output, replace the old presentation. There is no interpolation built into this process — unless a developer explicitly calls an animation or transition API, no frame exists between the old value and the new one. Real-time data updates (a websocket push, a polling refresh) follow the same pattern: a number jumps straight from 100 to 105, with no counting animation.
Because this is the pipeline's default behavior, not an occasional exception, it occurs in real products far more often than any single physiological interruption ever would. Every state update is a potential change-blindness trigger, whether or not the user's attention happens to be on that region at the time.
Where it stops holding
- This only covers state updates that lack interpolation. If a framework or component ships its own transition (list animations, route transitions in most modern UI libraries), the motion signal is still present and this entry does not apply.
- When an update happens outside the user's field of view (scrolled out of sight, a backgrounded tab), the failure mode becomes "not looking at all" — that is inattentional blindness, not the change blindness discussed here.
- High-frequency, small-magnitude updates (a counter ticking every second) may still let the user gradually perceive the trend through repeated exposure even without a transition. This entry describes a single, discrete, low-frequency state jump, not a continuously incrementing number.
Applying it
- Audit every "data changes, the UI changes immediately" path in the product: list re-sorting, results replaced after a filter is applied, a background push overwriting a currently displayed value, cross-device sync overwriting local state, pagination swapping results — these are the hotspots for transition-free refresh. List them explicitly rather than assuming "page refresh" is the only case.
- Prioritize auditing updates the user did not trigger themselves (background pushes, cross-device sync): a refresh the user triggered by clicking at least carries their own intent as a cue; a passively received update carries no warning at all, so it is the higher-risk case.
- Make "does this update have a transition" a pre-launch checklist item in code review or design handoff, rather than something left for motion design to patch after the fact.
- Verification: list every state-update trigger path in the product and mark which ones are hard cuts and which have a transition. The hard-cut list is the candidate list for change blindness — go through it and judge whether each change matters enough to the user that it needs to be guaranteed visible.