It was a dark and stormy night... accounting for the physical when designing the digital

Yesterday, I used the London cycle hire scheme for the first time. I had checked all the instructions on how to hire a bike online before heading off to the nearest cycle station, all prepared with my cycle helmet and my payment card. For various reasons, it was dark and drizzling by the time I got there. The cycle station display was well illuminated, so I could go through the early stages of the transaction without difficulty, but then it came to inserting the payment card. Ah. No illumination. No nearby streetlight to improve visibility. I found myself feeling all over the front of the machine to locate the slot… which turned out to be angled upwards rather than being horizontal like most payment card slots. I eventually managed to orient the card correctly in the dark and get it into the reader.

Several steps of interaction later, the display informed me that the transaction had been successful, and that my cycle release code was being printed. Nothing happened. Apparently, the machine had run out of paper. Without paper, there is no release code, and so no way of actually getting a cycle from the racks.

To cut a long story short, it took over 30 minutes, and inserting my payment card into four different cycle station machines distributed around Bloomsbury, before I finally got a printed release code and could take a bicycle for a spin. By then it was too late to embark on the planned errand, but at least I got a cycle ride in the rain...

The developers have clearly thought through the design well in many ways. But subtleties of the ways the physical and the digital work together have been overlooked. Why is there no illumination (whether from street lighting or built into the cycle station) for the payment card slot or the printout slot? Why is there apparently no mechanism for the machine to detect that it is out of paper before the aspiring cyclist starts the interaction? Or to display the release code on-screen to make the system more resilient to paper failure? Such nuanced aspects of the situated use of the technology in practice (in the dark and the rain) have clearly been overlooked. It should be a universal design heuristic: if you have a technology that may be used outdoors, check that it all works when it's cold, dark and damp. Especially in cold, dark damp cities.

If we can't even design taps...

Today, I got a wet arm: the tap control was immediately behind the faucet, so I reached through the line of fire to turn it on, and the inevitable happened. But it looks Well Designed:

I thought I had already encountered every possible type of poor design: the tap that is unpredictable because there is only one control to govern both temperature and flow rate:

The tap that needs the explicit notice to tell the user how to make it work:

The taps where it's almost impossible to tell whether the water will flow from the shower head or the main tap:

The tap that looks as if you should turn it, when actually that controls the temperature, not the flow; for that, you have to pull the control towards you:

Yvonne Rogers told me of a tap that would only work if you were not wearing black....

The user of a tap wants to control two parameters: the temperature and the flow rate. There are plenty of designs around that enable people to do this without any faff at all. But these are apparently not interesting or exciting or aesthetically pleasing enough. So innocent users get frozen, scalded, bemused or unexpectedly wet as tap designers devise ever more innovative taps. If we can't even get tap design right, what hope for more complex interactive technologies, I ask myself...