Last week I asked why you thought this shower fitting was so bad:
You gave a number of answers, some close* and some not so close (it really is a shower, not a chocolate dispenser, Mr Flibble).
Most of you guessed how the shower works. The larger dial, mounted nearest the well, controls the flow of water. Turn it anti-clockwise and you get more water, clockwise and you get less. The smaller dial controls the heat. Anticlockwise for hot, clockwise for cold. Not a great design, but not appalling: how it functions isn’t obvious but at least it’s discoverable.
There is, however, a fundamental and dangerous flaw with the shower. The hot/cold dial is slightly loose on its bearings, and there’s friction between the two dials. As you turn up the shower’s flow, the larger dial rubs against the smaller dial and the smaller dial shudders anti-clockwise. Since the balance between pleasant and scalding is a fine one in most hotels, you get burnt. Secondly, the lever on the heat dial is too heavy for its bearing. As you shower, its weight pulls the dial anti-clockwise. Again, scalding water.
At this point you might accuse me of asking an unfair question. There’s no way, you say, you could have spotted this from just looking at the picture or even from looking at the shower itself. You’d have to watch me interact with the shower to spot the issues I was having.
To which I say: exactly.
You could look at this design for a week and not spot the obvious faults. You could even play with it, in your design or development studio, and not see what’s wrong with it. If you’re the designer, you could possibly even use it, hooked up, in the real world and still call it easy to use, claim that users would figure it out and blame malfunction on user error.
But if you saw me, a real user, try to use it in a real-life situation then its faults would be obvious. The swearing and screaming would give it away.
The same is true for software. On paper, a design can look good. Even when you code it up it can look great. You, the designer or the developer, think that it’s the most intuitive, simplest interface possible. Only a fool could fail to use it. But put it in front of a user and it could easily fail. The only way to make your software usable is to watch people using it. Or – more likely – failing to use it.
It’s slightly more complicated than that, of course. There are numerous books out there on how to conduct usability trials. If you haven’t already, then read up on it and try it out. I guarantee that it will be both fun and eye-opening.
At Red Gate we’re always looking for people to participate in our usability trials. It’s normally a fun experience for users, and it gives you a chance to influence the future direction of our products. If you’re a SQL Server professional or .net developer and can spare about an hour of your time for a worthwhile and interesting experience then send Jenny an e-mail at us*******@re******.com.
*Since Austin Salonen got closest, he gets the $100 vouchers. Well done Austin!
The first thing I look for in an interface of any kind is familiarity. Whatever other flaws or advantages this shower fitting has, it fails the familiarity test in a spectacular way. Sure, I support doing user testing, but I would think that, for anybody concerned with usability, rather than with form and style, this shower fitting would never have made it out of brainstorming.
The difference between shower fittings and software user interfaces is that shower fittings have a long history behind a few common interaction designs (two valves to control hot and cold water and a valve to switch between faucet and shower being the most common in U.S. homes prior to the 1980s) while software user interfaces are, essentially, brand new. The problem faced by someone design a user interface for a new computer program is that there just isn’t enough history of familiar and effective interfaces to draw upon. Running user trials is the only way to know if your fabulous new interface is clever or just obscure.
Are you kidding ? It’s intuitively obvious to the casual observer that’s a crap design for the reasons that play out in real life: turning one may turn the other. It optimizes the wrong problem, a common error.
It certainly isn’t an improvement on any standard design.
I apologize for this cheap shot, but maybe you might want to watch a Red Gate client try and renew his license. I admit I didn’t scream and no bodily parts were harmed, but there was plenty of swearing “giving it away” 🙂
Dirk,
We have just rewritten our licensing client because it was obvious that it was causing problems (both to us and our customers). Perhaps you could e-mail me at ne***********@re******.com and let me know what issue you had? Ie was it with the process / the software / the web site?
Default settings, in software or shower fitting, should not burn the user. For most of its useful life, shower dial dispenses lukewarm water (70-85F). Instead of having a great default value for temperature and control of flow, we have no control over temperature since we have to battle flow at the same time. You could said that the “middle” setting works as a default but it does not.