Error messages are often the last thing a designer thinks about and the first thing a user reads when something goes wrong. A bad one turns a recoverable situation into an abandoned session. A good one keeps the user in the flow and moving forward.
Why Most Error Messages Fail
Most error messages fail at the same point: they describe the system’s state instead of the user’s problem. “Error 403: Forbidden” is accurate but useless. “Request timeout” tells the user what happened but not what to do. These messages optimise for logging, not for recovery.
The pattern is consistent across codebases. Developers write the happy path first, then add error handling as a cleanup task. By the time errors are being handled, no one is thinking about the person who will read the message at 11pm on their phone trying to pay a bill.
What a Good Error Message Contains
A useful error message does three things.
Confirms what failed, in plain terms. Not the technical cause, but the user-facing consequence. “We couldn’t process your payment” is better than “Transaction declined by issuer.”
Explains why, if the user can act on the reason. If the reason is something they can fix, state it. If it’s a server error they can do nothing about, skip the why and go straight to what’s next.
Gives a clear next step. This is the part most error messages omit entirely. “Please try again” is a step. “Check that your card’s billing address matches what your bank has on file” is a better one.
The test of a good error message is simple: can the user read it and immediately know what to do? If not, it’s a system log entry masquerading as communication.
Tone matters too. Error states are moments of friction and sometimes frustration. A clinical or dismissive voice makes it worse. Neutral and direct lands best.
Three Failure Modes
Most error messages sit in one of three categories.
Too vague. “Something went wrong.” Users cannot act on this. Vague messages force a support ticket or an abandoned session. If you genuinely can’t surface what went wrong, at minimum tell the user what to try next.
Too technical. “CORS policy blocked this request” or a raw stack trace belong in logs, not in UI. Filter error details by audience. Developers using an API need more detail. Consumer-facing products do not.
Too passive. Many error messages describe a failure without providing resolution. “Your session has expired” is a statement. “Your session expired. Sign in again to continue where you left off” is a handhold.
Placement and Timing
When an error message appears matters as much as what it says.
Premature validation. Flagging an email as invalid before the user finishes typing is not helpful. Validate on blur, when the user leaves the field, or on submit. This is worth careful attention when working on forms that are meant to convert, where every point of friction compounds dropout.
Too far from the cause. A validation error at the top of the page for a field at the bottom creates a discovery problem. Errors should sit adjacent to what caused them. In a long form, a summary at the top works when it also links to each offending field.
Silent failures. Async operations that fail without any feedback are a particular risk. A file upload that fails and renders nothing, a payment that times out and shows no state: both leave the user stuck. Notifications and toasts handle these cases well, but only if the system sends them on failure, not just on success.
Writing the Copy
A few rules that hold across every context.
Use plain language. “Invalid credentials” means nothing to most users. “That email and password combination doesn’t match our records” says the same thing in terms a person understands.
Don’t blame the user. “You entered an invalid date” versus “We couldn’t read that date. Try DD/MM/YYYY.” The second version conveys the same problem without implicating the person who hit a date format they weren’t warned about.
Be specific when the fix is specific. “Your password must contain at least 8 characters, including one uppercase letter and one number” is more useful than “Your password doesn’t meet requirements.” Don’t make the user guess the rule.
Provide an escape hatch. For errors the user can’t fix themselves, link to help content or offer a way to contact someone. A dead end is worse than an imperfect resolution. It’s the same instinct behind designing empty states well: if there’s nothing to show or nothing the user can do alone, give them a path forward.
Error Copy in Design Systems
Most design systems define error state styling and leave copy as an afterthought. Component libraries show red borders and warning icons. They rarely ship example messages for common scenarios.
A payment form, an authentication flow, an upload component: each has a known set of failure modes. Writing canonical error messages for those modes and putting them in the design system documentation, alongside the component, means the whole product team is working from the same script. Errors stop being incidental and become designed.
It also reduces the support burden. When users know what went wrong and what to try, fewer of them send emails.
One place this often falls short is modal and dialog flows, where a destructive or irreversible action fails partway through. The error state in that context needs even more care, because the user is already mid-decision and the stakes feel higher.
How Strynal Approaches Error Messages
At Strynal, error states are part of the component design, not a post-launch addition. When we build an interface through our UI/UX service, every interactive component ships with its failure states defined: what the message says, where it sits, and how it behaves across breakpoints.
That means error copy gets reviewed alongside layout and interaction. The microcopy for an inline validation message gets the same attention as the headline copy on the page.
If your product has error states that are doing more harm than good, or if you’re starting from scratch and want it done properly, get in touch and we’ll work through it with you.