(Photo borrowed from Cornerstork)
There's a coffee maker (oh, sorry, espresso maker...) in my office with which I'm having a tempestuous relationship. Every morning I make my usual quadruple espresso: two doubles gently mixed with a bit of low-fat milk and cinnamon. It's part of my routine, and makes me very happy, and awake.
The problem is, this particular coffee maker (fine, espresso maker) always has something to complain about. Our strained exchanges of late go something like this:
"Double espresso, please."
Fill water tank.
"Ok, double espresso please."
Fill beans.
"Fine. Make the espresso."
Empty grounds.
"Argh -"
Rinse.
"Why I oughta-"
Warming up...
Eventually, I get my lovely coffee beverage, and I usually only have to do one of these, sometimes two, but it gets irksome. Given, much of this is a constraint of a machine that is connected to neither a large bin of coffee bean, water source nor garbage receptacle. But still.
Here's another example:
Each time the power goes out in my house, I need to reset the time on the microwave I almost never use, but came with the house. Resetting the time on this particular microwave involves entering the time, am/pm and date.
I never seem to remember to look to see what the date is before I try to reset the time, so I inevitably need to go find out in the middle of the process. In spite of this extra needed effort, the date appears to serve no useful purpose whatsoever.
Recently, daylight savings time required setting the clocks ahead ("spring forward! fall back!") and you would think that, since I dutifully tell this microwave the date each and every time I lose power, this information would be used to automatically set the time ahead.
Nope.
When we design interfaces, its important to think about how the interface communicates with the user.
Ideally, the interface should prevent the user from making mistakes in the first place, and not collect any more information that is necessary to complete the task.
Users are task oriented. They just want to do what they want to do. They don't want to learn your interface, nor the clever intricacies of how information is collected or captured.
Use existing conventions, handle issues inline and strive for an interface that is forgiving of its users' idiosyncrasies.
And if you don't need the information, don't ask for it – less data entry will get you increased conversion and happier users. If my microwave isn't going to use the date to do anything useful, I really wish it didn't require it just to reset the time.
If the user does make a mistake, and the mistake can be fixed or mitigated, the interface should do so.
I just looked up the spelling of "idiosyncrasies" because I was forgetting it was "idio.." not "ideo.." I tried using a browser tool called Ubiquity, but it couldn't find an entry because I wasn't spelling it right. Dictionary.com happily offered the correct spelling as long as I could get close enough.
If the interface absolutely has to complain to the user, be user-friendly about it.
Make the message clear, concise, friendly, and as much as possible try to make it the system's problem, not the users. Is there something – anything? – that the user can do next? If so, make it easy to do so, don't leave the user hanging with an error message and no idea how to fix things or continue.
True, none of these things will probably help with my espresso maker, but hopefully will offer some small suggestions for your next project. And if it's possible to attach your next big idea to it's own conceptual water source and thus save your users a bit of time, effort and frustration, they'll thank you.