Change Blindness & UI Design
By: Dan Bayn
Tags: Usability, Psychology, User Experience

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.

From Supplementary Information for ‘Change blindness as a result of mudsplashes.” Used here without permission.

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.

Something like this.

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.

What your users see or, more accurately, don’t see.

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.

If you’ve used the internet since 2005, this should feel familiar.

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.

A less conventional approach.

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…