3 ms·
Looking at this more from the non-technical end user perspective, my rule for error messages is that they should always be actionable. If the viewer is the dev
by pugworthy 5y ago
Looking at this more from the non-technical end user perspective, my rule for error messages is that they should always be actionable. If the viewer is the developer, then technical details are important. But if the viewer is an end user/consumer, they don't necessarily need to know exactly what happened, but they do need to know what to do.
For an average end user...
* If the hard disk is full, that's easy to convey and easy to suggest a fix.
* If a hardware fault occurs on activating a device, suggest they try again and contact support if the problem persists.
* If an unhandled exception occurs, all they need to know is that something very unexpected happened, and they should contact support - they don't need to see a stack trace and error message.
- jiehong 5y agoThis cannot be overstated. Every time I review error messages, I _always_ ask 3 things: - What: is the "what" clear. - Why: explain the reason this happened. - Next: what can be done next. Almost all error messages can be expressed this way (the exception being the ones about security where giving information is a way for attackers to more about users, etc.) The result is great: users almost never ask you any questions, and when they do, it usually means it's either because the message told them to, or because the error message is not clear, and we ensure to clarify it.
- logbiscuitswave 5y agoI agree fully with this. Sadly it seems like entirely too much software these days has pivoted to the essentially useless “oops something went wrong” error messages.