Handling errors, sometimes called defensive programming, isn’t really something I have been taught very well at Athabasca or Niagara College. Over the last few years, while handling customer support and internal user support I have come to realize that what the dialog box says and the frequency of errors is probably the single biggest user experience issue.
I use the following guidelines for developing and when to show error messages.
Visual Attributes The error message should immediately grab the user’s attention: on a web application it should be exactly in the middle of the screen using some sort of popup, in regular desktop applications it should be in the middle of the screen in a log box. For text, I usually use a bold and red coloured font.
Message The error message must be clear to your average user: if the printer is out of paper tell them that! Don’t give your user just an error code, because they won’t know what that means and they won’t want to read your manual or contact support.
Where? Your user wants to know where it occurred, and how to fix the error. If possible some sort of visual attribute should also be set if the error occurred on a data entry screen. Set the border of the element reg, set it bold if the text is invalid, or even use some sort of icon.
Always make sure your error messages are clear: users don’t want to have to search through some user manual for software they bought, or have to pick up the phone and call for technical support. Apple has really shown us that users just want things to work, and it should of course look pretty. 🙂
Author: Brian Cline