Remember: When you can’t figure out what to do next, it’s not your fault — it’s the user interface designer’s fault. And, nine times out of ten, the reason you can’t figure out what to do next is because the designer failed to correctly implement standard UI design patterns. Here are some examples of design patterns that you know…and where some designer went wrong with them.
In Learning Tree’s UX design course, we talk about design patterns quite a bit. Design patterns are recognizable pieces of user interface functionality that, the UI designer hopes, will be recognized by the application’s users. Design patterns aren’t complicated — a standard button is a perfect example of a design pattern: Something that user will recognize that a designer can combine with other patterns to create a complete UI.
The key part of a useful design pattern is that it must be something that users will recognize. And, by “recognize,” I mean something very specific: The user will know how to interact with the widgets that make up the pattern and have some pretty specific expectations about what will happen when they do. Again, a button is a great example: users know that they have to click on buttons and that, once they do, something will happen (usually, something related to the caption on the button).
That doesn’t mean UI developers always get the design pattern right, though.
I know that because each of these patterns led me into error (you can, if you wish, assume that you wouldn’t have fallen into these traps). Design patterns have names (like “the button pattern”) so I’ve given these mis-implementations their own pattern names, too. It only seems fair…
And, to protect the guilty — and to ensure that I don’t violate anyone’s copyright — I’ve just provided some of my own hand drawn sketches of the UIs involved.
This is a sketch of a form that I use every month as part of paying my bills. I’ve marked the placement of the three buttons on this form with the numbers 1, 2 and 3. The good news is that they each implement the button pattern correctly: A user really can click on these buttons and they really will do something. The problem here is how they work together — specifically, which one is the main/default button (the button that performs the “typical” task for the form)? While you’re thinking about whether it’s button 1, 2, 3, I’ll just mention some another feature of design patterns.
Most design patterns come with some restrictions about where they can be put and how they can be used with other patterns. For example, if you put a static, vertical menu down the right-hand side of the screen instead of across the top or down the left-hand side, I suspect you would confuse many users (in fact, I bet that many users wouldn’t find the menu at all).
With the button design pattern you have relatively few restrictions — if you only have one button on a page, there are very few places where you shouldn’t place it. I’d try to avoid putting buttons across the top of a form or page, for example, because users expect a menu or title to go there…but outside of that case, I can’t think of any place for a standalone button that’s guaranteed to baffle users. Placing each of the buttons where you see in my diagram isn’t out of the question.
But most ‘multiple button design patterns’ organize buttons into groups so I’d wonder why these buttons are so far apart. One UI design pattern divides a page into panels with each panel having its own button — this page, however, has only one panel. Furthermore, if you have more than one button on your form then you need to decide where the default button goes. If you’re a Windows user, you know the answer to this question: the default button goes in the lower right-hand corner of the form. I’ve noticed that’s where most Web pages put it, also (unless the page has only one button, in which case, while the button still goes at the bottom of the form, it’s sometimes put in the center of the page, rather than in the corner).
Following that pattern means that my most likely choice for the default button in my example is either button 2 or 3. This is bad: Giving users choices isn’t useful here because it forces the user to stop and think about what to do when performing the ‘typical’ task. In a good UI, performing the typical task should require virtually no thought at all.
But, in this case, it doesn’t matter which of button 2 or 3 the user picks because neither of them is the default button. The default button is in position 1 — just about as far away from the standard position as it can get without moving to the top of the form.
You’ll be happy to know that I did, eventually find the right button. However, I used button 3 twice before I finally gave up, read the captions on all three buttons, and figured out that I was supposed to use button 1.
The teaser pattern is one of my favorite design patterns because it works so well and no one realizes why. When the UI is displaying a list of information, the teaser pattern helps to tell the user if they should scroll down because there’s “more to see.” All you do in the teaser pattern when there is “more to display” is to show just the top half of the last item on the list. Without providing a scrollbar or any other visual feedback, the fact that part of the last item appears to be displayed below the edge of the screen tells users that they can scroll down.
This pattern is normally implemented for vertical lists but it can also be used horizontally…though the designer in the picture above didn’t pull it off. In the picture above, the UI designer had three tabs to display. However, rather than try to fit all three on the screen, the designer chose to display the first two tabs and leave the third off the screen. If you press on tab B, everything shifts right and tab C is revealed.
The problem is that if you never press on tab B, you’ll never know that tab C is there. The UI designer should have implemented the teaser pattern and shown some of tab C on the right-hand edge of the tabs. Not a lot of space would be required to tell the reader that there is another tab to display (see below — I’ve even shaded in how much of tab C I think would be required to let the user know that there’s more to see).
Because, in this case, the missing tab is hiding something you could do with the application (rather than just concealing some more content) I might also have called this the “Hidden Functionality pattern.” Why you would want to hide some of your application’s functionality is a mystery to me.
This is obviously an implementation of the carousel design pattern (at least, I hope my diagram is obvious). The problem here is not with getting the user to do the right thing (even I figured out that I could click on the arrows on the right or left side of the item in the middle to move between all of the items in the carousel). Nor is the problem with with what’s in the middle: The items in the middle were obviously pictures of the company’s store.
The problem here is the user’s expectations: What happens when the user moves through the items in the carousel or clicks on the item currently displayed in the carousel. There are two expectations that users have with the carousel design pattern:
In this case, the designer picked a third choice: Nothing happens as you move through the carousel (well, other than displaying another picture of the business). You can whack away on the picture in the middle until the cows come home…but nothing will happen. Since this is a mobile app, the developer has given up most of their screen’s real estate to something that does nothing for you. Or for them, for that matter.
So, the next time you find yourself fruitlessly banging on some UI without anything happening or, instead, getting some completely unexpected result, take a moment to look at the UI. Try to see what design pattern convinced you that what you were doing was going to work. Then figure out what the UI designer should have done. If you can do those two things then you, too, could be a UI designer.