Bad UI of the Week: Kettles and Washing Machines
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Bad UI of the Week: Kettles and Washing Machines
The last couple of weeks have discussed bad user interfaces for computer hardware and software. This week will discuss some consumer devices. The first bad user interface comes from a kettle I encountered when I visited my mother recently.
I am fairly easily distracted. I try to minimize the potential for distraction when I interact with devices, and good user interface designers do the same. One example is the cash machine. When you are using a cash machine, you are thinking about getting cash. Designers discovered that, if you gave the cash before returning the card, many users would walk away leaving their card in the machine. They had already achieved their goal (get cash) and so the need to reclaim their card slipped from their attention. By refusing to give cash until the card had been retrieved, this problem was dramatically reduced.
Filling a kettle is the same. You have two operations: fill the kettle and turn the kettle on. Older kettle designs required you to plug them in to a wire, and so the last thing you would do would be related to power. This made it easy to remember to turn it on. Newer ones have a base that supplies power. You fill the kettle with water and then place it on its base. The second operation is so simple that you are not really thinking about it. Instead, you are thinking about filling it with water, and so it is easy to forget to flip the "on" switch.
There is a very simple trick you can do to stop yourself from forgetting. If you get into the habit of flicking the switch at the start of the operation when you are thinking about turning the kettle on, it rarely slips your mind. I do this, and I can’t remember the last time I embarrassed myself waiting for a kettle to boil without turning it on as a result (forgetting to drink the coffee is a completely different problem).
My mother’s kettle was designed by someone very safety-conscious. If you poured the water out before it had finished boiling, they reasoned, then you could end up damaging the heating element. To prevent this, they designed the switch so that it would automatically set itself to "off" as soon as the kettle was lifted from the base. Now when I use the kettle, I turn it on, lift it up, it turns itself off, I fill it with water, return it to its base, and then wait. And wait. And then curse the designer for interposing himself between me and caffeine.
It seems designers of this mindset are not uncommon. My washing machine has a similar "safety feature." It cannot be opened until two minutes after it has finished running. Why? I have no idea. Even when it is on a dry-only cycle, and so at any point in the run it is guaranteed to have no more water in it than the last time the door was opened, it still won’t let you open the door until you have turned it off for two minutes.
These two features have two things in common. They were both created to prevent the user from doing something stupid (burning the heating element or flooding their floor), and they both tested the wrong thing. The kettle could have had a simple sensor checking if there was enough water in it to operate safely, and simply refused to work at all when empty. This would not only have addressed the same problem, but it would have done so better and without inconveniencing the user.
The washing machine simply needed some slightly more complicated logic. Two minutes was presumably chosen because that was the length of time it took for the water to drain away if the user manually advanced it to the end of the cycle. Rather than having a fixed time of two minutes, it could have set the time differently for each step in the cycle that it entered without human intervention. Or, it could have simply contained a weight or conductivity sensor to detect when it was full of water.
It is very easy, when designing a system, to make shortcuts for user interface elements. To test for conditions that are almost, but not quite, the correct ones. If I open a text document and type a letter then Backspace, nine times out of ten when I try to save it will say, "This document has been modified. Save changes?" The designer didn’t check if the document had been modified, but rather if any operations which modified the document had occurred. If I did this a few days ago and forgot to quit the editor, then I am forced to remember whether I made important changes.
For a good user experience, make sure the conditions you are testing are the conditions your users expect you to be testing.