The most expensive sentence in your product – and why bad error messages aren't sloppiness, they're an interest payment that rises every year.
The short version: Error states hit exactly the people who were about to pay, book or submit. They still get designed nowhere: they appear in no concept and no acceptance criteria, so a developer ends up typing them into the code window on the side while actually building the feature. The result isn't a design problem, it's a cost problem that compounds: every incomprehensible message generates support contacts, and Gartner puts the median cost of a live-channel contact at $13.50. Rewriting the message costs twenty minutes, once. The phone call costs you every single time.
Take a proper look at this sentence:
A technical error has occurred. Please try again later.
At that moment the user has four questions:
- What happened?
- Was it my fault?
- Is my data gone?
- When is "later"?
Zero get answered. The sentence contains exactly one piece of information — that something is broken — and the user already had that before reading it.
Which is precisely why it's the default message: it's the only statement that's always true if you don't want to know anything about the situation. It isn't communication. It's a shrug in the corporate typeface.
And it never appears at a harmless moment. Error messages don't show up while someone is idly scrolling. They show up when someone wanted to do something: submit, pay, book, apply. Error states reliably hit the users with the highest intent. Which is to say: the most valuable ones you have that day.
1. The Part Everyone Skips: What This Costs
I'm deliberately not starting with copy examples. I'm starting with money, because this is where projects look away, systematically.
Bad error communication isn't an ugliness. It's a standing liability. And one you never shed, because it's never paid off: every message nobody understands costs you not once, but with every single user who sees it — in a different cost centre, where nobody connects it back to the source.
That's the difference from a loan. A loan gets repaid eventually. This keeps running, and the amount grows the better your product does.
The instalments are called: phone call, ticket, chat transcript, email to support, question to a colleague, abandonment.
Some defensible numbers.
Gartner puts the median cost of a contact in an assisted channel — phone, chat, email — at $13.50, while a successfully completed self-service interaction lands around $1.84. An earlier survey in the same series put live contact at $8.01 against roughly 10 cents for self-service. Gartner on the cost difference. The exact figure varies by sector and country. The order of magnitude doesn't: a human on the phone costs a multiple of what a self-explanatory screen costs.
Now the calculation you can run yourself.
Say your application handles 100,000 relevant transactions a month. Two percent run into an error state — that isn't much. That's 2,000 cases. A fifth of those contact support because the message didn't help: 400 contacts. At €12 per contact — conservative, measured against the numbers above — that's €4,800 a month. €57,600 a year.
For a handful of sentences nobody ever wrote.
And now the part that appears in no presentation:
These costs grow with your success. More users means more error cases means more contacts. The design work, meanwhile, happens exactly once. So you've traded a recurring, growing expense against a one-off investment — in the wrong direction. Whoever scales, scales the problem too.
And you're paying in several places at once:
- Support. Every contact that exists only because a screen explained nothing.
- Second level and engineering. When the error code means nothing to the user and nothing to support either, the case lands with the people whose hour costs the most.
- Abandonment. The share that never gets in touch and simply leaves. It appears in no ticketing system — the most expensive cases are the ones you never see.
- Repeated failed attempts. Every failed try generates load, logs and sometimes junk data in your systems.
- Trust. Soft but real: a user who lost their input once will not fill in a long form a second time.
- Internal onboarding. In business applications there's an extra layer: every cryptic message becomes part of the tribal knowledge new staff have to acquire the hard way. That's training cost you built yourself.
The bitter part: error messages are the cheapest repair in the entire product lifecycle. No refactoring, no migration, no new architecture. Usually: change the text, attach the message to the right field, add a button. Days, not months.
Ask your support team for the ten most common contact reasons. If at least three of them don't trace back to a screen that explained nothing, I'll eat my notebook.
2. What's Missing From That Standard Sentence
Back to the classic. A usable error message answers four things:
What happened — in the user's language. Not "transaction declined" but "your bank declined the payment." Same fact, entirely different information.
What about my data? The most important and least frequently answered question. "Your input has been saved" removes ninety percent of the panic. One sentence.
What can I do now? Every message needs a next step. Try again, use another route, contact support, come back later — but something. A dead end with an "OK" button isn't communication, it's an eviction.
When, if not now? "Try again later" isn't a time. "In about ten minutes" or "we're working on it, status here" is.
None of this is my invention. At its core it's the ninth of Jakob Nielsen's usability heuristics — users should be able to recognise, diagnose and recover from errors — and the Nielsen Norman Group has turned it into twelve very concrete rules. Error-message guidelines at NN/g.
3. Error Codes: Not the Problem, Rarely the Solution
ERR_5031 is a message to the engineering team that was accidentally delivered to the customer.
Even so, I'm not against error codes. They're useful — in support. A code a user can read out shortens every call. The only question is whether the code is the message or whether it accompanies it.
Wrong: the code is the message.
Right: plain language at the top, the action option in the middle, the code small underneath, copyable.
Two conditions for a code to do its job:
- Support can look it up — without calling engineering.
- It's unambiguous. A code triggered by five different causes is decoration.
And HTTP status codes generally don't belong in the interface. "500 Internal Server Error" is about as useful to someone without an IT background as an error message in Latin. It isn't even mistranslated — it simply wasn't written for them.
4. Whose Fault Is It Anyway?
Three states get muddled constantly:
System errors. Server gone, interface dead, timeout. The user isn't responsible and usually can't do anything about it. This is where an apology and a statement of what happens next belong.
User errors. Wrong format, missing required field, invalid combination. This is where instruction belongs, not a lecture.
Expected states. Account locked, item out of stock, slot taken. These aren't errors, they're outcomes. They still get rendered in red, because in the code it was the same branch.
And then there's the category that annoys me most: errors you cause and blame on the user. "Invalid input" for a format you never documented anywhere. The rejected IBAN with spaces in it, even though every bank statement prints it with spaces. The date field that only accepts DD.MM.YYYY and rejects 1.3.2026.
That isn't user error. That's system error with an accusation attached.
5. Tone
Error messages are the one moment your brand speaks to somebody who is already annoyed. Treat the tone accordingly.
What doesn't work:
- The passive voice. "An error has occurred" — spontaneously, apparently.
- Blame. "You have entered an invalid number." Nobody talks like that outside a government office.
- Legalese. "The processing of your request could not be completed."
- Jokes in the wrong place. "Oops! Something went wrong 🙈" — on a failed payment that isn't sympathy, it's mockery. Humour belongs on a 404 page. Not in a payment flow.
What works: factual, specific, no finger-wagging. Not "invalid format" but "the IBAN has 22 characters, yours has 20." The user immediately knows what to do and doesn't feel like an idiot doing it.
One rule that almost always holds: take the word from the label and put it in the message. If the field says "date of birth," the message says "enter your date of birth" — not "required field."
6. The Most Expensive Error of All: Deleted Input
If a form discards input after an error, nothing else matters.
I've seen this repeatedly in projects, usually unintentionally, usually caused by a reload after server-side validation. The user has invested eight minutes, gets a red message and an empty form. From that point it's no longer about usability, it's about whether they come back at all.
The same goes for sessions that expire after fifteen minutes without warning, and for uploads discarded entirely because of one invalid field.
The rule: an error must never destroy work. If you take one sentence away from this whole piece, take that one.
7. Where the Message Sits and When It Arrives
Where: At the field. Not in a red box at the top that the user has to scroll up to, then scroll back down from, guessing which field was meant. On long flows, add an error summary at the top of the page whose entries link as jump marks to the relevant field. The pattern is fully documented in the GOV.UK Design System and the NHS Service Manual, including focus behaviour for screen readers — you only have to copy it. Error summary in the NHS Service Manual.
When: After leaving the field. Not while typing — anyone who sees "invalid email address" after two letters is being told off by their own software before finishing a thought. And not only on submit, because then everything arrives at once.
There's a widely cited study on the effect, by Luke Wroblewski and Etre from 2009: inline validation produced 22 percent more successful completions, 22 percent fewer errors and noticeably shorter completion times. Results at LukeW. In fairness: small sample, one form type, over fifteen years old. I cite the numbers as an indication, not a law of nature — and on a long flow I'd measure it myself anyway.
8. The Screens That Appear in No Concept
Lay out your design files and go looking for: 404. 500. Timeout. Offline. Maintenance window. Session expired. Empty state after a search with no results.
In nine out of ten projects these screens aren't there. Not because someone decided to leave them out — because nobody ordered them. They're in no flowchart, because flowcharts describe the happy path. They're in no acceptance criteria. They get generated at runtime, by the framework's default output.
That's the real finding of this article: bad error states aren't a quality problem with individual people. They're a process problem. Nobody is responsible, so it happens on the side, at two in the morning, by someone who was trying to solve a different problem.
Anyone who wants to change that doesn't need a design philosophy, they need one line in the definition of done: no feature is finished until the error case has been designed.
9. And Since the BFSG, It's Also Mandatory
The Web Content Accessibility Guidelines are quite explicit about errors:
- 3.3.1 Error Identification: a detected error must be described in text — colour alone isn't enough.
- 3.3.2 Labels or Instructions: if input requires a particular format, that has to be stated up front.
- 3.3.3 Error Suggestion: if the system knows a correction, it has to offer it.
- 3.3.4 Error Prevention: for legal and financial transactions, input must be reversible, checkable or confirmable.
Those are conformance levels A and AA — precisely what EN 301 549 and therefore Germany's Accessibility Strengthening Act (BFSG, in force since June 2025) point to. W3C quick reference.
This doesn't necessarily catch the generic server error — often there genuinely is no suggestion to make. But anything involving input, it does: a red-outlined field with no text violates 3.3.1. An "invalid input" where the system knows the expected format violates 3.3.3. Both sit in every second product I look at. At that point it's not just bad communication, it's a checkpoint you fail.
10. What You Can Actually Do
1. Collect your error messages. All of them. In one table. Most products turn out to have between 40 and 300, and nobody in the building has ever seen them together. That list alone is half a day's work and reliably raises the first uncomfortable question.
2. Sort by frequency, not alphabetically. The top ten almost always account for the bulk of the volume. Start there.
3. Build a scorecard. What happened, what about my data, what can I do, how long will it take. Four columns. Any message that doesn't answer all four gets rewritten.
4. Connect the list to your support contact reasons. This is the step that turns a design task into a business case. Most frequent contact reason times cost per contact — there's your funding request.
5. Put error states in the definition of done. Otherwise this all happens again in a year.
6. Measure afterwards. Number of contacts on that topic, before and after. Exactly one slide. That slide decides whether there's budget next time.
Why You Can Take My Word for It
I'm Tobias Adam, a freelance UX designer in Hamburg, more than ten years in digital product development.
I learned the craft agency-side, including at Jung von Matt and deepblue networks. I've worked for BMW, Audi, FIFA, Union Investment, Vodafone, OBI and Deutsche Messe, among others. Over 20 awards, including Webby, ADC and Cannes.
The awards came for the visible work. It always got interesting with the invisible kind. The VisualVest account opening in the Union Investment orbit, for instance: when something goes wrong in a regulated flow, the error message isn't a line of copy, it's the question of whether someone still trusts a financial product with their money. Or a digital future planner, so far unpublished, where the same point sat differently: how much may a system correct before it patronises?
After that it runs through everything: signups, applications, onboardings, internal systems. Error states are the part I most often write down for the first time in a project's history.
Today I work freelance and together with HC Merkle as intro.team — two freelancers for the phase where an idea becomes a testable product: concept, UX, UI, prototype, user testing. Short cycles, senior staffing, no agency apparatus.
The Short Version
- Errors hit the users with the highest intent. The most valuable ones you have.
- Every unclear message is a standing liability. It never gets paid off, and the amount grows with every new user.
- "A technical error occurred, please try again later" answers nothing. Delete that sentence from your product.
- Four questions need answering: what happened, what about my data, what can I do, how long will it take.
- Error codes accompany the message, they don't replace it. And status codes don't belong in the interface.
- Don't confuse user errors with your own. A rejected IBAN with spaces is your problem.
- An error must never destroy work. No wiped forms, no silent session timeouts.
- Message at the field, summary with jump marks at the top, validation on leaving the field.
- 404, 500, timeout and offline belong in the concept, not in the framework's default output.
- No feature is finished until the error case is designed. Put it in the definition of done.
A product doesn't show what it's worth when things work. It shows it in the moment they don't.
Previously in this series: forms, field count and smart defaults — B2B software and internal tools.
Sources and Further Reading
- Nielsen Norman Group: Error-Message Guidelines – nngroup.com
- Nielsen Norman Group: 10 Design Guidelines for Reporting Errors in Forms – nngroup.com
- Jakob Nielsen: 10 Usability Heuristics for User Interface Design – nngroup.com
- Gartner: cost per contact across live and self-service channels – gartner.com
- Luke Wroblewski / Etre: Testing Real Time Feedback in Web Forms (2009) – lukew.com
- NHS Digital Service Manual: Error summary – service-manual.nhs.uk
- GOV.UK Design System: Error summary – design-system.service.gov.uk
- W3C: WCAG 2.1 Quick Reference, section 3.3 – w3.org
- Barrierefreiheitsstärkungsgesetz (BFSG), in force since 28 June 2025 – bfsg-gesetz.de