The Importance Of Interface Text (part 2) - When Things Go Bad... (
Page 5 of 8 )
Next up, error messages, one of the most important components to consider
when creating interface text, purely because of its potential to unnerve
the user.
A well-written error message should cover three bases:
- What happened?
- What is the result?
- What does the user need to do?
You will usually have two kinds of errors - validation errors and exceptions.
Validation errors occur due to incorrect data entry by the user, and
therefore, the error message needs to essentially point out the input field
where the error occurred and how to correct it. In an online expense claim
system, for example, if a user enters an amount claim that exceeds his
total permissible expenses, a validation error would occur, and the
following message would be generated: "Your expense claim cannot be greater
than your total permissible claim. Please re-enter your expense claim."
An exception, on the other hand, occurs due to a back-end problem - for
example, the database has missing data or a resource cannot be found.
Typically, these are internal errors beyond the control of the user, and
the error message should reflect this, essentially asking the user to
contact a more technically-astute administrator to identify and rectify the
problem.
Some things to keep in mind with respect to exception messages:
- The message should specify whether the changes made have been reset and
the user needs to enter them again or simply use the "Submit" or "Save"
commands to register the changes.
- Avoid letting the system code for the errors appear on screen. And also
avoid using exclamations in error messages - "Oops! You screwed up!!!!" is
definitely not a good error message to see in an application.
- The user need not be informed of any back-end processes that are causing
the error. In case there is nothing more the users can do, ask them to
contact the administrator.
You can be more professional in your design of error messages by creating a
single database of generic error messages, and reusing them in your
application - for example, "<field> contains data of incorrect type", where
<field> is a variable that is automatically replaced with an actual field
name by the program. The benefit here is that you have a single database of
error messages, and can immediately enforce a consistent style across the
entire application.
Your other option is to write specific messages, like the message for claim
expenses above. You will need to write these for validations that are *not*
common across the application. In practice, you will nearly always end up
with a combination of these two approaches. The thing to be sensitive to
here is that you should not have an overlap between the two approaches -
that is, you should not be writing a specific message for a situation where
the generic one will suffice.
/ 3 
