This is a part of a series of posts around “-able” software, which will eventually grow into an evaluation rubric.
Today I want to talk about understandable software. Is your application giving your users something they can understand? And better yet, is the feedback actionable? Is it even useful?
Here’s some feedback, along with a dialog box, that aren’t:
I have no idea what to do here. None at all. An error message with a number that I suppose I can Google, but wouldn’t it seem that if there is a server error, these error messages should be sent in some type of actionable list to somebody who cares? And if there is something like an End Date before a Start Date, why not just fix it? Or tell me to stop seeing these error messages? Do I need to track down the e-mail and do something with it? And the unknown errors? Are they really still unknown at this point? Would it be so hard to link these to an online database that is periodically updated with “Likely Causes and Resolutions”
It may simply be that this is a poor example, and a product that Microsoft doesn’t really care about. Some spec somewhere said “make this dialog box work” and that was the end of it.
But it sends a message…that this is an unloved piece of software. If I am evaluating any vendor’s product, I want to know if this is a product they care about, or something that they simply want to sell.
Pingback: The "-ible", "-able" and "-abilities" for software and systems. ← David Pinkus