Error messages without user’s frustration
An error message is text displayed when things go awry. It notifies of a problem that has occurred unexpectedly, or an operation that requires user interaction. An error message can also include a warning (based on Wikipedia).
Poorly written or rendered error messages can be a source of frustration and disappointment for users, making them address technical support more often and thus increasing technical support costs.
Moreover, error messages may cause stress and irritation, making users think they are at fault for the error. This can adversely affect user interaction with the product, since some users will just abandon the process and delete the application. This is why your top priority should be to avoid errors as much as possible, and to reduce user frustration by improving your error messages.
In this post I will deal with input field error messages, though most of the tips will also work well for system errors, 404 error pages and others.
Now, here is some advice to help you avoid multiple errors, make users of your product happier and improve user experience.
Avoiding Errors
- Give prompts to the user
- User-friendly input
- Autocomplete
Dealing with errors
- What is an error message like?
- Only that which is necessary
- Accessible content (applies to the hints as well)
- What? Where? How?
- How you write what you write
- Be brief
- Accessibility
Avoiding Errors
Give prompts to the user
You need to show users what exactly you expect them to do so that they are able to do it. One way to achieve this would be guiding users step by step in details through the operations, or giving them appropriate hints.
For example, if the user is required to enter their password, you can specify the password requirements, e.g. those pertaining to capital letters, using symbols and numbers or minimum password length. This information can be displayed under the password form in a font smaller than the base.
Another option would be giving an example in the entry fields (such as email or phone number). However, in this case some users may either a) skip the field thinking that it is already complete, or b) if distracted at entry, they may forget how exactly they should enter the data and will have to erase all the information to see the hint again.
You can also provide pop-up hints that will appear when users are entering their data in certain fields. In this case, you need to make certain you place the hints in a way they do not interfere with data input.
User-friendly input
Yet another option would be making data input less restrictive. For example, a user is asked to type into a field a 16-digit code divided by dashes in four groups. Make it possible for the user to enter the code in a way that is comfortable for them (e.g. just like it is designed, 4 groups with dashes; allowing spaces between the groups; allowing to enter all the digits together without dashes).
Autocomplete
If the system already has some user information (their address or phone number), you may allow for the automatic completion of respective fields. However, this should be used sparingly since user information may change. You can also help users correct their mistakes by adding options of correction. For instance, instead of notifying that the city and time zone do not match suggest a choice of correct options upon clicking “city”.
Dealing with errors
What is an error message like?
When users see a long list of errors, they may feel rather stressed, especially if a place (or field) with the error is not specified. To reduce user frustration, a good solution might be placing the error message by the field where the error occurs, highlighting the field with bright, easy-to-notice colors (red in most cases). You might also want to use small icons (which works well for those who have difficulties telling the colors and might confuse green and red). Make sure the message appears near the specific field (and remember to indent it) to avoid ambiguity.
A good idea might be to use line-by-line validation, which allows to spot errors at once. According to the research by Luke Wroblewski and his team, this way of displaying error messages helps users to cope with forms validation quicker and more successfully. While the user is entering information or scrolling down, a process is carried out that spots errors and notifies the user if something goes wrong. This tool helps to correct the errors on the spot and concentrate on one field at a time rather than re-read everything from the beginning (when there are many fields to be completed this can become quite a tedious and annoying exercise). There are also cases when the user feels more comfortable knowing at once whether the information is entered into a field correctly or not. Otherwise, users may experience Pogo-Sticking Effect, frustration and disappointment, when the information is checked only after all the forms are completed, and it takes some time to eventually discover that there is an input field error. Such cases are quite common with username and password forms validation.
It is important in this regard to understand which type of line-by-line validation will suite this or that form. For instance, the fields that require a definite number of characters (e.g. card number or zip code) may display an error message once the limit of characters is exceeded. Another option would be enabling validation during data entering, which works well for password forms. Still the most common type is validation upon form completion.
It is worth noting here that if a field requires entering more complex information (like a credit card number or an address), line-by-line validation may not be the most comfortable option, since even after all the fields are validated the form may still contain errors at confirmation.
When displaying error messages, do not use pop-up windows where forms completion is needed, because they just distract the user. They also cover the workspace and the user cannot see where the error occurs, or which field contains incorrect information.
Only that which is necessary
There is nothing more annoying and discouraging than spending time and effort to complete a form only to see the error message with a request to re-enter all the information. Do not make the user “suffer” one more time. Instead, it would be better to ask them to complete anew only the erroneous fields.
Accessible content (applies to the hints as well)
This means writing in plain, non-technical language (if the product is not for technical experts) so that a user with any background (even those who see a PC for the first time) could understand what is going on. Try to avoid sophisticated technical words or professional slang (tech-speak), because not all users may know what you are talking about.
It is better to avoid specifying the error number, since the user will hardly know what the number stands for (if you do put the number, make it less noticeable compared to the main text). Use active voice when describing system errors to show that you are the one responsible for the error. However, passive voice serves well to describe an error from the user’s side (but not necessarily made by the user), e.g. “Your card is expired”.
Make error descriptions as clear, informative and relevant as possible. This information may be handy not only for the user but also for the technical support specialists, if the user decides to address the issue to them.
What? Where? How?
You should always specify where and how the error can be fixed.
Any feedback should be appropriate in content so that the user can understand where it comes from and can interpret it correctly. Make sure to state the problem clearly, point out the reason for it (if this is relevant for the user), show the place where it has occurred (it should be clearly visible) and mention the ways to fix it.
How you write what you write
Make your error messages friendly and respectful. Let the user feel that you want to help rather than offend or nitpick over the faults that lead to errors. Never make the user to blame for the errors.
Depending on your target audience and product type you can decide to use either more informal language if the product is geared at young people and itself is entertaining, or, if the product is more businesslike, adopt a more official and formal register. You should avoid emotionally marked vocabulary and take care not to overuse words with negative connotations (error, failed, wrong, bad, etc.). Try to replace them where appropriate by more neutral or positive words if this does not affect the meaning of the sentence.
Be brief
An error message should be concise. Any error is itself time-consuming, so hardly any user wants to waste time reading lengthy detailed descriptions, which may also be quite difficult to understand (see the point above). The only exception might be when you give advice on how to fix the error, but even in this case try to make your explanation as clear and succinct as possible.
Useful tips on how to make inline error messages accessible can be found here
In conclusion, here is what you should do to avoid input field validation errors:
· specify what information or actions are required from the user;
· give hints;
· make input more user-friendly or provide word completion.
If the errors did occur, here is how you can help the user correct them and stay satisfied with the product:
· use line-by-line validation if appropriate and highlight only erroneous fields;
· use relevant and understandable language;
· explain briefly and clearly what kind of error has occurred and how to fix it;
· respect your users and never blame them for the errors.
Hope this post helps you avoid common pitfalls when designing your new product :)
If you enjoyed this post, click on the applause button to help other people find it.
Thanks,
Fively Team | ☞ https://5ly.co
Resources
· Resource 1 · Resource 2 · Resource 3 · Resource 4 · Resource 5 · Resource 6 · Resource 7
