Contemporary interfaces can be complicated, tieing a lot of data sources together: i.e., a contact list can be imported from the device’s local storage, user pics come from the cloud storage, and the status comes from a social network. The more data vendors you have, the bigger is the chance something may go wrong and cause a malfunction.
It’s important to keep in mind that ill-timed, hard to find, or intrusive error messages can damage user experience significantly.
There are four basic ways to report an error:
- An interface-blocking message;
- A section-blocking message, leaving the other sections unblocked;
- A non-blocking message;
- An inline message displayed next to the malfunctioned element.
Interface-blocking messages
This type of reporting an error is the easiest one to make on the app. These can be native or custom pop-ups and alerts, blocking the interfaces or replacing interfaces as full-screen messages. In this case, the user can’t continue using the app, before the error is resolved or the pop-up is closed.
The interface-blocking messages are the most noticeable of all, but, at the same time, the most distracting. They should only be used in cases when any further work with the interface is useless, both for the user and the system.
Do: “Error 500, can’t display page”. The interface can’t be loaded, so the user has nothing to work with.
Do: “Session expired” in banking apps. Further interaction is unavailable or potentially unsafe.
Don’t: Internet connection is lost while a map is loading. The map can’t be refreshed, but the user can work with the parts already loaded. There’s a chance a piece of the map he was looking for is already on the device.
Use interface-blocking messages for major errors that make further work with the app useless.
Section-blocking messages
This way of reporting an error is more complicated in the making, but it, obviously, is a more delicate one.
If the interface is built with some separate widgets, receiving data from different sources and sending different queries, it makes sense to display an error in the malfunctioned widget, leaving the working ones intact.
For instance, if the page contains chat, friend list, exchange rates, and weather reports. If the weather widget has malfunctioned, there’s no need to disturb the other widgets. In that case, even a small error message with an OK button may disturb the user working with another widget, so there’s no need to use it.
However, don’t use section-blocking messages if the data had already been loaded into the block, and the error has occurred when updating it.
Do: “Unable to load exchange rates”. No data was loaded, further interaction with the widget is pointless.
Don’t: “Unable to update chat”. Just like the map case—the user may have received the information he needed, no point in disturbing further use.
Use section-blocking messages for local errors, making further work with the block pointless.
Non-blocking messages
Such messages are snackbars, pop-up statuses, and Android toasts. This type notifies the user about an error, without blocking any parts of the interface. Use it in cases where further work with the loaded data makes sense for the user and the system.
Do: “Unable to load a piece of a map”. The user can continue using the loaded parts but should be notified about an inability to update.
Don’t: “Form filling errors”. In that case, the user’s attention will be drawn away from the fields, in which the error is found. The user will have to look for the filling errors themselves. Another scenario is, the user may not know any errors have occurred, and wait, thinking that the form is processing.
Use non-blocking messages for major errors that don’t make further work with the app useless.
Inline messages
These are the hardest in the making. Inline messages appear next to the malfunctioning object, i.e. with invalid forms.
Inline messages are great because they draw the user’s attention right to the place where it’s needed.
Do: “Username is already taken”. Choose a username that’s free.
Do: “Invalid email address”.
Don’t: “Unable to send the form”. The user will focus on the element of a form, even though the error is global and related to the whole form. In that case, it’s best to use a non-blocking message.
Use inline messages for local form validation errors.
Next time, I’ll tell you what exactly you should write in your local form validation error inline messages.
Don’t forget to download the poster for your viewing pleasure.