Oops! Our Bad.

Alice Toth, Tuesday, April 10, 2007 @ 3:01 pm

There are two ways of producing error-free software. But only the third will work.
~ anonymous

There comes a time in the life of any application when an error occurs. Ideally, the software should be written in such a way to gracefully handle the exception and, if necessary, let the user know how to proceed. However, some development teams seem to focus solely on system errors and their output, which makes sense since they’re deep in the writing of the system code, but it generally leaves the user out in the cold.

Writing error messages using language the user understands is an essential element of user-centric design. A stack trace is not written in a way the user will understand. A database connection error holds no meaning for the user. Do not display these at the presentation layer. Exceptions such as these need to be handled behind-the-scenes, and if the application cannot gracefully recover, only then display a message to the user and explain what they need to do in order to resume their task. In other words, use the language of the user and not the system to explain the error and supply them with an escape route.

Whenever possible, the system should display the error message on the page where corrections need to be made in order for the user to continue on with his task. However, this isn’t always possible. Some errors will require the user to return to the beginning of the task flow and start over. In either case, preserve the user’s work as much as possible so they don’t have to enter everything all over again. (They will really appreciate it.) And if appropriate, highlight any data that caused an error to be thrown and advise the user to double-check their entry.

Regardless of which page they’re displayed on, error messages needs to be both visible and highly noticeable. Don’t hide them below the fold and don’t have them blend in nicely with the visual elements. They need to prominently stand out so the user knows the next steps to take. If the next steps are on the same page, i.e., missing data, highlight the fields the user needs to update. If the next steps require the user to return to a previous page, provide a link within the error message so the user can easily access that page. Tell the user there was an error and give them an escape route.

Of course, every effort should be made to develop a graceful way to handle exceptions, but occasionally messages need to bubble back up to the presentation layer. Letting the user know what happened and what they need to do using language they’ll understand goes a long way to creating a good user experience.

user experience design

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment