Avoid Aggressive Error Messages: UI Design Rules for Better User Experience

Translated from "Hostile Patterns in Error Messages", this article introduces UI design principles for displaying error messages. Showing errors too early, using overly aggressive field styles, or presenting unnecessary disruptive system status information can feel impolite and increase cognitive load.

No one likes to make mistakes—whether in life or when using applications or websites. Mistakes are natural, but they can cause extra work, confusion, or embarrassment.

Jakob Nielsen’s ten usability heuristics include two principles specifically about errors:

Principle 5: Error Prevention – Prevent problems by eliminating error‑prone conditions or providing confirmation before actions with serious consequences.

Principle 9: Help Users Recognize, Diagnose, and Recover from Errors – Error messages should use plain language, clearly explain the problem, offer a solution, and use visual styling to attract attention.

While prioritizing error prevention and recovery is valuable, well‑intentioned designs can go too far, creating overly aggressive patterns that frustrate and distract users.

Follow these two guidelines to avoid excessive error‑prevention and recovery patterns:

Avoid displaying errors too early : Show error messages only after an error has actually occurred.

Use error styling only for errors : Reserve visual treatments like red text or warning icons for critical system states that interrupt the user’s workflow.

The article provides examples and guidance to avoid these pitfalls.

#1: Avoid Displaying Errors Too Early

Premature error messages appear before the user has truly made a mistake or reached a logical point in the workflow.

For example, in form validation, it is ideal to inform users of errors in real time once they actually make a mistake. However, many validation mechanisms are overly eager, showing errors before the user finishes entering a field.

A typical case is triggering an error when a user types "2" in a phone‑number field, which should not be flagged, whereas typing letters would be.

LG’s checkout process shows an error about postal‑code format as soon as the user starts typing, and the message persists until the required number of characters is entered, even though the user has not yet erred.

Labcorp’s payment portal shows "Invalid email address" as soon as a letter is entered in the email field, causing unnecessary interruption.

Sorel’s checkout triggers an inline error "Please enter a valid date" while the user is still entering birth‑date information.

Generally, avoid showing errors before the user leaves a field. Immediate inline validation can feel like unwarranted blame and provoke resentment.

Even more frustrating is when errors appear before any input, either on field focus or by default on page load, giving users no chance to start typing before being warned.

At Conradnewyork.com, clicking the "Last Name" field immediately wraps it in a red border and shows "Please enter last name". Such messages are useful only after a submission attempt, not on mere focus.

Xpress‑pay’s patient payment portal displays "Amount cannot be empty" before any interaction, along with three redundant required‑field indicators (asterisk, exclamation‑icon, red border).

While it’s fine to clearly mark required fields (a single asterisk suffices), redundant visual cues feel confrontational. Inline error "Amount cannot be empty" is appropriate only after the user attempts to submit an incomplete form.

#2: Use Error Styling Only for Errors

Another aggressive pattern is applying error‑like visual treatment to non‑error information.

Non‑critical system status messages should be noticeable but not intrusive.

Critical errors and warnings should be invasive to capture attention, using red text or warning symbols.

In a HR application, the message "No attachment to display" is styled like a warning with yellow background and icon, causing users to pause and wonder if an attachment is required, even though it is optional.

Yellow warnings should be reserved for genuine alerts, such as Amazon Glow’s notification of a failed call.

At Thrift Books checkout, a helpful message about address immutability is displayed with red styling and warning icons, making it appear as an error and prompting unnecessary verification.

Similarly, PayPal’s mobile app uses a gray background and an informational "i" icon for non‑error notices, avoiding aggressive styling.

Conclusion

These aggressive error‑prevention and recovery strategies feel like shouting "You did it wrong!" from behind the user, causing offense and unnecessary frustration.

We should help users, not blame them.

Following these guidelines can support error prevention and recovery without making users feel attacked or ashamed:

Show format‑related errors only after the user leaves the field (e.g., postal code, email address).

Provide constraints early, rather than waiting for input or submission to inform the user.

Mark required fields with a single asterisk or the word "required"; avoid multiple indicators that burden the user. Show additional elements only after a failed submission.

Reserve error‑specific visual treatments (red text, warning icons) for critical system states that interrupt the user.