We have the neediest coffee maker. It’s great having free, freshly ground espresso at the office, but that machine is constantly yalping for one thing or another. Waiting for your espresso to brew gives you time to think about usability.
The coffee machine has a one-line, 10-character LED display, which it uses to cryptically beg you for attention. (The latest: “Descale machine.”) I found a co-worker one morning, exasperated with trying to guess its needs. “I’ve put coffee in! What is its problem?” The machine was alternating between two words, “grounds” and “empty.” Believing that the grounds were empty, my co-worker was adding more to the hopper. Turn the sentence around, though, and you realize the tray for catching used grounds needed to be emptied.
I recently read Microinteractions by Dan Saffer. He gives a great explanation of what a microinteraction is, a single use-case interaction with a device or application. Dismissing an alert on your phone, setting the target temperature on the oven, even turning on a lamp are all microinteractions. Getting these right is what makes an application “intuitive.”
The coffee maker could scroll the words or just use an LED display with two lines of text. At least it is consistent: all messages are imperative commands, rather than declarative statements. Having seen other, less ambiguous messages from it led me to parse “empty” “grounds” correctly. And error messages in applications should be instructions, telling us what to fix instead of just complaining that something is wrong.
The coffee machine’s not off the hook, though. There’s a button you press to select the strength of your coffee. One press means “mild,” two means “strong,” three means “stand the spoon up in it,” and I hope that’s the one you wanted, because there’s no cycling back to the beginning. Subsequent button presses do nothing.
What microinteractions are you designing into your applications?