{"id":7480,"date":"2020-03-02T15:06:30","date_gmt":"2020-03-02T15:06:30","guid":{"rendered":"https:\/\/blog.tubikstudio.com\/?p=7480"},"modified":"2026-05-11T14:24:18","modified_gmt":"2026-05-11T14:24:18","slug":"error-screens-and-messages","status":"publish","type":"post","link":"https:\/\/tubikstudio.com\/blog\/error-screens-and-messages\/","title":{"rendered":"UX Design for Error States: The Art of Failing Well"},"content":{"rendered":"

There’s a moment every designer quietly dreads. Not a crash, not a blank screen, something subtler: the look on a user’s face when something goes wrong and the interface offers nothing useful in return. No explanation, just the digital equivalent of a shrug.<\/span><\/p>\n

Whether we, as designers, want it or not, errors are part of the product. The question is not whether your users will encounter them; it’s whether your error state design is ready when they do.<\/span><\/p>\n

Now, let’s dig deeper.<\/span><\/p>\n

What an Error Actually Is<\/span><\/h2>\n

Before fixing something, name it precisely. An interface error is any state where the interface cannot do what the user wants. That breaks down into three honest scenarios:<\/span><\/p>\n

The platform literally cannot do what’s being asked\u2014the function doesn’t exist, the server is down, the file format isn’t supported. The system cannot understand the input\u2014a field expects a number and got a sentence, an email address is missing the @, a password doesn’t meet requirements the user never knew about. Or the user is combining things that can’t coexist\u2014operations that conflict in ways that are invisible from the outside.<\/span><\/p>\n

Three different problems. Three different types of communication required. Grouping them into a single “error” category and responding to all three identically is where most design systems start to crack.<\/span><\/p>\n

What makes this genuinely serious: errors aren’t neutral. Research<\/a> connecting smartphone error messages to cortisol levels\u2014the body’s stress biomarker\u2014found a measurable physiological response to a bad error state. For some users, in some moments, a confusing UI error message triggers real anxiety and raises cognitive load significantly. It makes them stop trying. It costs you not just a conversion but a relationship.<\/span><\/p>\n

Design for that reality, not the ideal one.<\/span><\/p>\n

\"email<\/p>\n

This is how the error of filling the subscription form on our website looks<\/em><\/p>\n

Design Principles for Errors That Don’t Insult People<\/span><\/h2>\n

There’s no single moment where users decide they’re done with a product\u2014it’s a series of small failures that stack up. Here’s how to make sure UX error states aren’t one of them.<\/span><\/p>\n

Make It Impossible to Miss<\/span><\/h3>\n

The worst error is a silent one. The second worst is one that’s easy to overlook.<\/span><\/p>\n

If a form has ten fields and one is invalid, do not tell the user “something went wrong” and make them play detective. Highlight the broken field. Put the message next to the problem, not at the top of the page in a banner they’ve already scrolled past. Error visibility is about respect for someone’s time\u2014and it’s one of the most fundamental UX design principles there is.<\/span><\/p>\n

Yes, the red border might disturb your minimalist composition. But the composition doesn’t matter if the product doesn’t work.<\/span><\/p>\n

Use Signals People Already Know<\/span><\/h3>\n

Designers love novelty. Error states are the wrong place for it.<\/span><\/p>\n

Red and exclamation marks exist for a reason: decades of learned behavior mean users process them instantly, without thinking. That instant processing is exactly what you want when someone is already in a moment of friction. Use the conventions. Save your creative energy for places where originality adds value.<\/span><\/p>\n

One important caveat: color<\/a> alone is never sufficient. A red border that’s the only indicator of an error is invisible to colorblind users. Pair color with iconography. Pair both with text. Redundancy here means accessible error message design\u2014it’s an inclusive UX design requirement. Ignoring it means failing WCAG error indicator standards and locking out a significant portion of your users.<\/span><\/p>\n

\"art<\/p>\n

Explain What Happened, Not Just That Something Did<\/span><\/h3>\n

“Invalid input” is not an explanation. “The username or password don’t match” is.<\/span><\/p>\n

The difference between those two messages is the difference between a user who tries again and a user who gives up. When someone doesn’t understand what went wrong, they can’t fix it\u2014and they’re likely to hit the same wall again. Worse, they start to feel confused and incompetent, which they will attribute to the product (and rightfully so).<\/span><\/p>\n

This is where UX writing<\/a> for errors does its real work. Explain the problem in plain language, not a developer or legal one. The language of the actual human who is standing there, holding their phone, trying to log in before their meeting starts, the train arrives, or the coffee goes cold. Plain language UX isn’t dumbing things down\u2014it’s showing respect.<\/span><\/p>\n

Keep the Interaction Minimal<\/span><\/h3>\n

The instinct when something breaks is to escalate: pop a modal, add a full error screen, demand acknowledgment before proceeding. Resist this almost every time.<\/span><\/p>\n

Inline validation\u2014a message that appears immediately next to the field or action where the error occurred\u2014is almost always preferable to a modal. A modal requires an extra click to dismiss, interrupts the user’s mental flow, and adds friction at the exact moment when you should be reducing it. Good form validation UX keeps the user in flow; bad form validation pulls them out of it.<\/span><\/p>\n

A modal earns its place only when the error genuinely requires redirecting the user to a different context entirely. In every other case, fix it where it broke.<\/span><\/p>\n

\"tubik<\/p>\n

Write Like a Human Being<\/span><\/h3>\n

Read your error messages out loud. If they sound like they were written by a legal department or generated by a server log, rewrite them.<\/span><\/p>\n

Short sentences. Active voice. No jargon. No error codes (unless there’s a support workflow that requires them\u2014and even then, pair the code with a plain-language explanation). Get to the point immediately; the user doesn’t need a preamble, just a solution.<\/span><\/p>\n

The bar for error message copywriting is not eloquence, it’s clarity. Those are different things, and clarity is harder.<\/span><\/p>\n

Don’t Blame the User<\/span><\/h3>\n

This one seems obvious, but still needs to be said out loud.<\/span><\/p>\n

“You entered an invalid email address” and “Enter a valid email address” contain almost identical information. The difference is that the first assigns fault and the second gives direction. Users already feel friction in an error state\u2014adding blame compounds that feeling into something that erodes user trust in UX. Write every error message as if you’re speaking to someone you respect who made an understandable mistake. Because that’s exactly what’s happening.<\/span><\/p>\n

Be Constructive: Tell Them What to Do Next<\/span><\/h3>\n

Explanation without direction is half the job. Once you’ve told someone what went wrong, tell them how to move forward.<\/span><\/p>\n

On a web interface, this means giving clear paths\u2014back to the homepage, back to the previous step, or directly to the broken element. On mobile UX design, it means making navigation out of the error state effortless, not buried. In multi-step forms, it means surfacing errors at each step rather than presenting a list of failures at the very end, after someone has spent eight minutes filling everything out.<\/span><\/p>\n

The constructive error message is functional\u2014it turns a dead end into a detour. And in terms of conversion rate UX, this single principle can make the difference between a completed form and an abandoned one.<\/span><\/p>\n

\"404<\/p>\n

This 404 page of the\u00a0fashion brand’s e-commerce website<\/a>\u00a0gives the visitor various options to jump to, marking the ability to get back to the home page as the main call-to-action<\/em><\/p>\n

Use Imagery Thoughtfully<\/span><\/h3>\n

Not every error screen needs an illustration<\/a>. But when an image is appropriate\u2014a 404 page design, an empty state design, a major system failure\u2014a well-chosen visual does something text cannot: it shifts the emotional register of the moment.<\/span><\/p>\n

Dribbble’s 404 page is a useful example not because it’s clever (although it is) but because it’s calibrated. They know their audience\u2014designers with visual curiosity\u2014and they give that audience something to engage with instead of just a dead end. The error becomes, briefly, interesting. That’s emotional design at its best: understanding your users well enough to meet them in the moment.<\/span><\/p>\n

The rule: use imagery when it genuinely reduces tension or adds useful context. Avoid it when it becomes decoration on top of a bad experience.<\/span><\/p>\n