An error message is the moment your product is most likely to lose a user. Something went wrong, the user’s expectations were violated, and the next three seconds determine whether they retry or close the tab. Most error messages guarantee the worst outcome because they were written by a developer who thought “Error 422: Unprocessable Entity” was an acceptable thing to say to a human being.
I’ve rewritten error messages for SaaS products, checkout flows, and AI chatbots that were hemorrhaging users at failure states. The fix is never about making the message “nicer.” It is about applying three specific cognitive principles that turn a frustrating dead end into a guided recovery. Those principles are the Progress Endowment Effect, Perceived Control, and Empathetic Mirroring.
Why Bad Error Messages Cost You Users
The psychology is straightforward. Users experience negativity bias — negative experiences are remembered more vividly and weighted more heavily than positive ones. A smooth onboarding flow followed by a cold, confusing error message at the payment step can ruin the perception of the entire experience. That is the peak-end rule at work: people judge an experience by how it felt at its peak (often the error) and at its end.
A bad error message does three things simultaneously:
- Increases cognitive load. The user has to decode what went wrong, figure out what to do next, and manage their own frustration. That is three tasks stacked on top of whatever they were already trying to do.
- Triggers loss aversion. If the error wipes out form data, progress, or a configured state, the user feels the loss of their invested effort. The pain of losing 10 minutes of work is more intense than the potential gain of completing the task.
- Breaks trust. A vague or technical error suggests the product is unreliable. “Something went wrong. Please try again later.” tells the user you do not know what happened and you cannot help them fix it.
Principle 1: The Progress Endowment Effect
The Progress Endowment Effect is a behavioral principle where people who can see how far they have come are less likely to abandon a task, even after encountering friction. It is related to the sunk cost fallacy but applied to UX design: if the user can see that they are 80% done, the perceived cost of quitting feels higher than the cost of pushing through the error.
Most error messages strip away all progress context. The user fills out a multi-step form, hits an error at step 4, and sees a message with no reference to the work they already completed. The fix is embedding progress information directly into the error state.
| Bad Error Message | Why It Fails | Rewritten With Progress Endowment |
| “Error: Payment failed. Try again.” | No progress context, feels like a restart | “Your order is 90% complete. The payment didn’t go through — try a different card or check your billing address. Everything else is saved.” |
| “Something went wrong.” | No information, no direction | “We hit a snag on step 3 of 4. Your first two steps are saved. Here’s what to check to move forward.” |
| “Invalid input.” | Technical, blaming the user | “Almost there! The phone number format needs a country code. Your other details are saved — just update this one field.” |
The pattern: acknowledge what is already done, name the specific obstacle, and confirm nothing was lost. The user does not feel like they are starting over. They feel like they are fixing one small thing to finish a process they have already invested in.
Principle 2: Perceived Control
When an error occurs, users feel a loss of control. Something they expected to happen did not happen, and they did not choose for it to fail. That involuntary shift triggers frustration at a level disproportionate to the actual severity of the problem.
Perceived control is restored by offering clear, specific, alternative actions. Not one action — multiple options. When users have choices, even small ones, their sense of agency returns and frustration drops.
| Bad Error (No Control) | Better Error (Perceived Control Restored) |
| “Page not found.” | “This page doesn’t exist anymore. You can go back to the homepage, search for what you need, or check our most popular pages below.” |
| “Upload failed.” | “That file didn’t upload. You can try again, choose a smaller file (under 10MB), or switch to a different format (JPG, PNG, PDF).” |
| “Session expired. Please log in again.” | “Your session timed out for security. You can log in again (your draft is saved), or continue as a guest.” |
| “This feature is unavailable.” | “This feature isn’t available on your current plan. You can upgrade to access it, or here’s an alternative way to get the same result with your existing tools.” |
Notice the structure: state the problem, offer two to three specific next steps. Each option is a concrete action the user can take immediately. No ambiguity, no dead ends.
Principle 3: Empathetic Mirroring
Empathetic mirroring means acknowledging the user’s emotional state before redirecting them. It sounds simple. It is rarely done well because most product teams think error messages should be purely functional.
The principle comes from counseling psychology: before you can redirect someone’s behavior, you have to validate their current experience. In UX terms, that means the error message should briefly acknowledge that the situation is frustrating before offering a solution.
This does not mean being dramatic. It means being human.
| Cold (No Empathy) | Empathetic (Mirroring Applied) |
| “Error processing payment.” | “That’s frustrating — the payment didn’t go through. Here are two quick things to check.” |
| “No results found.” | “We couldn’t find what you’re looking for. That’s on us, not you. Try a broader search term or browse by category.” |
| “Connection lost.” | “You just lost your connection, which is annoying when you’re mid-task. The good news: your work is auto-saved. Reconnect and you’ll pick up right where you left off.” |
The key is brevity. One short validating phrase (“that’s frustrating,” “that’s annoying,” “that’s on us”) followed immediately by the solution. Overly apologetic messages (“We’re so sorry for the inconvenience! We truly apologize for this disruption!”) feel performative and waste the user’s time.
The Bad-to-Good Transformation Gallery
Here are 10 common error messages rewritten using all three principles together. Each rewrite incorporates progress endowment, perceived control, and empathetic mirroring.
| # | Original Error | Rewritten Error |
| 1 | Error 404: Page not found. | This page has moved or been removed. Head back to the homepage, or use the search bar — it’s probably one click away. |
| 2 | Invalid email address. | That email format doesn’t look right. Double-check for typos — everything else you’ve entered is saved. |
| 3 | Payment declined. | The payment didn’t go through. Your cart and shipping details are saved. Try a different card or contact your bank — sometimes it’s a quick hold issue. |
| 4 | Upload failed. Try again. | That file didn’t make it. Try a smaller file (under 10MB) or a different format. Your other uploads are still here. |
| 5 | Something went wrong. | We hit a problem on our end. Your progress is safe. Refresh the page, or if it happens again, reach out and we’ll sort it out. |
| 6 | Session expired. | Your session timed out (security thing). Good news: your draft is auto-saved. Log back in and it’ll be waiting for you. |
| 7 | No results found. | Nothing matched that search. Try a different term, check your spelling, or browse our categories for ideas. |
| 8 | This action is not allowed. | Your account doesn’t have access to this feature yet. Here’s how to request it, or try this alternative approach instead. |
| 9 | Request timed out. | The server took too long. That’s on us. Try again in a few seconds — if it keeps happening, our status page has live updates. |
| 10 | Form submission error. | Almost there. One field needs attention (highlighted below). Fix that and you’re done — everything else looks good. |
How to Apply This to AI Chatbot Errors
AI chatbots introduce a new category of errors: the misunderstanding. The bot does not crash. It gives the wrong answer, misinterprets the query, or admits it cannot help. These moments are just as critical as technical errors.
| Chatbot Situation | Bad Response | Response Using All Three Principles |
| Bot misunderstands the question | “I don’t understand. Can you rephrase?” | “I might have misread that. Could you try asking a different way? Or I can connect you to a person who can help right now.” |
| Bot cannot answer | “I can’t help with that.” | “That’s outside what I can handle, which is frustrating. Let me transfer you to someone who can — or you can email [email protected] for a faster answer.” |
| Bot gives wrong product info | No correction mechanism | “If that doesn’t look right, click here to flag it and I’ll connect you to a specialist who can double-check.” |
Building an Error Message Style Guide
If you manage a product with more than 10 error states, you need a style guide for errors. Not a general UX guide — a specific document that covers how errors should sound.
- Tone rule: One short empathetic phrase, then the solution. No corporate apologies.
- Structure rule: Problem statement, then two to three specific actions.
- Progress rule: Always confirm what has been saved or completed.
- Blame rule: Never blame the user. Frame the issue neutrally or take ownership.
- Length rule: Under 30 words for inline errors. Under 50 words for page-level errors.
Conclusion
Error messages are not afterthoughts. They are recovery moments — the points where your product either earns trust by helping the user through a problem, or loses them permanently by showing a cold, cryptic wall of text.
Apply the three principles: show progress to prevent abandonment, offer choices to restore control, and mirror the emotion before redirecting. The difference between a user who retries and a user who leaves is usually not the severity of the error. It is the quality of the message that follows.
