The attack of the badly designed shower fittings (part 2)

Last week I asked why you thought this shower fitting was so bad:

Shower

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 usability@red-gate.com.

*Since Austin Salonen got closest, he gets the $100 vouchers. Well done Austin!