Have you ever tried justifying hiring an artist for a project? In this age of the Internet and nearly limitless clip art, it can be daunting to ask for more money to create one-off imagery for your app or site. Why should you purchase bespoke images for your project?

Remember “Who Framed Roger Rabbit?” In that 1988 movie, Roger Rabbit hires Eddie Valiant, a real world private detective, for a job in Toontown. While the groundbreaking interaction between the live and animated characters was visually compelling, the styles clashed. The toons were overly bright, flattened and followed different rules of physics than the real-world characters.

When you mix clip art styles, you get much the same effect, without the wonder and enjoyment. Flat active tabs next to overly rendered, gradient tabs with shadows look like an obvious mistake. Icons with flat graphics interspersed with images drawn with perspective lend different meanings to the buttons that are unintended. Even things like using solid silhouettes for your icons along with outlines is setting you up for misunderstanding. People will always assign meaning to their cognitive dissonance, and usually their mental models have little or nothing to do with the developers’ intent.

Spending the time or money to have a consistent look and feel to your interface provides the polish and experience that allows the interface to fade into the background and the activity to come to the forefront for the user.

For more information on mental models, check out my blog entry about superstitious users.

An analogy that caught the industry interest recently is a comparison of IT delivery styles with how we treat pets versus cattle.*  In a nutshell:

  • Pets are owned in small numbers, uniquely named, hand reared and lovingly cared for — they are, by all considerations, members of the family. When they get ill, you nurse them back to health.
  • Cattle are owned in large numbers, tagged using a standard system, identical, managed in herds, and bought and sold as a commodity — they are, in effect, food. When one gets ill, you replace it with another one.
  • Many traditional IT departments are pet owners. Servers and applications are designed from an enterprise perspective — services are tightly coupled, relying on scale-up systems and relational databases. They are lovingly and expensively cared for, with great attention and affection.
  • Modern commodity server users are cattle ranchers. Applications are designed to require little maintenance, to handle failure and to scale out. Services are loosely coupled and stateless. If a server fails it is easier to replace than fix — there is no emotional attachment.  Moving from pet owners to cattle ranchers would allow us to be more nimble and focus our efforts more on writing application code that makes us different.

I was feeling pretty good about myself for proposing moving to commodity servers, until I realized I am guilty of the same thing.

The menu itself is nothing new; sidebar menus with links to various parts of an app/site have been used since the early web (and probably elsewhere perhaps earlier still) to provide contextually relevant navigation. Also, buttons that toggle hidden content or optionally allow dragging to reveal content have also existed for much longer than touchscreen smartphones; the drawer in older versions of QuickTime Player and OS X’s color picker swatch drawer are good examples of this.

The patterns and terminology are getting muddied lately. After going through designer idea books, the iOS and Android guidelines, there is no consistency in behavior is lacking. I will attempt to describe each of the relevant patterns and proscribe their use.

The internet is full of stories of a website making what they consider a small change, only to have their user base revolt, often leading to rolling back the changes.  Facebook is often attacked whenever they make any change to their timeline, layout, or even their logo.  While these changes are noticed and talked about ad nauseum, I recently read an article by Kathryn Whitenton from the Nielsen Norman Group about Change Blindness, which is the other end of the spectrum. 

 

 

But first, a magic trick:

Choose your card 

Mentally, select a card and concentrate real hard on it…

Don’t click on it or even point at it though…let’s keep this difficult…


 

Your card is gone!

Your card is gone! 

I removed your card! Amazing! Astounding! Magical!

Actually, none of the above. I took advantage of change blindness.

 

Change blindness is the tendency of people to overlook alterations in images, especially when those changes appear immediately after a visual interruption such as a flickering screen.  If your website reloads when the user clicks a button, a change to the menu, a notification or a secondary option can be easily overlooked.  If those changes are important to the user in performing the task, that change blindness can severely impact your user experience.

The factors that impact this effect are proximity to the user’s fixation point, interruption of our visual perception and speed.

  • Proximity – As the user works his or her way through the site, their fixation point moves.  If the change you make is in the menu, the header, or a notification that is away from where the user is focused, or worse yet, off screen, the chance of the change being noticed is low. I purposely moved the link to click away from the cards to increase that distance.
  • Interruption of visual perception – your vision is interrupted when a page reloads, when we blink, when our eyes are quickly jumping from one fixation point to another, or when a screen display shifts as a device reorients from vertical to horizontal presentation. I took advantage of the screen change to interrupt your visual perception.
  • Speed – Fast changes in visual details are more likely to be missed by even brief interruptions. The blink of an eye is typically 300-400 milliseconds; change blindness has been observed when an image is interrupted for just 67 milliseconds. With the refresh, the change was nearly instantaneous.

In reality, all of the cards from the first set were removed and replaced by similar cards. No matter which card you had chosen, it would have “disappeared.” The change blindness, however, caused you to miss the fact that all cards were gone and just focus on your card. 

How can we design for change blindness?

If seeing a change is important to the user experience or the user’s ability to successfully complete a task, you want to minimize change blindness.

  1. Make changes obvious – use color or size to draw attention to the change.
  2. Make changes close – ensure any changes to instructions, notifications, warnings, etc. happen inline or as close to the user’s interaction as possible.
  3. Make changes without a refresh or scroll. Instead of refreshing, switching pages or tabs or any other shift of context to reveal a change, work inside the page with AJAX calls.
  4. Slow changes down. A slower animation, such as a fade, can draw attention to a change on your screen.

And if you want to write me to complain that a good magician never reveals his tricks, remember I never claimed to be a good magician.  

“Change Blindness: Why People Don’t See What Designers Expect Them To See” Kathryn Whitenton, 2015.