User Support in Case of Errors

Basic Rules | Error Messages | Setting the Focus of Attention | Support for Erroneous User Inputs | Error Prevention

This page describes methods which support users after they committed an erroneous entry or action.

Basic Rules

Prevent Errors!

Error prevention comes first. To prevent errors, do the following:

Use precise descriptions and instructions - do not be too short
Indicate required fields (through a red asterisk *) and an explaining text

For more information on error prevention, see below.

User Error or Error in the User Interface?

It is not the user who is too stupid to correctly use the interface, it is the computer software which is too stupid to intelligently interpret the user's inputs.

Support Users in Recovering from Errors

You can do this by:

Measure	Relevant Questions
Providing precise information to users ...	What did happen - what is the user supposed to do?
... directly where the error occurred	Where did the problem originate?
Providing useful input aids	What is already known to the system and can be offered to the user as possible input(s)?

Error Messages

An error message informs users that an error occured; it should consist of two parts: (1) a problem description and (2) an instruction for recovering from the error. Use precise field names (or field contents) and instructions in error messages. So users can recognize the element(s) which the message refers to, follow the instructions for recovery and continue their work.

Problem Description	+ Instruction for Error Recovery
Which data could not be interpreted by the system?	Which measures can be taken by the user?
Examples	Example
"Heibelderg could not be found;..." "There are no ICE trains available at the departure station Walldorf;...“	"...; select the destination of your choice from the list"

Syntax for Message
<Problem; Action for error recovery>
Example
"Data are not complete; enter <data>"

For more details on messages see Formulating Messages in the SAP Reference Lists on the SAP Design Guild.

Setting the Focus of Attention

... to the Place where the Error Occurred

Emphasize error fields and messages by coloring them (see visual design guidelines).

Scroll the screen to the field where the error occurred and position the cursor into it. Messages should also be visible without scrolling.

Fields

Place a textual description directly above the field, or field group where the error occurred.

This can be accomplished by:

Temporarily replacing instructions above fields or field groups - if there are such instructions
Moving fields apart so that an error message can fit in

Combinations of Fields (e.g. Conflicting Inputs)

Issue a message on top of the pushbutton that initiated the action and thus caused the error.

Tables

Issue a text description above the erroneous line (that is, within the table).

Exception: Collective data entry in tables (see below).

Avoid Popups!

Popups interrupt the users' work flow and thus annoy them.

Exception: You may use popups for severe errors like aborts that need direct user intervention.

Support for Erroneous User Inputs

If the user input contained an error or could not be uniquely identified by the system, users can be supported by providing useful data that the users can select from - instead of havíng to re-enter the data.

Complete inputs through plausible assumptions, for example:

Today, here (user location), user name
Typical values, last/recent entries, data from preceeding screen
Example (plausible location): Walldorf, Germany

Transform an entry field after ambiguous, or unidentifiable entries into a dropdown listbox:

Ambiguous entries may be supplanted by additional information.
Example: If there are several users named "Peter Smith", provide further information that allows users to select the wanted one.
Mispellings may lead to inputs that the system cannot interpret; provide "fuzzy" searches that let users select from plausible alternatives:
Example: Heibelderg -> Heidelberg, Heidberg, ...

Collective Entry in Tables

There are cases, where users want to book a large number of items and some of them lead to errors after the booking has been initiated by the user. Here, users do not want to be bothered with the correctly booked items, but have to take measures to correct the erroneous bookings. Therefore, display the table again, but only with the erroneous items (provide a respective error message).

Error Prevention

Preventing errors - instead of remedying them - has the following benefits:

Users cannot come into error situations - many users have problems with recovering from errors
The users' work is not interrupted by error messages
Users are not confused, or puzzled by (often cryptic) error messages
There is no need for a screen area that display errors

Often it needs some rethinking and the giving up of "old habits" to find design solutions that prevent errors instead of sending an error message after an error has occurred.

Do Not Let Users "Pay" for System Weaknesses

Many systems work the way that they need help from the users, not the other way round as it should be. For example, often users are required to enter data in a certain format, because the system otherwise cannot recognize the input as valid data. As a consequence, an error handling procedure is needed, because users make errors. Sometimes the system is even "nicer" to the users and also provides online instructions for them. So they can read how they should enter the data. Actually, even this does not help much - users still make errors and developers complain about their "stupid" users.

This way of thinking is on the wrong track. The problem is not on the side of the users, and they are not too "stupid" to read the instructions and enter the data correctly. The problem is on the side of the system, which forces users to act in a "system-friendly" manner. Instead of requiring users to enter data in a certain format, an input field could interpret the data "intelligently". This prevents users from entering invalid data, and there would neither be a need for an onscreen instruction, nor for an error handling procedure.

Tips

In the following we provide some ideas and examples, which may stimulate your imagination when looking for ways of how errors can be prevented.

Prevent Wrong or Invalid Inputs	Numeric fields: Prevent users from entering letters by parsing the input string Date and time fields: Provide "intelligent" date and time fields that are preformatted, or provide selection controls instead of input fields (dropdown lists, spin buttons, calendar controls) Currency fields: Use preformatted fields
Prevent Incomplete Inputs	Indicate required fields (through a red asterisk *) and an explaining text
Prevent Invalid Actions	Disable pushbuttons that cannot be used in the current context Do not offer functionality that is not needed
Prevent Desastrous Actions	If actions can have severe consequences for the user, add explaning texts to the respective buttons and inform the users about the consequences Send dialogs if users can loose data
Do Not Make the Interface Lie	Do not use screen elements where uses expect to use them in any order, if there are dependencies, or if a certain sequence of steps has to be followed Example: Do not use tabstrips for views that depend on each other and cannot be viewed at random
Do Not Obscure the Screen and its Purpose	Often important information is hidden while irrelevant information dominates the screen. In other cases users simply have no clue what a screen's purpose is Thus, provide the necessary information and arrange it so that relevant things are recognized first - this way users know what to do on a screen and how to do it

top