Tuesday, 8 May 2012

Heathrow Terminal 4 Usability Failure

Airports and Underground systems are often used in usability case studies. The clear and simple iconography an well thought out signs help countless people no matter their language. They help clarify how best to sign post and navigate large areas and can provide great material to study.

However, Heathrow Terminal 4 does have quite a usability failure on its hands in terms of the toilets. Above every single tap is a yellow warning exclamation mark with the text, caution extremely hot!

The message is correct the water is nearly too hot to use, and certainly too hot to use for much longer than a very short period of time without burning yourself.

This is a failure on so many levels, but I feel it is an illustration in how a simple related solution removes obstacles in usability.

If the water temperature was reduced a few degrees then there would be no issue with using the water and there would be no need for the signs. In addition there is likely to be a reduction in cost as heating the water to that temperature is likely to be much more costly than a lower temperature. There are many other bonuses such as a more pleasant experience, a cleaner visual aesthetic without the warning signs.

Essentially by identifying the root of the problem then a better solution can be achieved.

Now there are many possible explanations for the choice of adding the signs instead of fixing the water system.

1 .The temperature cannot be controlled or is too expensive to adjust. This seems an unlikely issue.
2. They need to significantly reduce water use and so making the water too hot stops people from using the water. This is possible, but given the automatic taps and reasonably slow flow of water it appears less likely that this is the cause.
3. It may be a temporary solution to a problem which requires extensive work. Again it does seem unlikely that there is much more required than a thermostat setting.

It appears most likely that there is an interdepartmental communication problem and as a department was able to "solve" a problem they took it upon themselves to create their shoddy option rather than the real solution.

This situation can be witnessed in software development very frequently, where one suboptimal choice leads to a second suboptimal choice and then the UI ends up being a horrible mess. It is very common that a feature can be removed/replaced to dramatically reduce the complexity of an interface. The trick is to find these messy points and question the features that have been implemented to see if there is a better way.

No comments: