The way a software application handles errors can have a big impact on user satisfaction and usability, and so error handling deserves close attention from user interface designers.
Errors are unexpected or undesirable situations that prevent the normal operation of the application. We might classify errors by their general types and severities:
- The worst type of error is the unrecoverable crash, where the program abruptly stops due to a programming error that usually involves an unforeseen situation. Extensive testing and careful code inspections can reduce but never completely eliminate the possibility of such cases in a complex system.
- Technical errors are programming errors that prevent some task or action from being completed, but do not crash the entire application.
- Transient technical errors are situations that arise that temporarily hinder proper operation, but which can usually be corrected by taking actions outside of the application. For example, a database connection or network connection might be lost, a disk is full, etc.
- Data validation or rule violation errors are cases where the application has detected that the data does not meet some criteria for validity. The system cannot function correctly if the data remains in this state, and so the user is notified and the user is expected to correct the data.
- Warnings are cases where the application detects a situation that doesn’t prevent operation but which may have consequences that the user might not want or expect.
We should also note that if the system interacts with the real world, programming mistakes and invalid data can lead to “error-like situations” in the world. For instance, if your application prints out checks but the address on the check or envelope omits the postal code, they may not be deliverable by the postal system, and the recipients won’t receive their checks.
Errors usually occur as a result of the user taking some action, although sometimes a system will report an error “out of the blue” when a background process has encountered a failure or when some data has been received from another system. Data-entry forms are one of the most common places where errors are identified and presented. In most data-entry forms, the data must be checked for completeness and validity before the task flow can continue.
Usually, the user is informed of errors by means of error messages, which may be presented in pop-up dialogs, in lists (when there are multiple errors), or in “callout” messages alongside fields in a data-entry form. In some applications, you may be able to indicate errors using highlighting or non-textual symbols. For example, word processors often highlight misspellings with squiggly red underlines, and cells with formatting errors in Microsoft Excel are marked with a colored triangle.
When writing error messages, here are some guidelines to keep in mind:
- Ensure that error messages are carefully worded so that they clearly identify the problem in a way that your users will understand. If possible, explain how to proceed to resolve the issue. In enterprise systems, you may ask the user to notify the helpdesk; in such cases, you should provide an error number so that the helpdesk staff can easily identify the error.
- Try to ensure that error messages are at a suitable level of abstraction for the user. Complex software systems are built upon stacked “tiers” or layers of abstractions, and an error message generated in a low-level component may be too technical or obscure to be exposed to the user without translation into a more user-friendly form.
For example, when trying to save information to a database, if a required field is missing, the database might generate an error such as “ORA-01400: cannot insert NULL”. This type of message is baffling to average users. It describes a technical situation that the user does not understand and cannot access, and it doesn’t pinpoint what or where the actual problem is, or what the user should do to solve it. If the system cannot prevent these types of errors through better program design (validation at a higher level of abstraction), it should “catch” these errors and relay a more suitable error message such as “Please enter a value for the Due Date field”.
There are cases where the details of the error are necessary for technicians to properly investigate the error. As a compromise, you may choose to present “sanitized” error messages to users, but save the technical error messages to a log or database for inspection by the support team and developers.
- Avoid blaming or criticizing the user. Many users feel guilty when the system is reprimanding them for a mistake they have made, when it is often the design of the system that is really at fault. When the error is a system exception and the user is not at fault, the error text should reassure the user that she has done nothing wrong. If the error has caused the user some inconvenience, it is courteous to apologize for the error.
- When an error message is presented, you may wish to aid users by offering help or suggestions for resolving the issue. This is very useful for new users, but cumbersome for experienced users, especially when the explanations are very detailed. (The IBM DB2 database system’s error messages are sometimes over a page long and scroll off the screen!) For error messages that contain lengthy explanations, ensure that there’s an emphasized summary or “headline” so that experienced users can identify and refer to the error easily. Or you may consider presenting only the brief summary, and then allow the user to click a button to access help content relating to the error.
Here are some more tips and guidelines for thinking about how to handle and present errors in your application:
- Let the user correct errors and mistakes easily. Allow the user to undo an operation or retry an action without losing data or having to start over from scratch. For validation errors, allow the user go back and correct the erroneous fields without having to re-enter all of the data on the form.
One study found that expert users of word processors spend about 30% of their time correcting typographical mistakes (Card et al., 1983, p. 423). Because of the amount of time spent on error correction, improving the efficiency and ease of correcting errors can greatly increase productivity and reduce frustration.
- For validation errors, whenever possible, show the error messages in proximity to what is causing the error. If a field is invalid, try to place the error message alongside it. Don’t put a list of errors on another page or in a pop-up dialog and then expect the user to navigate back and find the errors. However, some validation errors involve multiple information sources, and in these cases it may not be so simple.
- Color can be used to highlight errors (e.g., marking invalid fields with a red border or background), but don’t make it the only signal, because it may not be noticeable to visually-impaired or color-blind users.
- Obviously, whenever possible, try to design the system so that error conditions simply cannot occur in the first place. If a mortgage calculator requires the interest rate to be within a certain range, a “slider” control that constraints the interest rate so that it can never exceed that range will prevent any error. As another example, the user may be unsure of the correct date format to enter in a date field. If you pre-fill the field with the default due date (in the correct format), or if you let the user pick the date with a calendar control, there will be fewer chances for entering the format incorrectly.
- Make sure that the user is aware of important error messages. One system I’ve used displayed error messages in the status bar at the bottom of the screen, and the user was not always aware that the message in the status bar had changed. (Using the status bar for displaying errors also has the problem that it can only show one message at a time.)
- Non-critical warning messages that are presented repeatedly can quickly become a nuisance. You may wish to allow the user to check a “Do not show me this warning again” box to suppress these warnings.
- It is better to catch and report errors early rather than allow invalid data to lead to further errors later. It is much better to use data validations to ensure information is correct instead of letting it pollute later calculations and operations, which may lead to additional, more complex errors.
- For transient technical errors such as a broken network or database connection, the system might want to retry the operation several times before generating an error message.
- Some types of errors and mistakes made by the user can be automatically corrected by the system. For example, Microsoft Word can auto-correct common spelling errors. Some systems let the user enter dates in virtually any format, and the system then converts it to the preferred format.
When the system performs an auto-correction, there should be clear but unobtrusive feedback so that the user is aware of what has happened and can verify that the correction is in fact correct. You should also allow the user to disable this behavior, because there is nothing more arduous and frustrating than correcting unwanted auto-corrections.
- Critical technical errors, especially those that cause program crashes, should be reported to your support team or helpdesk for eventual investigation and fixing by the development team. Investigators will need sufficient diagnostic information (stack traces, system configuration, etc.) to understand the context and recreate the error.
Although you can ask users to submit a bug report or trouble ticket, and copy-and-paste error details into an e-mail or online form, extraordinarily few will do so, because it is time-consuming and the user receives no immediate benefit. It is preferable if the diagnostic information can be provided electronically to the support team. In a web application, the server can simply record these errors in a log or database, but in a desktop or mobile app, you usually need to ask permission to transmit data to a server. Ensure that privacy laws involving the use and protection of personal data are respected.
- Some systems must allow invalid or incomplete data to be saved. Investment brokerage systems, for instance, often require a number of documents to be submitted before an account can be opened, and multiple errors will accumulate if documents are missing or information is incomplete. It may take weeks for the proper documents to be received. Some pension administration systems even allow the user to intentionally override certain errors so that preliminary benefit estimates can be calculated even when some information is missing or invalid. In these systems, the errors have to be resolved before some key final task (such as “open the account”) can be completed.
In systems that permit these “persistent” errors, users must be able to easily access the list of errors. Ideally, the user should be able to click on an error to navigate to the place where the error can be corrected. And in workflow-driven systems, reports or alerts should alert staff to cases that have been left “hanging” for some length of time.
Dealing with errors is always an unpleasant situation for users. Careful attention to user interface design and an effort to reduce the number of errors that users will be presented with can greatly improve the user experience.
