In defense of something went wrong
As a UX Writer, I often need to write error messages.
And as any UX Writer worth their salt knows, a good error message:
- Is specific about what went wrong.
- Tells the user how to fix it.
That can look like, “Invalid file type. Upload a .jpg instead.” or, “We don’t have an account associated with that email address. Check for errors and try again, or sign up for a new account.” You get the idea.
I’ve read countless articles advocating against vague error messages. And for good reason. Nobody likes filling out a form online only to see, “Something went wrong” when they submit it. What went wrong? Nobody knows! And how annoying is it when you try again only to get that same vague error in a constant loop of not knowing if there’s a system error or if it’s something you did? That’s why those articles tell you that vague error messages are “bad UX writing.”
But I’ll play devil’s advocate for a moment here and say that “Something went wrong” can be good UX writing too.
In a perfect world, no digital product would ever have bugs, there would be no unspecified server errors. We would always know exactly what had gone wrong and be able to communicate that to our users along with a solution.
I don’t know if you’ve read the news lately, but our world is far from perfect. Sometimes you’ve already written 12 different possible error scenarios. You’ve designed a flow so user-friendly that it prevents 99.9% of errors in the first place. But you still need to write something as a fall-back when the 12 specific errors you anticipated don’t apply. When there’s a bug and something unexpected happens. UX writers aren’t wizards; it’s not possible for us to know everything. At a certain point we need to say, “Something went wrong, try again” and cross our fingers that it works on the second try.
It doesn’t make you a bad writer to use generic messaging. It just means you work with a team of other imperfect people in an imperfect world, and sometimes you really just don’t know what went wrong.
