User Interface Anti-Patterns

by Anders Toxboe on February 5, 2009

As you develop the skills of an experienced user interface designer you are bound to make mistakes. However, as UI-Patterns.com is a testament of, I believe that we should rather focus our attention on what can be learned from successes rather than what we can learn from mistakes.

User Interface anti patterns do not deserve their own section or being a part of the design pattern library. Nevertheless they carry some value, which is why I’ll try to list a few. Hopefully that will make you refrain from going over the same smelly waters as myself.

So what are anti patterns? A definition that resembles the definition of a design pattern is: Recurring re-invented bad solutions to solve common problems.

Common UI Anti Patterns

Ambiguous link labeling

Have you ever seen a link simply labeled: Click here? The result of using such ambiguous link label is a confused user. Where will the link take the user upon clicking on the link? This mistake is in the same category as not marking your links to stand out from the rest of your content.

Hide and hover

The hide and hover anti-pattern occurs when links to the actions of an element are not visible until you hover the element. A common example is the use of a hover effect to show and hide edit/delete links in web applications. This forces the user to explore the interface with his or her mouse instead of knowing where to click and what actions are available immediately. Some even go further in this anti pattern by leaving a margin between the hover target and the action links so that the links disappear as the user moves the mouse towards the action links.

Tiny link targets

When building a site’s navigation, a common pitfall is to provide way too small click targets for links. This will frustrate the user as he or she will have to spend more mental energy on clicking on a small link target than a bigger one. Instead provide gracious padding to links to fill up the white space between elements. Fitts’ law states that the time to move your cursor to a target is a function of the distance to the target and its size. Making interaction points too small is a good way to frustrate your users.

Not using labels for radio and checkboxes

Apparently, not everybody are aware that the <label> html tag acts as a link target for radio and checkboxes.

Use of rocket science to solve simple problems

Sometimes a designer constructs a solution that is much more complex and confusing than the prior solution. The anti-pattern is often seen when designers have explored new ways of doing things that are then forced upon simple problems. An example is use of drag-and-drop techniques for simple attribute setting. Does a shopping cart need drag-and-drop functionality and are you sure you need fade and fold effects to make your user interface better and more understandable?

Designing for the perfect use-case

Some say the user is dumb. I would rather say that the user never stands a chance guessing your initial intentions. Design your interface defensively and provide feedback to unintended input. Think about how your user interface can and is interpreted by different users and remember to do user testing!

One at a time

When dealing with lists, it can annoy and frustrate users not being able to perform the same action on multiple items in a list at the same time. Project management applications with todo list functionality such as Basecamp or Backpack suffer from this anti-pattern, as you can only check one item at a time.

Webmail software solve this problem by having a “Select all” button that will check all checkboxes for each mail. But what if you want to perform the same action on more than just the items that are visible on the page you’re viewing? At my workplace, there is a space limit on my mail account of 350MB. Deleting mails in order to get below the limit is a tiresome task as only 20 mails can be deleted at a time in MS Outlook’s webmail.

Bloated user interface

A bloated user interface tries to incorporate as many operations as can possibly fit into it with the end result of confusing more than helping the user to perform his or her task. A bloated user interface often include features that cannot be used on kinds of data the interface handles.

The magic push button

Some will argue that interface design should be separated from coding. Those people tend to follow a development methodology parted into phases, also known as the Waterfall model.

In this worldview, designers tend to draw the interface first then followed by the business logic only to discover that the “magic button” can’t just do what it should do – a number of steps are required by the user in order for that to happen. This is why good designers with an understanding of the coding paradigm are valuable assets.

Unfactorable interfaces

When interfaces emerge they are often simple and well thought out. Over time as several different designers each put their hand on an interface correcting and changing things here and there, the interface often grows into a monster that does a gazillion things more than it was originally intended to do.

At some point it looses its coherence and becomes an unstoppable monster. Agile programming talks much about staying lean by always refactoring your code to being the simplest possible working solution. One should never design ahead and prepare for what might be needed in the future, but only keep to what is needed right now.

If prior features are not needed anymore, they should be removed in order for the system to stay lean and be prepared for change. The same can be said about interfaces. They should always be the simplest possible working solution. If they change direction over time, they should still represent the simplest possible working solution for what it is changed into.

What common pitfalls do you tend to fall in to?

What are your user interface anti-patterns?