We all remember the story of the boy who repeatedly tricked the villagers into thinking a wolf was attacking his sheep. When the wolf’s attack became real, no one believed him. The moral of the story is don’t squander your credibility, and it’s a lesson that applies to user interface design as well as human behavior.
If an application raises the alarm about every little thing that might happen or go wrong – if it “cries wolf” – its alerts and warnings gradually become meaningless and lose their intended effect. Worse, they can become annoyances or even hindrances to the user, who then ignores them or, if he can’t, ends up hating them.
Alerts and warnings: error messages by any other name?
My last post was about error messages and how to make them effective. I mention this to emphasize that alerts and warnings are not the same as error messages.
Error messages occur “after the fact” and show the user how to navigate away from the problem and get back in the flow. Alerts and warnings are about problems that might occur in the future. Their intent is to prevent these from happening in the first place or, if that’s not possible, to mitigate their impact (think “preemptive damage control”).
Alerts “alert” and warnings “warn”
There is a difference between alerts and warnings, although it’s a subtle one. Alerts are a kinder, gentler version of warnings (think yellow traffic light instead of red). They inform more than they warn and are not fatal or even critical. An alert is the right way to let users know of upcoming downtime for maintenance or that the site login process has changed.
A warning is an absolute must when the user has to act (or refrain from acting) to avoid the loss of:
- mission-critical data
- access to the system
- privacy or control over confidential information
- the user's time (a significant amount) 1
Going with “the flow”
The Holy Grail of UI designers is to create experiences where the user becomes “fully immersed in a feeling of energized focus, full involvement, and enjoyment.” This is known as flow, a psychology concept with recent application in the field of Human Computer Interaction, particularly in Gaming.
Flow is completely focused motivation. It is a single-minded immersion and represents perhaps the ultimate experience in harnessing the emotions in the service of performing and learning.2
If flow is the Holy Grail, breaking it is anathema. Unfortunately, alerts and warnings do just that. In fact, breaking the flow is what they live for: their job is taking the user’s focus away from what she’s doing and towards something that needs her immediate and undivided attention.
This is the very reason for using alerts and warnings sparingly and judiciously. In a nutshell, avoid them unless absolutely necessary. Apple’s guidelines3 declare alerts unnecessary if they merely:
- increase the visibility of information already available
- update users on tasks that are progressing normally
- ask for confirmation of actions initiated by the user
- inform users of errors or problems they can do nothing about
Red light/Yellow light
Earlier I suggested you think of yellow vs. red traffic lights as a way to differentiate alerts from warnings. Red and yellow (and of course green) are common colors in UIs because their significance is universal.
Using these colors in alerts and warnings is an effective way to grab your user’s attention and quickly convey the severity of what’s involved. When you combine these colors with equally significant symbols or icons, you can replace redundant Alert and Warning labels with more specific and meaningful content (e.g., Scheduled Downtime or Malware Detected).
Green light
These are simple guidelines to follow when crafting alerts and warnings. I’ve also stressed the importance of using caution and good judgment when giving an alert or warning the green light, so to speak. Before making that decision, ask yourself: Is this alert or warning worth interrupting the user’s ever so elusive state of flow?
Until next time and happy trails.1 Adapted from a list in the “Messages” section in Windows User Experience Interaction Guidelines. http://msdn.microsoft.com/en-us/library/dd535525.aspx.
2 Both quotes are from the Flow (psychology) page in Wikipedia. The second is the words of Mihaly Csikszentmihalyi who, together with J. Nakamura, proposed the concept. http://en.wikipedia.org/wiki/Flow_(psychology).
3 Pared-down version of the list in the “UI Element Usage Guidelines” section of the iOS Human Interface Guidelines. https://developer.apple.com/devcenter/ios/index.action.
Subscribe