UI annoyances

In daily life, we encounter usability issues all the time. This can be in software, but it is applicable to general design as well. This article highlights some examples of bad design choices, both in everyday objects and software.

 One of the principles of design is: if the product needs an explanation for every tiny detail, it's probably too complicated. Norman discusses therefore some examples for everyday objects. In this case, people are likely to blaim themselves for having a wrong model of how something is supposed to work, since it seems trivial once you know how to do it. Some examples:

• Controls for cooking fires. Normally, the plates on cooking fires are structured into a rectangular or triangular grid. Additionally, there might be an oven as well. Unfortunately, the controls are aligned in a row without an obvious mapping to the plate configuration (or the oven). Therefore, people often use the wrong control.
• The same applies to lighting switches: it's hard to know which switch controls the desired light.
• When I was in Sweden last year, some ATMs refused to take in my card. After studying the device, I noticed a label stating that the card should be inserted upside down. This is clearly inconsistent with the majority of ATMs. Even when I knew it, I kept making the mistake again and again.
• Doors are one of Norman's favourite examples. With good reason. I had some troubles myself figuring out how to use them. Should I push or pull? If so, where? Here, the problem can be solved using a design with the right 'affordances'. If a door should be pushed, make it impossible to pull. Labelling is not a real solution. For example, again in Sweden, Stockholm, the subway station's doors are labelled "dra" (pull) and "tryck" (push). However, in Dutch, which is quite similar, we use "duwen" or "drukken" (push) and "trekken" (pull). Quite confusing.

In software design, the problem is even worse. Because a program is generally conceived as more complex than a door or switch, people are even more likely to blaim themselves and not the design. Note that, ideally, software could be as easy to operate as a well-designed object such as scissors. The user should get (only) the right information at the right time in the right way to convey the intended message. This is easier said then done. It requires a lot of feedback from actual users. As an illustration, some software UI issues:

• Students using KotNet at the KULeuven are required to log out if they want to log in via a second system within the auto-logout period. Annoyed, you decide to walk through the procedure quickly. When you complete it, you get a red message on your screen to indicate success, similar to the error message you get when login fails. This is consistent in the sense that it indicates you're not logged in. I think however that most users will wonder whether they did something wrong when logging out.
• Shortcuts such as Ctrl+C and Ctrl+V are rather arbitrary, but once you've learned the convention, you use them a lot because many applications implement this functionality consistenly. Yet, my version of Matlab, shines by inventing its own convention. The equivalent for the actions mentioned before are Alt+W and Ctrl+Y. In fact, all shortcuts are different, except perhaps for Alt+F4. Most likely implemented in the window manager.

Perhaps it is impossible to do the right thing for all users - you will always need to strike a balance between functionality, easy of use, effectiveness, efficiency and many more aspects of a design. Yet, usability should be a contribution design goal of equal weight compared to more functional goals. As they say: if something is difficult to use, people will tend to avoid using it, whatever its power...