I was travelling on business a few weeks ago, and was fortunate enough to be staying in a hotel that had a gym. One morning I was using a treadmill, when I inadvertently dislodged the safety key (this sort of thing often happens when I try to function before the first coffee of the day!)
As you’d expect, once the safety key was dislodged, the treadmill stopped. Trouble was, I didn’t immediately realise what I had done. The lack of caffeine was clearly affecting my neurons! I looked at the treadmill’s digital display for help — and the error message displayed was ambiguous to say the least. I thought I’d share a photo with you:
Error messages can be confusing!
The treadmill’s digital display showed the word “True”. I have no idea what this means — perhaps “True” is the result of a logical test, or perhaps it’s the name of the manufacturer of the treadmill. Perhaps it was a homage to the 1980’s Spandau Ballet song of the same name. Either way to an end-user, without any context it doesn’t mean anything at all.
This got me thinking back to the “day job” and specifically how software is specified. How often are the ‘little details’ like error messages left until the last minute, or even worse not explicitly specified at all? How often have you been using a software package that crashes, giving an extremely useful error message like “Exception error 0xxxx23948”?
I’ve worked on projects where the analysts have argued that it’s the UI designers who should specify error messages. I’ve worked in projects where the dev teams ask the marketing team to define meaningful error messages during design. Like many of these things, it really doesn’t matter who supplies them as long as somebody does, and as long as that person knows and accepts they are responsible for it.
As BAs, there are a number of things we can do to prevent confusing error messages getting into the final system. Three examples are listed below:
1. Ensure all UI and Business Rules are consistently documented: Messages will be required for both “errors” and “warnings”. Make sure there’s a consistent way of documenting all types of rule (and making sure there is a ‘single source of the truth’). This will be far easier than having fragmented rules spread across hundreds of textual specifications. This will make a whole host of things easier, not just defining error messages.
2. Agree who will define the error/warning messages: This might be the BA, it might be someone else. The key thing is to agree the responsibility up front. The Project Manager can then make sure it happens!
3. Test the messages with actual users: Before implementation — use prototypes (which can be as low-fidelity as you like — paper works well) to establish whether the error messages actually make sense. Incorporate feedback from your end-users, SMEs and customers.
It’s also important to remember that the user might be in a rush, might be tired, and might not be used to using the software/equipment. And perhaps, like me, they’ll be in need of coffee — so better make sure those error messages are crystal clear 🙂
I hope you’ve found this article useful. I’d love to hear your comments and experiences. Please feel free to add a comment below.