Fixing Errors in Your Error Messages

Summary: This article deals with a basic single error message, as opposed to, for example, more complicated form feedback. It also addresses keeping web-nerd lingo from making it to an end-user, or at least finessing the language as much as possible.

UX Scribe
4 min readFeb 24, 2021
Oops, this error message is completely pathetic.

Having originated with 404 page handling, an error message that opens with “Oops” stands a good chance it will not be followed up with anything substantive, especially when it comes to additional info or recovery. Try not to start off with something as corny as “Oops”, “Oh No” or “Shucks”. At this point, I would even prefer an “Oh shit” to “Oops”. Now that I think about it, I do remember seeing the expletive used on Urban Outfitters somewhere, and thought it actually read well, simply due to how brand-centric it was.

Also, I’d like to point out there only seemed to have been an error. Obviously, as if this error message doesn’t seem to suck anymore than it already does. Just imagine a user taking a totally unexpected turn, ending up on a mostly blank page with a loud alert modal, then having to read a message that suggests that things could have messed up somewhere, perhaps.

Finally, there’s one last complaint: the recursive matter or writing “Error” in an error message. I have seen error messages that contain several instances of the word. Personally, I visualize this as slapping the user across the face every time the word appears.

So… what you’re trying to say is there’s an error? Thanks.

Rewriting “Oops” Messages

Do you have to go all out, citing the what, why and how of an error? More detailed info can be hidden if need be, but quickly explaining what happened, and possibly how, is enough — you’re going to need some of that space to provide a solution (or two).

One of the first things I do is check in with the developers, making sure they don’t sneak in rogue error messages within their code, which usually ends up as heartwarming user-facing communications such as, “Wrong type given, expected a string”.

If you don’t stay on top of this, at some point there’s a good chance a user may end up with a blue-screen-of-death type of scenario. For you millennials out there, that means a creepy sort of end-frame screen, showing only cryptic code-speak and no way to back out.

Sure, let the dev team be in charge of error messaging.

Another developer-penned message might go something like this: “An unexpected error has occurred” — this seems to be at odds with explaining why the error happened.

However, if you give a developer or web admin a chance to address the problem, they may output some sort of debugging insanity, for example, a long stack trace list. Most users know how to break down stack traces, right? It is especially enjoyable for the user to see words like “Warning” and “Fatal”. These mechanized words and numbers have to be parsed into something understandable, and then finally further distilled to something a user can easily digest and relate to.

To illustrate, take the case of a simpler coded error below.

Um no, that’s not going to work.
Some progress here — a readable error. Understandable — not so much.
Getting there. Oh yeah, the TCP stream, right, that’s what I thought it was.
So this is the least dense I can make this, without getting into sockets, TCP and network switches. This also means web admin geeks are going to loathe this explanation. This is not for them, which is the entire point.

--

--