Interesting to hear this from the UX team at spotify. I think these are all very good advice.
Of course, Decided to see how fast I could trigger an obscure error message in the app. 2 minutes in:
1. Enable offline mode 2. Click a song that hasn't been downloaded yet 3. "Song unavailable" is the error. No explanation why.
Great advice, BUT: apart from the laziness and the poor written communication skills, often the real reason for the vagueness is that these pesky details are simply unavailable to the coders who throw that exception or issue that message. It is buried somewhere deep in the bowels of inner components.
Better error messages start with better architecture.
One thing that has amazingly never improved for 20 years. That's when your internet connection does not work. It could be anything from:
1. your computer broke 2. your network/wifi card failed 3. your wifi access point failed 4. your hub/switch failed 5. your router failed 6. your cable modem failed 7. your ISP failed 8. the URL you were trying to reach failed
The error message you get is just a generic one with no clue at all.
It's nice to see this raised as an important issue for designers. It can be really hard to get anybody outside engineering interested in error messages until they see them show up in production.
I also like the emphasis on giving explanations that help the user understand what they can and can't do next. When users see errors, they immediately go into the mode of trying to make it work. They get hyped up and focused; they don't relax. A vague "friendly" message will just frustrate them further if it doesn't help them understand what to do next.
I think this is one aspect of UX where engineers can provide a unique perspective. I think designers and product managers are often surprised by the amount of energy a user can pour into struggling with an error, and the level of anger and frustration that can result. As programmers we can identify with that experience better than most, so we need to take it on ourselves to write good error messages and, when possible, present them to the designer as part of the design that needs their attention and vetting.
I'll quote the Android Guidelines on error messages here, because they summarize it well into a single sentence:
> It's not my fault
> Be gentle in how you prompt people to make corrections. They want to feel smart when they use your app. If something goes wrong, give clear recovery instructions but spare them the technical details. If you can fix it behind the scenes, even better.
You can find the other design principles of Android quickly summarized here: https://developer.android.com/design/get-started/principles....
These design principles are important for any developer, on any platform, and they're short enough that they're easy to remember.
See the Macintosh User Interface Guidelines for the original Mac. They thought this through.
Error messages were to be two sentences. The first one explains the problem. The second sentence says what to do about it. There were rules for buttons, too. "Your file has been lost" should have a button that says "Sorry", not "OK".
Last week I saw someone get stuck trying to change his password, the interface would not tell him what criteria was making it not secure enough.
Also equally important and related to the article is messages on exceptions raised by libraries used by developers. I think this is one of the primary reasons why I found some Python's open sourced libraries like Numpy or Pandas easy to learn. Most of the messages when an exception is raised are specific and helpful in helping me fixing the error.
Mate of mine from years ago (we've lost touch), once told me that the system he built to scan blood samples and used by lab techs all over the UK had some very interesting error messages he put in there.
He got a call one day from a customer who told him the error message read "Fuckity, fuckity, fuck, everything's about to get stuck". His response on the phone was "Well, the good news is I know exactly where the error is..."
It was in a loop you shouldn't be able to get into and so his defence was that this error was "impossible".
Yeah, can't really disagree with any of this. Depressing how many programmers and software designers don't listen to this advice though, I mean, look at the standard Windows Media Player error nowadays. Server execution failed, really? You couldn't be more precise than that?
Eh, I guess it's still better than the (thankfully very rare outside of deliberate glitches) error Nintendo consoles give you now. "The software closed because an error occurred". Thanks for that useful piece of advice.
Haha. Last error message I saw from Spotify was: "Login failed. Unable to login, either username or password is incorrect. Have you signed up for a Spotify account?". The issue was that I filled in my email instead of username into a form that said "Username or email", see https://community.spotify.com/t5/iOS-iPhone-iPad/I-can-t-log... Tell me something about error messages, Spotify.
There was an excellent talk by Larry Wall on the perl6 error message design. I think it was in Santa Clara and it was a Perl Conference, but haven't found a transcript yet. It was about 9 years ago.
Anyone have a link?
So is there a guide for error messages when the message is not client facing. The grammar, format, etc. +1 if it also provides language specific info , for example in Java use e.getMessage() etc?
One of Nielsen's classic UX heuristics:
> Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
ed has perfected it years ago:
I love diagnosing Microsoft enterprise frameworks.
Half the time in CRM or NAV, it's either an error code with zero google results, or, "general error."
And yes, I know about tracing.
It's disappointing that this needs to be spelled out. It really should be common sense, minimal competency.