Error States

Error states communicate failures or invalid inputs with clear explanation and actionable recovery paths.

stellae.design

Design Principles

Error states appear on validation failures, network errors, permission issues, or unexpected conditions. Effective errors follow three parts: what went wrong, why, and how to fix it. They should appear near the error point, use appropriate severity indicators, and never blame the user. Goal is recovery, not just notification.

Why It Matters

Error states are the moments when something goes wrong in an interface — a failed submission, an invalid input, a server timeout, a broken search — and they represent the highest-stakes touchpoints in the entire user experience because they occur precisely when the user is most vulnerable to frustration and abandonment. How a product handles errors communicates more about its quality and respect for users than any marketing copy or onboarding flow ever could, because errors are the moments when the polished surface cracks and the system's true character shows through. Well-designed error states transform potential abandonment moments into trust-building opportunities by showing users that the system anticipated problems and prepared helpful recovery paths.

Real-World Examples

Mailchimp's friendly error illustrations

Mailchimp pairs every error state with a custom illustration, a conversational error message that explains what went wrong in plain language, and a clear call to action that tells users exactly how to recover. The illustrations use the brand's signature humor to defuse frustration without trivializing the problem, and the tone acknowledges the user's situation without assigning blame. This approach turns error moments into brand-building touchpoints where users feel supported rather than abandoned.

GitHub's 404 page with search and navigation

GitHub's 404 page does not just report that a page was not found — it offers a search bar, links to popular repositories, and suggestions for what the user might have been looking for based on the URL pattern. The page treats the error as a navigation problem to solve rather than a dead end to endure, and the search functionality means users can recover their intent without returning to an external search engine. This design acknowledges that 404 errors are often caused by outdated links rather than user mistakes, and responds with empathy rather than blame.

Counter-example

Banking app that shows raw error codes on payment failure

A mobile banking app displays 'Transaction Failed: ERR_PROC_4221_TIMEOUT — Contact system administrator' when a payment does not go through, providing no explanation of what happened, no indication of whether the money was debited, and no clear path to resolution. Users panic because financial transactions demand absolute clarity about the state of their money, and the technical jargon suggests the app was built for engineers rather than the people who depend on it. Many users call customer support in a panic, overwhelming the support team with calls that a well-designed error message would have prevented entirely.

Role-Specific Guidance

Common Mistakes

• The most critical mistake is treating error states as edge cases that do not deserve design attention — teams invest weeks perfecting the happy path and then handle errors with generic 'Something went wrong' messages that leave users stranded without guidance. Another common failure is designing error messages that blame the user ('You entered an invalid email') instead of describing the situation neutrally ('This email format is not recognized — please check for typos'), which creates a hostile tone that compounds the frustration of the error itself. Teams also frequently forget to design for the ambiguous middle state — when a request is in progress and the user does not know whether to wait or retry — which leads to duplicate submissions, lost data, and the most corrosive form of user anxiety.