Eight Golden Rules: Rule 5 - Make Errors as Impossible as Possible

Shneiderman’s Rule 5 is the one that I suspect is most often violated by software developers, and I say that looking back at 20 years of writing code.  When writing software, developers think in terms of edge cases and data validation.  The rule of thumb is that, for example, when a user enters a value that is outside of the expected range, you will want to display an error message and ask them to try again.

I think this mindset goes back to the early computer classes that engineers take.  I remember some early computer classes when we wrote simple command-line programs that asked a user to enter a number between 1 and 10 and then validate that number.  This typically meant that, if the number 11 was entered, an error message would be printed to the console.  We learned in our very first classes that this was the way things were done, and from the programmer’s perspective it's easy enough to put the onus for correct data on the user and move on to fry some bigger fish.

So if a user tries to enter a date of February 30th, we would display an error message reminding them that there are only 29 days in February this year and ask them to try again. Simple, right?  Yes, but also frustrating, especially when it's so easy in software to give the user some safety nets.

From a User Experience Design (UXD) perspective, there are several choices we would make for date entry that are much better from the perspective of the end user, most of which involve not letting the user select February 30th in the first place.  For instance, we could use a calendar-based control to select the date, which would visually display all the days of the month and let the user select the desired one. We could even use three dynamic dropdown lists to enter year, month and date. Doing so, in that order, lets us determine the number of entries in date list.  Even if you don’t want to get that clever in the code, at least grey out the confirmation button if someone tries to enter February 30th.

Date entry is a trivial example, but it serves nicely to illustrate the point:  to make errors as impossible as possible.  If the user can’t make an error in the first place, that means less error dialogs that have to be programmed, less error messages to write, and less frustration from your users.  It's a win all around!

For more serious examples, I highly recommend the book “The Human Factor”, by Kim Vicente.  There are some chilling examples in the book from the medical field that talk about how changing the interface design on a patient-controlled infusion pump would have saved dozens of lives.  Preventing errors before they can happen is, in my opinion, one of the most critical things a UX designer can do.

Reference:

The Human Factor: Revolutionizing the Way People Live with Technology, Kim Vicente, (Random House of Canada, 2004)