Change blindness in interfaces

Your visual system doesn't hold a copy of the screen. It holds a sparse summary plus the ability to look again, and it relies on motion to tell it where looking again is worth the trouble.

A change that happens while you're watching produces a transient: a local burst of motion energy that pulls attention to itself automatically. Remove the transient and the change has to be found by search instead, one element at a time, against a memory that was never detailed enough for the comparison.

The panel below alternates between two versions. One tile differs.

Start on flicker. A blank frame of about 110ms sits between the versions, which is short enough that it doesn't read as an interruption and long enough to swamp the local transient with a global one. Most people take several seconds. Some take considerably longer while looking straight at the tile that's changing.

Now run direct. Same two versions, same alternation rate, no blank. The change announces itself immediately, because now it's the only thing moving.

Then run animated, where the change transitions over 200ms while remaining visible.

The blank is doing all the work

This is the flicker paradigm, from Rensink, O'Regan and Clark's work in the late nineties. The finding that made it notable is how large the changes can be while remaining invisible: objects appearing, colors inverting, entire regions of a scene swapping, all missed for tens of seconds by observers actively hunting for them.

Nothing is wrong with the observer's vision. The blank frame produces transients everywhere at once, so the one transient that carries information is no longer distinguishable from the rest. Without a signal saying where to look, the only strategy left is to check each object in turn, and the checking is limited by how much detail you retained about each one, which is not much.

Both versions at once, no alternation, and the difference is found in a second or two. Nothing about the change got easier. The comparison became simultaneous rather than sequential, so it stopped depending on memory.

Where interfaces produce their own blank frames

The blank frame in the demo is artificial. Interfaces generate equivalents constantly.

• Navigation. Any full-page transition is a blank frame. A value that differs between the page you left and the page you arrived at will not be noticed.
• Loading states. A skeleton replacing content and then content replacing the skeleton is two global transients wrapped around whatever actually changed.
• Scroll. Content moving out and back in is a large-scale transient that masks small changes inside it.
• Anything off-screen. A change to a section the user has scrolled past has no transient at all, because there's nothing to see it.
• The user blinking or saccading. You don't control these and they're happening constantly.

Which means "we updated the value, the user can see it" is not a supported claim in most of the situations where you'd want to make it.

What this justifies

Motion on state change is the main one, and this is the mechanism behind it. A 200ms transition on a value that changed supplies the transient that tells the visual system where to look, replacing the one you destroyed by re-rendering.

That gives a rule for which changes deserve animation: changes the user did not initiate. A value they just typed needs nothing, because attention is already there. A value that changed because a websocket delivered something, or because a background refresh completed, or because another user acted, has no attention on it and no transient unless you supply one.

Optimistic UI is worth checking against this too. The whole point is that the change appears instantly, and instant frequently means within the same frame as the click, which produces no perceptible transient at the moment the user's attention is on their pointer rather than on the thing that updated. That's a case where the fast path is the invisible one.

Toasts sit at the far end of the problem. A notification in a screen corner, appearing while the user is reading the center, is a transient in the periphery, which is the one part of the visual field that is good at detecting motion. That's why they work at all. It's also why a toast that fades in slowly works considerably worse than one that appears with a snap, and why a toast that appears during a page transition may as well not have.

Testing for it

You can't check this by looking at your own interface, because you know where the change is and your attention goes there directly.

The usable version is to have someone else drive while you change something, or to record a session and watch whether the user's next action indicates they noticed. The signal to look for is a user repeating an action they already completed. That usually means the confirmation of the first attempt arrived without a transient, and they never saw it.