Answer 37 of 50
Designing User-Friendly and Helpful Error Messages in Web Design
A helpful error message says what went wrong, in words the user knows, and what to do next. Wording is only half of it. The message also has to appear at the right moment, next to the problem, and in a form every user can perceive, including people who cannot see the screen. A well-written message that shows up too early, in the wrong place, or only in red fails the person it was written for.
What every message needs
Jakob Nielsen’s ninth usability heuristic sets the standard: “Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.” Here is how that looks in practice:
| Instead of | Write | What changed |
|---|---|---|
| Error 500: Internal Server Error | Something went wrong on our end and your order was not placed. Try again in a few minutes. | Plain words, what happened, what to do |
| You entered an invalid email address | Enter an email address in the correct format, like name@example.com | No blame, and the fix is in the message |
| The email address wasn't recognized | This email address is missing an @ | Neutral and specific, not neutral and vague |
| Your session has expired | You were signed out after a period of inactivity. Sign in to continue where you left off. | The next step is stated, and offered as a link |
| Invalid password | Password must be at least 12 characters | States the rule; better still, show the rule before the first attempt |
Nielsen Norman Group’s 2023 error message guidelines, by Tim Neusesser and Evan Sunwall, add the tone rule: “Take a positive tone and don’t blame the user.” When the problem is on your side, say so. When a message offers a fix, make the fix a link or a button, such as a “Return to cart” link, rather than an instruction to go somewhere.
Words to avoid, and where style guides differ
The GOV.UK Design System’s guidance on error messages asks for messages in plain English that “use positive language and get to the point”, and lists words to leave out: technical jargon; words like forbidden, illegal, and you forgot; please, because it implies a choice; sorry, because it does not help fix the problem; valid and invalid, because they add nothing; and informal language like oops.
Not every style guide agrees on apologies. The Microsoft Style Guide entry on sorry says to “Use sorry (and similar wording) only in error messages that notify the customer about a serious problem or one that they might find very frustrating”. Pick one rule for your product, write it down, and apply it everywhere, so the same situation never gets an apology on one screen and none on the next.
When to show the error: two defensible answers
Both camps agree on the default: do not show an error before the person has had a chance to finish. Neusesser and Sunwall write: “Presenting errors too early is a hostile pattern.” Baymard Institute’s 2024 testing of inline form validation found that “overly aggressive premature validation negatively impacts the overall experience as users are told their input is wrong before they have had a chance to type it correctly.” Beyond that, there are two approaches with evidence behind them:
| Validate when the user leaves a field | Validate when the user submits | |
|---|---|---|
| Who recommends it | Baymard Institute (2024); Luke Wroblewski's 2009 study | GOV.UK Design System |
| What it does | Checks each field as the person moves on, and clears the message the moment the input is corrected | Checks everything on submit, then shows the page again with answers kept, an error summary at the top, and a message next to each field |
| Evidence | In Wroblewski's study, the best inline version beat a submit-only control with 22% higher success, 22% fewer errors, 31% higher satisfaction, 42% shorter completion time, and 47% fewer eye fixations | GOV.UK warns that validating before people finish entering information can cause problems, especially for people who type more slowly |
| Watch for | Messages that fire while people are still typing; green checkmarks people may read as "correct" rather than "valid" | Errors discovered only at the end of a long page |
Wroblewski’s results are in Inline Validation in Web Forms, published by A List Apart in 2009; in the first half of that study’s form, showing the message after people finished each answer led to completion seven to ten seconds faster than showing it while they typed or as soon as they entered a field. GOV.UK’s rule, in its validation pattern, is direct: “Do not validate when the user moves away from a field.” It allows exceptions only where research shows a benefit, such as a character count that warns when text goes over the limit.
Choose by context. Leaving-the-field validation suits short forms where catching a typo early saves effort, provided you test it with keyboard and screen reader users. Submit-time validation suits long, multi-page services and audiences that include people who type slowly or use assistive technology. Whichever you choose, use it consistently across the site.
Place the message where the problem is
Put field errors next to the field, not in a banner the person has to connect to the right input. When several errors occur at once, also show a summary at the top. The GOV.UK error summary component does this: it sits at the top of the page, keyboard focus moves to it, and it links to each answer that has an error.
Severity can be signaled with color, but never by color alone. Pair color with an icon and with text that says what is wrong, so the message works for people who cannot tell red from green; designing for color vision differences is covered in designing for color blindness and visual impairments. Match prominence to consequence: a payment failure deserves more weight than a formatting slip in an optional field.
Make every error perceivable without sight
Three WCAG 2.2 success criteria set the baseline:
- 3.3.1 Error Identification (Level A): “If an input error is automatically detected, the item that is in error is identified and the error is described to the user in text.”
- 3.3.3 Error Suggestion (Level AA): when suggestions for correction are known, they are provided, “unless it would jeopardize the security or purpose of the content.”
- 4.1.3 Status Messages (Level AA): status messages can be “presented to the user by assistive technologies without receiving focus.”
In practice: connect each message to its field in the markup, the way GOV.UK’s error message examples reference the error from the field with aria-describedby and start the message with a visually hidden “Error:” label. When an error appears without a page reload, announce it; W3C’s technique ARIA19 uses role="alert" or a live region so a screen reader is notified when the message is injected.
Keep what people typed
Never clear a form because one field failed. NN/g’s guidelines say to “Preserve the user’s input” so people correct the original entry instead of starting over. If a session times out while someone is writing, keep the content through sign-in, or warn before the timeout. In a multi-step form, return people to the step that failed with earlier steps intact. Preventing the errors in the first place, through field design, is covered in designing user-friendly and error-free form fields.
Suggest corrections instead of applying them silently
If someone types “gmial.com,” ask “Did you mean gmail.com?” and let them confirm. Silent correction can damage valid data when the person meant something unusual, and WCAG 3.3.3 is written around providing suggestions to the user.
Tone and humor
Match the message to your brand voice, but keep clarity first. NN/g’s guidance is specific: “Avoid humor since it can become stale if users encounter the error frequently.” Even a playful brand’s style guide agrees; Mailchimp’s voice and tone guide says “it’s always more important to be clear than entertaining” and “If you’re unsure, keep a straight face.” The narrow exception NN/g describes is a rare, catastrophic failure, such as overloaded servers, where an apology combined with something surprising may soften a bad moment. A 404 page has more room for personality than a payment error, as long as the way forward stays more prominent than the joke.
404 pages: helpful content and the right status code
A useful 404 page offers a search box, links to the most visited sections, and the main navigation. Whatever it looks like, it must still return a 404 or 410 status code. Google’s documentation on HTTP status codes says that when a page returns a 2xx status but “the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” A designed “not found” page served with a 200 status creates exactly that problem.
Questions teams ask
What if we don’t know what caused the error ourselves?
Say so plainly: “Something unexpected happened. We’re looking into it.” Offer a way to contact support or try again, and make sure the error is logged with enough detail for the team to investigate. An invented explanation is worse than admitting you do not know yet.
Our developers want error codes shown for support. How do we include them?
Lead with plain language and put the code last, in small text, as a reference: “Reference: ERR-2847.” The heuristic’s “no error codes” is about the message itself; a reference for support at the end does not replace the explanation.
How do we keep error messages good over time?
Review them on a schedule. Read support tickets for messages people misunderstand, check which errors are followed by people leaving, and include error states in usability tests alongside the main path.
Write each message to say what happened and what to do next in the user’s words, show it only after the person has finished a field or submitted, place it beside the field with a linked summary when there are several, announce it to screen readers, and keep the 404 status on your 404 page.