How to Ensure You Don’t Violate UI Design Patterns

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.

Why You’ll Hurt Your Finger

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.

Why I Can’t Turn Off My Car’s Heater

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.

Why Every Checkbox Circle is Filled in

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.

How Does This Happen?

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:

  • The hotel is old enough that the elevators may, originally, have an operator who would have known where the buttons were. The designer was more interested in creating an elegant impression than usability. Design pattern violated: The items the user must interact with should stand out.
  • The climate control button that said “off” (but would turn things on) is probably the result of adding more widgets to the display. What was once a separate label reporting the state of the climate control system was moved inside the button to save space as the display grew more crowded. Design pattern violated: Captions on buttons tell you what clicking the button will do.
  • Someone originally designed the option screen using circles for checkboxes, but then discovered that users assumed they could only make one choice (mistaking the circular checkboxes for radio buttons). Rather than reverting to using square checkboxes, they decided to signal that the circles were really checkboxes by prefilling them with light-blue checkmarks. Design pattern violated: Checkboxes are square and only the options you’ve selected have a checkmark.

Avoiding Confusion

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, AppleWindows, 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.

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.