No one enjoys receiving errors messages when working with computers, but there is something worse: software that fails silently. Can it get even worse? Yes: software that proceeds with the wrong data or assumption.
But let’s stay positive: if errors are not all that bad, what are the characteristics of good errors?
A good error is actually very helpful and can potentially prevent disastrous and expensive consequences. An error message is a communication medium and as beautifully elaborated by this TED talk, it should start with why.
A good error message should indicate:
If the error is supposed to be consumed by someone other than the end user (support, developers, auditors), there’s typically an online or offline logging system in place.
In this case the error should also answer:
Too many systems fail to give a good error which leads to user frustration. Windows Blue Screen of Death (even has its own acronym BSOD) is probably one of the most cursed error messages:
For an operating system that is developed for non-technical end users, it has embarrassingly too little information. It fails to answer WHY, briefly touches briefly on WHAT and jumps to WHERE the error happened. The instruction for HOW to solve the error is generic and not very specific (because the WHY is often unknown).
2 decades later, Windows shows even less information and expects the user to pull out their phone and scan a QR code:
The web platform is much more flexible and leaves room for creativity with powerful tools.
404 (page not found) is a classic error on the browsers. While some sites just throw the error number at the user and expect them to figure out the rest, Hootsuit has an actionable button: go to the main page:
Can it be done better? Of course. List24 don’t leave you there, it suggests you to search and even offers you some alternative content to click on right away:
While some like Path show empathy:
Chrome totally distracts the users by offering them a game when it can’t connect to the internet:
Software developers usually treat the errors as the ugly part of their code. That is because they are mostly aiming for the happy scenario where everything works and they solve the problem that the software has promised. However, when the end user is trying the software, they experience the real scenario which is different from the happy scenario in many ways:
Good software is a pleasure to use. It not only prevents errors, but when it fails, it gives actionable error messages that help the user understand why it went wrong, how the error was detected and what can be done to solve it.
If there’s one key take away from this article, I want it to be:
Errors are encountered by real users with real goals. The error message is a communication method to help the user continue their goal.
⚡️Liked what you read? Follow me to be notified when I write something new.