Change Blindness
& UI Design
Usability in error messaging & other state changes.
The test results are in and I’m afraid you have Change Blindness Blindness. It’s a terrible condition. Victims suffer from an exaggerated sense of their ability to detect changes in their field of view. The good news: You are not alone. 99.999% of the world’s population suffers with you.
However, if you design websites or software for a living, Change Blindness Blindness can have serious side-effects including…
- Positioning error messages where users won’t see them.
- Inadequately communicating state changes.
- Depressed conversion rates.
- Loss of income, trouble sleeping.
With a little time and attention, you can learn to manage your condition and, more importantly, help your users better manage theirs.
Change Blindness
Experimental designs used to demonstrate change blindness have eerie similarities to common, online user experiences. First, study participants are shown a scene. Then, some kind of flash or other noise interrupts the visual field. Finally, a second scene is shown, identical to the first except for one (often glaring) change.
People are surprisingly bad at detecting even drastic changes, like entire objects (dis)appearing from the scene.
This handy demo lets you try it for yourself… http://www.gocognitive.net/demo/change-blindness
Why this happens isn’t entirely understood, but it seems to be a result of how our brains construct meaning from visual information. The interruption is crucial, whether it’s a total flash or just a few dots splashed across the screen.
It’s very much like what happens when you refresh a web page.
State Changes & User Experience
Consider what happens when you fill out a typical web form: You hit a button and some invisible process is kicked off. Your browser thinks for a few seconds, then its screen flashes white. If anything failed validation, the same page probably reappears with a new element: an error message.
As a designer, that all looks pretty obvious. You have the luxury of already knowing what’s going on, already understanding the state change you’re trying to communicate. You’re also looking at the whole page, you’re not in the middle of trying to complete task, and you didn’t have to look at it with a flash of page refresh in-between.
Even without the refresh flash, having one’s attention focused on the bottom of the page, near the submit button, will make that error message as invisible as a ninja on your ceiling. (Look up right now. If you don’t see a ninja on your ceiling… it’s already too late.)
Slow feedback on button press, long load times, and extraneous things competing for your user’s attention can all make them blind to seemingly obvious changes in state.
Fortunately, change blindness has its own blind spots.
Facilitating Change Detection
The flash is essential to causing change blindness. If the state change is instantaneous, change detection is pretty much guaranteed. To prevent the refresh flash, don’t wait until form submit to perform field validations. Whenever possible, validate client-side as the user types.
Validations that can’t be performed client-side can still be done in the background. Keep attention focused on the button location while validation is running, then display any state changes in the same general area. Transforming the button into a progress indicator is ideal.
Participants in change blindness studies are better (still not great) at detecting changes in the center of the visual field, where most of their attention is focused.
Summary
Change blindness is a serious epidemic. Changes in state that occur during a page refresh are particularly likely to escape users’ notice. To clearly communicate state changes in web forms…
- Avoid page refreshes whenever possible.
- Provide smooth, continuous feedback.
- Position new elements near the focus of attention.
