Change blindness
The interface changed, but the user never noticed because their attention was somewhere else when it happened.
See it
What it is
Change blindness is the ordinary failure to notice that something in the visual scene changed, especially when attention was elsewhere or the change arrived across a brief interruption. In Simons and Levin's 1998 door study, an experimenter asking a stranger for directions was swapped for a different person while two workers carried a door between them, and about half the strangers carried on talking without noticing. Interfaces trigger the same miss when a click quietly updates a distant badge, total, or row.
Reach for the concept whenever an action changes content outside the control being used. Keep the result near the trigger, preserve spatial continuity, and use a brief transition, highlight, or status message to lead attention from cause to effect. The cue should answer what changed, not merely announce that something happened.
The gotcha is making the cue itself another distraction. Motion helps only when it points to the meaningful change. Flashing the whole page, showing a remote toast, or animating five regions at once competes for attention and can hide the result more effectively than no animation.
Ask AI for it
Make this update resistant to change blindness. Keep the result next to the control that caused it; if the changed item is offscreen, call scrollIntoView with block: 'nearest' before cueing it. Apply a single 600ms CSS background-color transition to the changed row, keep any new value or status text visible after the color fades, and announce the same result through an aria-live='polite' region. For totals or badges, animate only the changed value and include the previous value in accessible text. Respect prefers-reduced-motion by removing movement while retaining the persistent text cue. Do not rely on a corner toast as the only evidence that the action worked.