Jennifer B. Davis



















"I like an escalator because an escalator can never break, it can only become stairs. There would never be an escalator temporarily out of order sign, only an escalator temporarily stairs. Sorry for the convenience." - Mitch Hedberg

We once built an incredibly useful web application at work to handle a business problem that was labor intensive, a critical differentiator for our business, and was something that we needed to scale. The application was slick and worked really well, at least I thought. Then we started getting new users to try it and as they learned the nuances, we found they needed some "Do you really want to send this?" or "Do you really want to delete this?" confirmations added in to prevent some errors. In addition, logic needed to be added to the site that would prevent incorrect data from being entered in the first place. One colleague described the early version of the application as a gun without a safety. Powerful, but a big dangerous in the wrong or inexperienced hands. We quickly identified the risk areas and put fixed in place, but not without causing some consternation first. I have found that there are at least 3 ways to error-proof your product.

1. Make the Error Impossible

Usability experts like to focus on making the "right" thing to do obvious. I believe, however that equal attention needs to be played to making the "wrong" thing impossible (or at least horribly difficult). The shaped solid ink cartridges in a Xerox color printer is a great example of this. You can't put them in the wrong slots. They don't fit. All products and applications should be error-proofed in this way. Some people check for email formats on entry fields or check sum credit card numbers to ensure they were typed correctly. What about making sure in other ways that people can not proc

2. Take the Pain out of Error States

For a higher standard still, you can look to the quote above about escalators. How can you make a disabled, broken, or improperly used product still functional, but just not as functional. Instead of a 404 error on a website, what about sending users to an alternative page with a training video or with the offending part of the code pre-selected with defaults to make it easier for the user? Maybe in addition to sewing extra buttons into shirts, they should include safety pins. If the people mover at the San Francisco airport is not in operation, people can still walk on it and get a bounce in their step and view the artwork and displays on the wall. Remember, too that delays are error states and entertaining customers while they wait is also a way to take the pain away.

3. Reframe Unavoidable "Errors" as Opportunities for Differentiation

Taken one step further still, what about taking the unavoidable (or frequent) errors and turning them into differentiation points. For instance, all products eventually reach the end of their useful life (the ultimate error state). What about providing real solutions for empty packaging, used products, or those products which are at the end of their useful life? I firmly believe more people should bundle in recycling/removal or upgrade programs into the costs of their product. What other errors are unavoidable or frequent enough to justify looking at them differently? If most people mistakenly hit some key, select an inconvenient option, or have problems with particular types of installations, why not develop programs around those things and turn them into features that are marketed as differentiators, rather than error states to be avoided?

1 Response
  1. Ross Says:

    One of the bibles that we use on our web team is Defensive Design for the Web. A great book from the guys behind BaseCamp et. al, 37Signals.