The UX of Error Messages: Why 'Something Went Wrong' Is Violence

The Rage Moment

Picture this: You're trying to submit your taxes. It's 11:58 PM on April 15th. You click "Submit."

The screen goes white. Then, a cheerful message appears:

"Oops! Something went wrong. Please try again later. 😊"

Your tax return is gone. There's no error code. No explanation. No "later" time estimate. Just a passive-aggressive emoji and the digital equivalent of a shrug.

This is not an error message. This is violence.

The Worst Error Messages I've Encountered

1. "Error: Error"

I once tried to upload a file to a government website. It failed with the message: "Error: Error."

Not "Error: File too large." Not "Error: Invalid format." Just... Error: Error.

This is the error message equivalent of a toddler screaming "NO!" without context. It conveys panic but no information.

2. "An unexpected error occurred."

By definition, ALL errors are unexpected. If I expected it, I would have prevented it.

This message is a tautology wrapped in uselessness. It's what developers write when they're too lazy to handle exceptions properly.

3. "Please contact your administrator."

I AM the administrator. Who do I contact? Myself? God?

Even worse, this appears on consumer apps. You're trying to order pizza, and the app tells you to "contact your administrator." What administrator? I don't have a pizza IT department.

4. Error Code: 0x80070057

Windows is the undisputed champion of cryptic error codes. "0x80070057" sounds like a license plate, not actionable information.

When I Google this code, I get 47 different potential causes ranging from "corrupted registry" to "cosmic rays flipped a bit in your RAM."

Why We Write Bad Error Messages

1. Developer-Centric Thinking

Developers write error messages for other developers. We think in stack traces. We think in HTTP status codes.

`HTTP 422 Unprocessable Entity` makes perfect sense to me. To my grandmother trying to upload her photo, it's Klingon.

2. Fear of Commitment

"Something went wrong" is vague because the developer doesn't know what went wrong. Or, they know 17 things that could have gone wrong, and they don't want to debug which one it is.

So they write a catch-all message that technically covers everything while explaining nothing.

3. Legal Paranoia

Some companies make developers run error messages through Legal. The lawyers strip out anything specific because "we don't want to admit fault."

So "Your password must be at least 8 characters" becomes "Authentication failed" because Legal worries that being helpful is legally risky.

The Anatomy of a Good Error Message

A good error message answers four questions:

1. What Happened?

Be specific. Don't say "Upload failed." Say "Upload failed: File size (15 MB) exceeds the 10 MB limit."

2. Why Did It Happen?

Don't just state the symptom; explain the cause. "Your session expired after 30 minutes of inactivity" is better than "Please log in again."

3. What Can I Do About It?

Always provide a next step. "Please compress your file and try again" or "Upgrade to Pro for larger uploads."

If there's nothing the user can do, tell them that too: "Our servers are experiencing high load. We're working on it. Check back in 10 minutes."

4. Who Can Help Me?

If it's a true system error beyond user control, provide a support contact. "If this persists, email support@company.com with error code: AUTH_TIMEOUT_2026011101."

That error code should be meaningful to your support team. It should map to logs. It should expedite resolution.

Real Examples of Good Error Messages

Stripe's Error Messages

Stripe is the gold standard. When a payment fails, they don't say "Payment error." They say:

"Your card was declined. Your bank flagged this charge as potentially fraudulent. Please contact your bank to approve international charges, or use a different card."

This is perfect. It tells you what happened (decline), why (fraud detection), what to do (call bank or use different card), and gives you agency.

GitHub's Form Validation

When you try to create a repository with a name that's already taken, GitHub says:

"Repository name 'awesome-repo' is already taken by user @someuser. Try a different name, or if you own that repository, rename or delete it first."

It even offers alternatives. That's thoughtful UX.

The Empathy Test

Before you ship an error message, ask: "If I were a user seeing this at 11 PM while stressed, would I know what to do next?"

If the answer is no, rewrite it.

Better yet, show the error message to a non-technical person. If they look confused, it's bad.

The Technical Implementation

"But we can't predict every error!" you protest. Fair. But you can structure your error handling to fail gracefully.

Use Error Codes, But Make Them Human

Instead of `ERR_500`, use `ERR_PAYMENT_TIMEOUT`. Even if the user doesn't understand it, your support team will.

Log Context, Display Kindness

Log the stack trace, the request ID, the user ID, the timestamp. That's for you.

Display a human message, a possible solution, and a support contact. That's for the user.

Differentiate Between User Errors and System Errors

If the user uploaded a .exe when you expected a .jpg, that's on them. Say "Please upload a JPG, PNG, or GIF file."

If your S3 bucket is on fire, that's on you. Say "We're having trouble uploading your file. Our team has been notified and we're working on a fix."

The Cultural Problem

Error messages are seen as an afterthought. They're written last, tested never, and reviewed by no one.

We spend weeks debating button colors. We A/B test headlines. But the message a user sees when everything breaks? That's a hasty `console.error()` copy-pasted into a modal.

This is backwards. The error state is when the user is most vulnerable. It's when you can lose them forever or earn their loyalty. Treat it accordingly.

A Challenge

This week, audit your error messages. All of them.

Find the "Something went wrongs." Find the cryptic codes. Find the dead-end messages that offer no path forward.

Rewrite them with empathy.

Your users are already frustrated. Don't make it worse by being vague. Be kind. Be specific. Be helpful.

That's the UX of error messages.