Error messages, I’ve written about them before. I’ve written about how bad error messages harm your users and how error messages are just one type of the different messages your users see. At SEEK we noticed our global error messages (that is an error for a whole form) weren’t following the same pattern. After reviewing what we do in different places on the site, Vedran Arnautovic and I set to work documenting the global error style in our Style Guide, which was reviewed and signed off by the rest of our UX team.
First, errors should be avoided where possible
It is better to prevent errors, than have to show an error message.
Avoid errors - We think this is what you wanted
If you make a minor typo, like searching for jobs in “Yarravillee” instead of “Yarraville”, we automatically search for Yarraville, without any user interaction for error recovery.
Best guess error recovery
When we have an idea regarding the user’s intent, we should try to perform the action they were intending. When there is some confusion about their intent, provide alternates as quick options for recovery.
We think this is what you wanted... or did you mean
When someone searches for jobs in “Melbourne”, we show results for all of Melbourne, our best guess at what you meant. We also provide quick links to search results for other variations of “Melbourne” that you may have meant.
We couldn’t do that thing you asked
Sometimes errors are unavoidable. If you are filling out a job application and have left out a required field, we can’t figure out this data for you — if we’re not sure what your contact number is we can’t take a guess at this. We can’t take a stab at your phone number, we’ll likely add a nonsense number or it could be Bob’s number and then he’ll get the job.
We provide in line validation errors on every field as they’re filled in — this is required; your resume file is too big; etc. Sometimes, people miss these and try to submit anyway, they’re human after all. This is where global error messages come in. Instead of just sitting on the page, expecting them to scroll up and figure out why nothing seems to be happening on the screen, we tell them explicitly that the action could not be completed, and what that action was: “we haven’t been able to [verb] your [noun]”
We tell the user exactly what action failed, and on what:
- We haven’t been able to submit your application
- We haven’t been able to update your profile
- We haven’t been able to create your job ad
Great, you didn’t verb my noun. Now what?
If there are fields the user can, and should, correct in the form, we scroll the user back to the top, and present the errors there. We call out the cause of the error, and what to do to fix it, in the order they appear. Please review the highlighted fields (and then name those fields!).This allows them work their way back down the form, correcting as they go.
If you don’t name the fields they might miss fixing a field. Arm users with all the information they need to be successful on their next attempt. As they make their way back down the form they see inline error messages telling them what exactly needs to be fixed on each field.
When it’s our bad
Sometimes we can’t verb your noun because of some technical glitch. In these cases, we present the error just above the submit button, so users can see it in context without trying to figure out what’s wrong. In these situations, we ‘fess up and take the blame. We tell the users what is wrong (in this case, something, we can’t be more specific) and tell them what to do (try again) — “There’s something wrong on our end. Please try again in a little while”.
'fess up and take the blame when it's your fault
Global errors are necessary if you work with forms. If a user tries to submit a form, and it appears that nothing happens, they will just click submit again. They won’t know that a field 2 page scrolls up was missed unless you tell them, and be left swearing at the screen. If they can’t figure out what to do to make the noun, verb they’ll just leave your site.