Designing Better Error Messages UX — Smashing Magazine

Why Error Message Placement Matters

Error messages are one of those interface elements that rarely get attention during the design phase — until a validation failure sends a user into confusion. But thoughtful error design can be a business differentiator, especially when abandonment rates are high. When things go wrong, the quality of the error message often determines whether users push through or give up entirely.

Errors aren't limited to web forms, of course. They appear in complex tables, incompatible filter combinations, search queries, and failed interactions. They can be short inline notes or lengthy error summaries, subtle tooltips or floating toast notifications. Before deciding on a style, it helps to understand what kind of error you're dealing with.

As Page Laubheimer has pointed out, there are two distinct types of errors. Slips happen when users intend to do one thing but do another — filling in a form on autopilot, for example. Mistakes occur when a user's mental model doesn't match the system's behavior. Both need different support, and slips are typically easier to resolve.

Designing for Slips and Mistakes

For slips, helpful constraints go a long way: a reasonable input width, prefixes and suffixes on fields, autocomplete suggestions, sensible defaults, and forgiving formatting all reduce the chance of accidental errors.

Mistakes require a different approach. Confirm destructive actions, set expectations early (password requirements, file size limits), and always provide a way for users to change their minds. Measure success with error-focused KPIs tracked over time:

• Average number of mistakes per user journey
• Error recovery time
• Completion rates
• Completion times

No human input is bulletproof, so mistakes can't be eliminated entirely. But making errors harder to commit in the first place is always a good investment.

Beyond the Red Text Cliché

Red text is the default error styling, but it's rarely sufficient on its own. Users with color vision deficiencies may not perceive the error state at all. Always pair color with another visual indicator — typically an icon such as an exclamation mark on a red background, placed right next to the message.

Another approach is to highlight the entire error context: the field, label, hint, error message, and input. The Gov.uk design system uses a thick red vertical line next to the error message, which is a proven pattern for making errors unmistakable.

Some designs place the error icon inside the input field itself. If it sits on the right edge, users who zoom in and out of the page may lose track of it. Positioning the icon on the left edge tends to be more reliable.

An error summary can guide users to problem areas in a longer form. Typically placed at the top of the page or just above the action button, the summary provides links that let users jump directly to each error. One location to avoid is under the submit button — in user testing, error summaries placed there show poor discovery rates. Users keep clicking submit, unaware that feedback is already present.

If the page refreshes on validation, the error summary belongs at the very top. For validation without a page refresh, position the summary just above the action button, highlighted with color and an icon.

Avoid Auto-Scrolling and Overlay Tooltips

Should the page auto-scroll to the first error after a failed submit? There's no universal answer. This pattern works well for some users but frustrates others, as any sudden page movement can disorient people. If anything, auto-scrolling is less jarring than an auto-jump, since it at least communicates direction of movement.

Best to start without auto-scrolling — just display an error summary with links. Add auto-scrolling only if testing shows it's needed. Moving users around the page without an obvious reason just increases completion times and confusion.

Users confronting an error need to see three things at once: the input field, the error message, and any help content explaining how to fix the problem. Tooltips that open on hover make this difficult — once open, they can cover both the input and the message. The fix: trigger tooltips only on click or tap, never on hover, and require manual dismissal.

A better alternative for many cases is a details component or inline accordion. This lets content expand between the label and surrounding content without covering anything — error messages stay visible next to the input at all times, and all three pieces of information remain in view. Users can choose what they need to see.

Where to Position Error Messages in Forms and Tables

Error messages conventionally sit under the input field, occasionally to its right. Both positions carry accessibility concerns:

• Users of magnifying software may miss messages on the right.
• On mobile, the virtual keyboard can cover messages positioned beneath inputs.
• During editing, browser autofill or autocomplete suggestions may obscure the message.

Placing error messages above input fields avoids these issues, though at the cost of layout shifts — each new error pushes content down as space opens for the message. That movement can be noisy, but it's often worth the trade-off for accessibility. For lengthy messages, resist the urge to use tooltips; a collapsible accordion is a better fit.

Tables present a different challenge, where inline messages per row would cause excessive layout shifts. A simpler pattern: show the error message in the same row, typically under the input. Long messages can be collapsed and expanded by clicking the row.

When one error affects multiple rows, highlight the rows concerned and display an explanation at the top of the page, clarifying what went wrong and how to fix it.

The Problem with Toast Error Messages

Toast notifications — those floating messages that animate in and out — frequent enterprise dashboards and tables. But as error messages, they have significant flaws:

• Users often don't finish reading before the toast disappears, with no way to bring it back.
• Toasts appear at screen edges, typically far from the input that triggered the error — making it hard to read and correct simultaneously.
• Long toasts block content, sometimes covering the very input that needs editing.
• Screen reader users need to be announced when toasts appear and must be able to move focus between the message and the erroneous input.
• Toast space rarely accommodates rich help — images or videos are out of the question, and links to external help pages are a poor substitute.

If toasts must carry actionable information, they should persist until manually dismissed. Still, error messages are generally better off designed as toasts at all. The stronger the visual connection between an error and its cause, the less likely it is to be missed. The closer the explanation sits to the input box in question, the faster users understand what to do about it.

Don't Let Validators Turn Customers Away

An aggressive address validator at checkout can be a hard stop. A customer who has lived at their address for years is suddenly told it doesn't exist. Their only option is to change the delivery destination or abandon the purchase entirely — a 100% abandonment rate for that user. No validation library is ever 100% reliable for every edge case, so some percentage of customers will always get stuck.

Aggressive validators cost money, especially when paired with disabled buttons that leave users guessing what went wrong. Where a validator is too strict, let customers override the warning. Some incorrect addresses will get through, but businesses should weigh the increased service-desk load against the revenue gained from letting legitimate customers proceed.

The override pattern suits address and telephone inputs well. It breaks down for data that must follow a strict format, such as IBAN or credit card numbers, which need meticulous checking and guidance toward the exact problem.

Choose Words That Point Toward a Fix

A generic message saying an input is wrong does little to help. Truly useful errors indicate solutions. Establishing stop-words early in an interface project clarifies the product's voice and tone. This work can shape how all body copy and labels sound, not just error text.

Gov.uk maintains a shortlist of words and phrases it omits from error messages:

• Technical jargon like form post error, unspecified error, or error codes;
• Accusatory or legalistic phrasing: forbidden, illegal, you forgot, or prohibited;
• Please, since it implies a choice;
• Sorry, which does not solve the problem;
• Valid and invalid, as they add no meaning;
• Informal filler such as oops;

Crafting careful, adaptive messages is a direct investment in reducing abandonment and lifting conversions.

Show What Correct Input Looks Like

The best error message often walks users toward the right answer. A hint under the field label with an example gives them a concrete target. For complex inputs that won't be auto-filled, this guidance is essential — without it, a simple typo like an extra empty space can become an unconquerable barrier. Demonstrating the correct format is frequently the easiest conversion improvement available.

Summarize Errors Near the Submit Button

When validating on submit, users should not need to be shuttled to a separate results page. An error summary placed next to the Submit button keeps context clear. Position it above the button to stay within the viewport.

For multiple problems, an error summary component can list each issue as a link so keyboard users can jump to the relevant field. The page should move focus to the first failing field, using a bit of scroll-margin-top so the location remains obvious to screen reader users. If errors appear, updating the favicon and page title informs users who have already navigated away — assuming they can still recover the tab.

Applying These Patterns

Error-handling details determine whether a form causes friction or helps people move on. A practical checklist to keep nearby:

• Measure error recovery by defining KPIs around mistakes per journey, recovery time, completion rates, and completion time.
• Use icons, borders, and section highlights alongside color to mark errors.
• Present messages above input to avoid conflicts with autofill, magnifiers, and virtual keyboards.
• Use inline validation selectively — strength meters are fine, but let users complete most fields, and validate that step only on submit.
• Keep errors inside table rows rather than relying on toasts.
• Provide usable examples of correct input whenever format matters.
• Allow overrides for address and phone fields, but not for convention-bound inputs.

Even small steps help. If a validator-or-live-validation overhaul isn't feasible, replacing generic messages with useful ones is a modest change with outsized results shown in any conversion dashboard.