--- title: "Error Messages That Actually Help: UX Writing for Common Error Cases" url: "https://insideuxdesign.com/en/blog/error-messages-that-actually-help-ux-writing-for-common-error-cases" language: "en" description: "What happened, and what now? Learn to write error messages that help: rules for tone and placement plus ten before-and-after examples you can reuse." published: "2025-07-09T09:00:00+02:00" updated: "2026-10-15T00:38:52+02:00" --- # Error Messages That Actually Help: UX Writing for Common Error Cases What happened, and what now? How good error messages are structured, which tone works, and what ten common error messages look like before and after a rewrite. It’s just before midnight, and the train leaves at 6:12 the next morning. The connection is selected, the credit card details are in, the “Buy now” button has been pressed. Then a grey box appears: “An error has occurred. Error code: ERR\_PAY\_4021.” Below it, a single button: “OK”. Now what? Was the card charged? Is there a ticket or not? Is it worth trying again, or will that mean paying twice? The message answers none of these questions. All it does is report that the system has a problem, and then hand that problem, unfiltered, to someone who simply wanted to buy a ticket. Error messages are among the most frequently read texts in any product, and among the least cared for. They’re often written late, often straight into the code, and often without anyone from design or content ever seeing them. Yet they appear exactly when people are frustrated, unsure or short on time. A good error message can defuse that moment. A bad one turns a small problem into an abandoned task or a call to support. This article shows what an error message needs to do, which tone works, and what good copy looks like for ten common error cases, each with a before and after version. ## Why so many error messages don’t help Most bad error messages share the same root cause: they’re written from the system’s point of view, not from the point of view of the people using it. The system knows that a request returned status code 500, that a token has expired or that a required field was empty. So that’s exactly what it says. For developers, that information is valuable. For everyone else, it’s noise. The Nielsen Norman Group (NN/g) captured this in its ten usability heuristics. Heuristic number 9 reads: help users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language, precisely indicate the problem and constructively suggest a solution. The [10 usability heuristics](https://insideuxdesign.com/en/ressourcen/10-usability-heuristics) are a good yardstick for any interface, and error messages are one of the quickest places to test them. Error copy is a classic case of [UX writing](https://insideuxdesign.com/en/glossar/ux-writing), the practice of writing text that guides people through an interface. It belongs to [microcopy](https://insideuxdesign.com/en/glossar/microcopy): short pieces of text such as button labels, hints and messages that have little space but carry a lot of weight. Because they’re so short, every word counts. ## What a good error message answers A helpful error message answers the questions someone is asking at that moment. Usually there are three, sometimes four. ### 1. What happened? The message names the problem specifically. “An error occurred” is true, but it says nothing. In its error-message guidelines, NN/g explicitly calls out generic messages like this as lacking context. Better: “Your payment didn’t go through.” or “This file is too large.” ### 2. Why did it happen? The cause only belongs in the message if it helps fix the problem. “The file is larger than 10 MB” is useful because it shows where the problem lies. “Upload failed at the gateway payload limit” is accurate, but it helps nobody outside the development team. ### 3. What can I do now? This is the most important part, and the one most often missing. NN/g puts it plainly: merely stating the problem isn’t enough, the message should offer potential remedies. That can be a specific instruction (“Choose a file under 10 MB or reduce the image size”), a button for the next step (“Try again”) or a way out if the problem can’t be solved on the spot (“Call us and we’ll book the ticket for you”). ### 4. What about my data? Whenever money, time or entered content is involved, a fourth question comes up: has anything been lost? Has anything happened twice? The GOV.UK Design System, the UK government’s design guidance, recommends exactly this for pages about system errors: say whether the user’s answers have been saved and how long they will stay available. A sentence like “Your answers have been saved” often takes more pressure off than any apology. ## Getting the tone right Content alone isn’t enough. The same information can reassure or annoy, depending on how it’s phrased. ### Don’t blame the user “You have entered an invalid date” sounds like a telling-off. NN/g advises avoiding words like “invalid”, “illegal” or “incorrect”, and backs this up with a memorable line: the proper usage of any system lies with its creators, not with its users. The GOV.UK Design System goes further and lists words such as “forbidden”, “illegal”, “prohibited” and “you forgot” as having no place in error messages. “Valid” and “invalid” are on the list too, because they add nothing to the message. Instead of locating the problem in the person, a good message describes what’s needed: “Enter a date in the future” instead of “Invalid date”. ### Calm, not loud Capital letters, exclamation marks and bright red warning icons raise the pulse, not understanding. “ERROR! Required field!” feels like being shouted at. An error message is allowed to stand out, but it doesn’t need to scold. ### Humor only in exceptional cases An “Oops!” or a funny illustration feels charming the first time. The tenth time, or right after an important bank transfer has failed, it feels cynical. NN/g advises against humor in error messages because it gets stale quickly when people run into the same error repeatedly. The exception it makes is for rare, total outages: there, an apology combined with something surprising can soften the disappointment a little. For everyday errors, aim for clear and friendly, not funny. ### Be careful with “please” and “sorry” The GOV.UK Design System advises against both. “Please” implies a choice where there isn’t one, and “sorry” doesn’t help fix the problem. Not every brand voice has to be that strict, but the principle behind it is useful: politeness doesn’t replace a solution. An apology fits when the system really has failed, for example during a server outage. If someone has simply missed a field, there’s nothing to apologize for. ### Specific and brief An error message isn’t a manual. One or two short sentences are almost always enough. If more explanation is needed, link to a help page. The GOV.UK Design System’s rule of thumb: use positive language, get to the point and read the message out loud. If it sounds odd when spoken, it reads oddly too. ## Ten common error cases, before and after The following examples show what these principles look like in practice. They’re deliberately drawn from different kinds of products: an online shop, a project management app, a customer portal and a booking platform. The “before” versions are typical patterns that show up in many products. ### 1. Empty required field > **Before:** “This field is required.” > > **After:** “Enter your email address so we can send you the order confirmation.” The before version only says something is missing. The after version says what is missing and why it’s needed. For empty fields, the GOV.UK Design System recommends a clear instruction that names the field, such as “Enter your first name”, rather than generic messages like “Fill in the field”. When and how these messages should appear in forms is covered in detail in [Forms Nobody Abandons](https://insideuxdesign.com/en/blog/forms-nobody-abandons-12-rules-for-better-form-ux). ### 2. Wrong format > **Before:** “Invalid date format.” > > **After:** “Enter the date as DD/MM/YYYY, for example 24/12/2026.” An example in the right format is often more helpful than any description. Even better: the system accepts common variations such as “24/12/26” or “24 December 2026” and converts them itself. Then the error never happens in the first place. ### 3. Sign-in failed > **Before:** “Login failed.” > > **After:** “Your email address or password doesn’t match. Check both, or reset your password.” (with a “Forgot your password?” link) This is a genuine trade-off. From a UX point of view, it would help to say whether the email address or the password is wrong. From a security point of view, that’s exactly the problem: if the message reveals that an email address exists in the system, attackers can probe for valid accounts. The Open Worldwide Application Security Project (OWASP) testing guide therefore recommends consistent, generic messages for wrong usernames and wrong passwords alike. WCAG also allows an exception in success criterion 3.3.3 when a correction suggestion would jeopardize security. The answer isn’t vague copy but a good way out: the message stays generic, while offering a direct path to resetting the password. ### 4. File upload rejected > **Before:** “Upload failed.” > > **After:** “‘Report\_final.pdf’ is 24 MB. You can upload files up to 10 MB. Reduce the file size or split it into several files.” The after version names the affected file (important when several are uploaded at once), its actual size, the limit and two solutions. Ideally, the limit is shown next to the upload field before anyone uploads anything. ### 5. No internet connection > **Before:** “Network Error.” > > **After:** “You’re offline. Your changes are saved on this device and will sync as soon as you’re back online.” With connection problems, the most important information is what happens to your own work. Someone who has just spent five minutes on a note mainly wants to know whether it’s lost. If the app can’t save offline, it needs to say so just as clearly: “Your changes aren’t saved yet. Keep this window open until the connection is back.” ### 6. Payment declined > **Before:** “An error has occurred. Error code: ERR\_PAY\_4021.” > > **After:** “Your payment didn’t go through, and your card hasn’t been charged. Check your card details or choose a different payment method. We’ll hold your seats for 15 minutes.” This is the example from the introduction. The after version answers all four questions: what happened, what it means for my money, what I can do, and how much time I have. Of course, it only works if the statements are technically true. “Your card hasn’t been charged” may only appear if the system knows that for certain. That’s why error messages aren’t purely a writing task, but a shared job for design, content and engineering. ### 7. Server error > **Before:** “500 Internal Server Error.” > > **After:** “Sorry, something isn’t working on our end right now. Your answers have been saved. Try again in a few minutes. If it’s urgent, call us on +49 30 1234567 (Monday to Friday, 8 am to 6 pm).” With a server error, the problem clearly lies with the system, so an apology is appropriate here. The GOV.UK Design System treats this case as a pattern of its own: no technical terms like “500”, no stock phrase like “We are experiencing technical difficulties”, but information on whether answers were saved and, where possible, an alternative route such as contact details or another service. The phone number in the example is, of course, a placeholder. ### 8. Page not found > **Before:** “404 Not Found.” > > **After:** “This page doesn’t exist (anymore). The address may have changed. Search for what you need here, or go to the homepage.” (with a search field and links to the main sections) A 404 page is a dead end that can become a junction. A search field, links to the most visited pages and a way to report the broken link turn a drop-off into a detour. A little personality is fine here, as long as the way forward comes first. ### 9. No permission > **Before:** “403 Forbidden. Access denied.” > > **After:** “You don’t have access to the ‘Relaunch 2027’ project yet. Ask the person who manages the project to invite you.” (with a “Request access” button) “Denied” and “forbidden” sound like a rule has been broken, when usually all that’s missing is an invitation. The after version explains the situation neutrally and offers a path that actually solves the problem. ### 10. Session expired > **Before:** “Session expired. Please log in again.” (and everything entered is gone) > > **After:** “You were inactive for a while, so we signed you out to keep your account safe. Sign in again. Your application answers have been saved.” Expired sessions are especially frustrating because they tend to strike right after someone has spent a long time on something. Here, the copy can only be as good as the system behind it: ideally, the interface warns before the session runs out and offers to extend it. WCAG success criterion 2.2.1 (Timing Adjustable) generally requires that people can turn off, adjust or extend time limits, with exceptions such as real-time events. ## Where and how the message appears The best copy won’t help if nobody sees it, or if it shows up in the wrong place. ### Close to the problem NN/g recommends showing errors where they occurred. A message right next to the affected field or element is connected to the problem faster than a block of text at the top of the page. In long forms, a summary at the top complements the messages at each field, but doesn’t replace them. The GOV.UK Design System recommends using the same wording in the summary and at the field. ### Matched to severity Not every error needs a dialog that blocks everything. A typo in a postcode is a hint next to the field. A failed save is a clearly visible banner. Only when nothing works anymore, or data could be lost, is a modal dialog justified. NN/g calls this matching the visual severity of the message to the impact of the error. ### Visible for long enough Short notifications that disappear on their own after a few seconds (often called “toasts”) are handy for success messages. For errors, they’re risky: anyone looking elsewhere or reading more slowly misses the message, and the information is gone. Errors that require a response should stay visible until they’re fixed or deliberately dismissed. ### Perceivable for everyone Error messages also need to work for people who can’t see, perceive colors differently or navigate by keyboard. NN/g stresses never to signal errors through color or animation alone. A red border always needs text, and ideally an icon as well. The Web Content Accessibility Guidelines (WCAG) set out clear requirements: - **3.3.1 Error Identification (Level A):** If an input error is automatically detected, the item in error must be identified and the error described to the user in text. - **3.3.3 Error Suggestion (Level AA):** If suggestions for correction are known, they must be provided, unless doing so would jeopardize the security or purpose of the content. - **4.1.3 Status Messages (Level AA):** Messages that appear without a change of focus must be programmatically determinable for assistive technologies such as screen readers, for example via a live region with `role="alert"` or `role="status"`. In technical terms: the error message is linked to its field via `aria-describedby`, the field gets `aria-invalid="true"`, and after a form is submitted, focus moves to the error summary. That way, someone using a screen reader also hears what went wrong and where. ## The best error is the one that never happens As important as good error copy is, every error message is a sign that the interface has led someone into a dead end. Drawing on Don Norman, NN/g distinguishes two kinds of errors. **Slips** happen when someone intends to do the right thing but accidentally does something else, such as tapping the wrong button. **Mistakes** happen when the goal or understanding doesn’t fit the situation, in other words when the person’s mental model doesn’t match how the system actually works. Both can often be prevented before a message is ever needed: - **Forgiving input:** accept phone numbers with spaces, IBANs with or without gaps and dates in different formats, and normalize them in the background. - **Constraints instead of prohibitions:** a date picker in which past days can’t be selected doesn’t need a “Date is in the past” message. - **Suggestions:** if the system spots a likely typo such as “gmial.com”, it can ask: “Did you mean gmail.com?” NN/g recommends making corrections as easy as possible, for example with selectable suggestions. - **Undo instead of “Are you sure?”:** an undo option after deleting is often more pleasant than a confirmation dialog that many people dismiss on reflex anyway. - **Confirm where it matters:** for actions with legal or financial consequences, WCAG success criterion 3.3.4 requires that submissions can be reversed, checked or confirmed before they’re final. ## Improving error copy systematically as a team Error messages can rarely be fixed with a single ticket. They’re scattered across the whole product, in front-end code, back-end services and third-party tools. A few steps help to get them under control. **Take inventory.** Collect all error messages in one place, for example in a spreadsheet with columns for trigger, current copy, frequency and owner. Many teams are surprised by how many different phrasings exist for the same problem. **Prioritize by frequency.** Not every error matters equally. Logs and analytics show which messages appear most often and where people drop off afterwards. That’s where a rewrite pays off first. The support team usually knows exactly which messages lead to calls, too. **Agree on a template.** A simple pattern creates consistency: what happened, what it means, what to do. Add a few rules on tone and wording, such as “no ‘invalid’, no error code in the main text, always a next step”. If the product has a design system, that’s a good home for error copy guidelines. **Don’t delete error codes, demote them.** Codes can be valuable for support. They just don’t belong in the first sentence. A small addition at the end of the message, such as “If you contact us, mention code PAY-4021”, serves the same purpose without confusing anyone. **Write together.** Engineering knows which errors are technically possible and what the system can reliably say about their consequences. Design and content know how that needs to sound to people. Good error messages come from early collaboration, not from editing copy that’s already in the code. **Test with real people.** Error cases are often skipped in usability tests because the prototype only covers the happy path. Build errors into your test scenarios on purpose and watch whether participants can recover without help. ## Conclusion An error message is the moment a product shows whether it’s on the side of the people using it. “An error has occurred” essentially says: this is your problem now. A good message says instead: here’s what happened, here’s how to continue, and your data is safe. Getting there is manageable. Say specifically what happened. Always offer a next step. Explain what happened to entered data, money or time. Skip the blame, the jargon and the alarm bells. Show the message where the problem is, in a way everyone can perceive. And then check which errors you can prevent altogether. A good starting point is surprisingly small: take the five most frequent error messages in your product and rewrite them using the examples in this article. The difference often shows up in support requests and drop-off rates sooner than expected. ## Checklist - The message says specifically what happened, without jargon or an error code in the main text. - It always includes a next step: an instruction, a button or a contact. - Where money, data or deadlines are involved, it says what has been saved, charged or reserved. - The tone is calm and factual, with no blame, capital letters or exclamation marks. - Words like “invalid”, “illegal” and “forbidden” don’t appear. - Humor is reserved for rare exceptions, never for money or data loss. - Sign-in errors stay generic for security reasons, but offer a way out. - The message sits close to the problem, and its visual weight matches the severity of the error. - Errors don’t disappear on their own before anyone could react. - Errors aren’t conveyed by color alone and are accessible to screen readers. - Common errors are prevented through forgiving input, suggestions and undo. - All error copy is collected, prioritized by frequency and follows a shared template. ## Sources - [Nielsen Norman Group: Error-Message Guidelines (Tim Neusesser, Evan Sunwall)](https://www.nngroup.com/articles/error-message-guidelines/) - [Nielsen Norman Group: 10 Usability Heuristics for User Interface Design](https://www.nngroup.com/articles/ten-usability-heuristics/) - [Nielsen Norman Group: Preventing User Errors: Avoiding Unconscious Slips (Page Laubheimer)](https://www.nngroup.com/articles/slips/) - [GOV.UK Design System: Error message](https://design-system.service.gov.uk/components/error-message/) - [GOV.UK Design System: There is a problem with the service pages](https://design-system.service.gov.uk/patterns/problem-with-the-service-pages/) - [W3C: Understanding Success Criterion 3.3.3 Error Suggestion](https://www.w3.org/WAI/WCAG22/Understanding/error-suggestion) - [W3C: Web Content Accessibility Guidelines (WCAG) 2.2](https://www.w3.org/TR/WCAG22/) - [OWASP Web Security Testing Guide: Testing for Account Enumeration and Guessable User Account](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/03-Identity_Management_Testing/04-Testing_for_Account_Enumeration_and_Guessable_User_Account/)