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.

To quote a Japanese proverb, vision without action is a daydream.

I was working on dashboards within a logfile collection last week, when I was challenged how to determine the right components for the dashboard, and had several insights.

  • There is not one "dashboard" - there are dashboards for each stakeholder. The data of interest to each stakeholder depends on his or her entry perspective.
  • Dashboards are meant to provide a synopsis, not the whole story.  A user needs to be able to identify issues at a glance, with as little involvement as possible.  Pie charts, bar charts, and averages all provide a high level indicator that can be drilled down if something looks amiss.
  • The level of information isn't the same across stakeholders. Trends over time may be significant to an executive, but an engineer may need specific details at the transaction level. A system wide response time number is relevant to a user who knows tolerances and expected values, but a global number may mask small components within the average. Drill-downs, trends and thresholds are all contextual to the user viewing the dashboard.
  • It isn't enough for the data represented to be interesting. Seeing where in the world our users are connecting from may be interesting, but have no impact on me or my plans. I have to be able to act on the information, or I am just presenting trivia.

This leads me to my overarching recommendation on dashboards:

"Identify the highest level of visualization for each stakeholder that provides meaningful information, leading to action."

Designing an application is a balance between making it easy to learn and easy to use.  Something easy to learn may require additional instructions, work breakdown or examples.  Something easy to use, on the other hand, assumes mastery of the domain knowledge an tool, and attempts to streamline the task at hand.

Consider tax preparation software – for the novice who does their taxes once a year (infrequent task, high consequence of failure), a wizard walks through a series of questions complete with “What is this important” and instructions about where to find the required information.  A CPA, on the other hand, can go directly to the forms and fill them out quickly, having already mastered the domain knowledge and completing the task frequently.  Each of these users would be lost or frustrated with the opposite interface.

Designing for the user requires knowledge of their context (domain mastery, frequency of task, how the task presents itself) which can only be found through upfront contextual inquiry.  Sometimes you may have to create multiple interfaces for an application, or bolted on wizards to support the normal users and “pros”.