Loading…
Loading…
Error messages are the most critical microcopy in any product. They appear when users are already frustrated, confused, or anxious. A well-crafted error message transforms a negative moment into a recoverable one. The best error messages follow a three-part structure: what happened, why it happened, and what to do next.
stellae.design
Error messages communicate system failures, validation issues, and access problems to users. They're high-stakes moments because users are already in a negative emotional state when they encounter them.
Before/after examples: • Before: 'Error 500' → After: 'Something went wrong on our end. We're looking into it. Try again in a few minutes.' • Before: 'Invalid password' → After: 'That password doesn't match our records. Try again or reset your password.' • Before: 'Form submission failed' → After: 'We couldn't save your changes because you're offline. Your work is saved locally — we'll sync when you're back online.'
Error messages are the critical communication layer between a system and its users when something goes wrong — they explain what happened, why it happened, and what the user can do next, making them one of the highest-leverage pieces of microcopy in any digital product. Poorly written error messages are a leading cause of user abandonment, support ticket volume, and loss of trust, because when users encounter a problem and the interface responds with cryptic jargon or vague blame, they feel helpless and frustrated rather than guided toward resolution. Well-crafted error messages transform failure moments into recovery moments, preserving user confidence and reducing the operational cost of support by empowering users to fix problems themselves without ever leaving the interface.
Stripe's payment forms display error messages inline next to the specific field that has a problem, using plain language that tells the user exactly what to fix — 'Your card number is incomplete' rather than 'Invalid input in field 3' — and the message appears the moment the user moves to the next field, not after they submit the entire form. This approach reduces payment form abandonment by catching errors early and guiding correction in context, so users never face a wall of red text after a failed submission. The messages are written from the user's perspective and always suggest a concrete next step, making recovery feel effortless rather than punishing.
GitHub's error pages combine a clear explanation of what went wrong with a lighthearted illustration and helpful navigation options — the 404 page acknowledges the broken link, offers search functionality, and provides links to common destinations rather than simply stating 'Page Not Found' and leaving the user stranded. This design transforms a frustrating dead-end into a gentle redirect, preserving the user's momentum and reducing the likelihood that they leave the site entirely. The tone matches GitHub's brand personality without minimizing the user's problem, striking the balance between friendly and functional.
A mobile banking application displays errors like 'Transaction failed: ERR_TIMEOUT_504_GATEWAY — contact system administrator' when a payment does not process, providing no indication of whether the money was actually deducted, whether the user should retry, or who the 'system administrator' is in the context of a consumer banking app. Users screenshot these messages and flood customer support channels because the error gives them no confidence about the state of their money and no path to resolution, creating both user anxiety and operational cost. The technical error code is meaningless to the user and the instruction to contact an administrator reveals that the error handling was designed for internal IT staff and never adapted for the consumer-facing product.
• The most pervasive mistake is writing error messages from the system's perspective rather than the user's — teams default to surfacing what the code encountered ('Null reference exception in module X') instead of what the user needs to know ('We could not load your project — please try again'), because developers write error strings at the same time they write error handling logic and naturally think in system terms. Another common failure is using vague, unhelpful messages like 'Something went wrong' with no recovery path, which technically avoids exposing system internals but leaves the user equally stranded because they have no idea whether to retry, change their input, or give up. Teams also frequently neglect to test error messages under realistic failure conditions, meaning the copy reads well in a design review but falls apart when users encounter it during the stress and confusion of an actual error.
Was this article helpful?