TL;DR
This blog post is about error messages.
Why we should care about error messages? Heuristic Test Strategy Model [Bach] states that error handling is one attribute of products reliability quality criteria:
Will it work well and resist failure in all required situations? Error handling: the product resists failure in the case of errors, is graceful when it fails, and recovers readily.
Error messages come into play for this poetic statement:
"Is graceful when it fails."
Which has two parts: application will not “crash” and it will explain source of the error.
Ok, we do not expect Shakespeare or Ujević here, but we would be satisfied with information that will explain what happened.
Here is one example from the api response:
Cannot have a projected bitcoin value.
Problem with this message is that uses business vocabulary and it does not points to the source of this error.
When you receive this message, first question would be: what is projected bitcoin.? You need to think, question, investigate which is not the problem, but that takes time!
Consider this:
Bitcoin withstatus:
Projected
is not allowed.
No investigation, because status
is input attribute.
Straight to the bone error message heuristic
If user needs more than 10 seconds to figure out error message, this is not acceptable message.