This blog post is, admittedly, a list of ”User Interface failures” that you’ve suffered through, from badly designed elevators to the screen in the dashboard of your car. However, it’s also about what leads to these UI failures and how they could have been avoided — including a useful list of resources.
I stay at one hotel quite frequently (<name omitted to protect the guilty>). The hotel’s elevators have an interesting feature: Each has a panel that holds the buttons, with each button having a black-enameled label. It’s much like the picture on the left (only classier because, at my hotel, the whole panel is in brass). What’s interesting is that, unlike the picture on the left, almost all the black enamel has been worn off on every label, on every panel, in every elevator.
And I guarantee that if you ever stay at the hotel and ride in its elevators, you’ll contribute to the problem. Let me explain why.
In this hotel’s elevator, the labels for the buttons consist of the floor numbers in raised brass with the equivalent text in braille below the number. The whole label is surrounded in a pebbly black enamel. It’s very attractive — striking, even. In my hotel, however, the elevator buttons themselves (unlike the ones in the picture) are very discreet: They’re set flush with the panel, are made of the same polished brass as the panel, and have only a thin line around them that separates them from the rest of the panel. The actual buttons are, in fact, so subtly designed as to be almost invisible.
If you step into the elevator, the first thing you notice is the labels which, interestingly enough, look exactly like what you expect a button to look like (and, remember, the real buttons are almost invisible). So, it’s the labels that you punch, erasing a little more enamel as you do. It’s only after you’ve stubbed your finger on the unyielding label that you’ll notice the subtle signals that mark the buttons. At that point, you’ll successfully press the button that will take you to your floor.
This kind of mistake isn’t limited to hardware. As an example, I’m greeted with another button-related failure every time I get in my car.
In my car, the software-driven display panel lights up as soon as I start my car. The display panel presents a label ”climate control” with a button underneath it with the caption ”off”. You would think pressing the button that labeled ”off” would turn my heater or A/C off…but you would be wrong. That button is actually a toggle and its caption is reporting the current state of my climate control. The caption isn’t telling me what the button does, it’s telling me the current state of my climate control system.
So, if I press what looks like a button that’s clearly labeled ”Off” then I turn my heater on.
And the problem extends to websites. A few days ago, a website presented me with a list of options that I could select. Those options were presented as a set of checkboxes…except the boxes were circles. This was already confusing because circles normally represent radio buttons: Exclusive options where the user is allowed to select only one. Yet, as I read the options, they were clearly additive and I could select as many as I want.
I got over that bit of confusing visual noise but only to move on to another problem: Literally, every option already had a checkmark in its circle. It seemed unlikely to me that I should be selecting all the options.
Eventually, I did notice that some checkmarks were light blue while others were a darker blue. After some experimentation, I realized that the dark blue circles were the only ones ’checked’; The lighter blue circles weren’t really ’checked’ (even though they already had checkmarks in them). Clicking on a checkbox-circle changed the already present checkmark from light blue to darker blue and selected the option.
With these UIs, I was initially confused and had to waste some time trying to figure out what I was supposed to do. It seems unlikely that was what the designers of these UIs wanted to do.
I suspect the reason all the designs were confusing were due a series of steps that resulted in the designers incompletely implementing some standard design patterns:
There are various ways to make a UI confusing by corrupting your users’ expectations about how a UI should work. The solution is simple: Do what your users expect by consistently and completely implementing the design patterns your users are familiar with. Implementing ”half a pattern,” as you’ve seen, just confuses your users.
If you want a list of those design patterns and how to implement them, you don’t have to look far. Here’s a list from Learning Tree’s UX course of some of the sites that provide an inventory of UI patterns that your users already understand:
For mobile applications, here are two more sites we refer to in the course:
In addition, for mobile patterns, you should also check out Theresa Neil’s book ”Mobile Design Patterns for Smartphones.” And, of course, reviewing the UI guidelines for whatever platform you’re targeting (Android, Apple, Windows, and the MacIntosh are the big four) is another good idea. Your users know these patterns and conventions — take advantage of that! You’ll be a hero to your users.