Antipatterns

By Peter Hornsby

Published: January 26, 2009

“When moving an organization toward good user experience practice, providing a documented—possibly extreme—example of bad practice as an antipattern can help raise awareness of what can go wrong and why we must avoid such bad practice.”

Tools for developing user interfaces have become increasingly sophisticated and available in recent years, ranging from object-oriented application development tools such as Java Swing to WYSIWYG HTML editors such as Dreamweaver. Such tools promise more rapid development—including quicker iteration—and potentially greater reliability. While we should welcome these benefits, increasing the ease of user interface development at a technical level can—perhaps ironically—make it more difficult for UX teams to operate effectively. We must bridge the gap between the technical skills we need to implement user interfaces and the skills that let us understand users and design maximally effective user interfaces for them.

Using patterns has become a well-known design practice and is also considered best practice in the software development community. While UX teams can and should constantly promote best practice, we can also approach tackling poor design practice from the other side: antipatterns. Antipatterns are approaches to common problems that might appear obvious, but are less than optimal in practice.

When moving an organization toward good user experience practice, providing a documented—possibly extreme—example of bad practice as an antipattern can help raise awareness of what can go wrong and why we must avoid such bad practice. To effectively communicate a problem that we need to solve to an entire organization, we can write an antipattern in everyday, accessible language. In addition to sharing our understanding of a problem with a client, an antipattern also helps a UX team describe a solution for the problem. An antipattern lets a UX team present a solution in context, which helps people who aren’t UX specialists understand the pitfalls that are associated with a particular practice.

Click Here Antipattern

“You can also provide anecdotal evidence of an existing problem, particularly if you can take it from the organizational context.”

Consider a common error: the use of the phrase click here as link text. Its antipattern must clearly communicate the problem and how to recognize the problem. You can also provide anecdotal evidence of an existing problem, particularly if you can take it from the organizational context. You can represent the antipattern as follows:

Antipattern name: Click here

Also known as: Navigating in a mysterious way.

Most frequently sighted: On Web pages novice developers have created.

Root causes: The false perception that a user’s model of the world is the same as that of the person responsible for creating a Web page.

Anecdotal evidence: “All you can really say is Click here…

Background: Links on a Web page need to be clear, both visually and in terms of the language we use for their labels. Common errors include the following:

  • Not clearly distinguishing links from the rest of the text on a Web page.
  • Using excessively long link text.
  • Using the phrase Click here, which relies on users’ contextual understanding of a page to understand what here means.
  • Not providing titles for links.

The applicability of the phrase Click here is device dependent. Saying Click here assumes a user has a mouse. Worse still, it tells the user nothing about where the link leads. Users visually scan pages rather than reading them, so, if a link is not clearly visible, they are likely to assume there is no other content available from a page. Even if a link is clearly visible, if the link text does not describe its destination, it forces users to work harder than necessary to understand where the link leads by reading the text around the link.

Symptoms and consequences:

  • Users are unable to identify where the links are on a page.
  • Users are unable to see where a particular link leads when scanning a page.

Typical causes: Web pages that are created in haste.

Known exceptions: It’s not necessary to underline links that are within navigation elements—such as navigation bars—because clearly communicating their status as links is contextually dependent. However, such links must still have descriptive labels and titles.

Although this is a relatively simple antipattern, it clearly identifies a UX design problem and provides a starting point from which a UX team can develop a solution.

Shiny Thing Antipattern

“A team can sometimes lose sight of the needs of users in the process of creating visual impact.”

Another antipattern results from the inappropriate use of technology. The problems this design creates can be much less clear cut than the use of the phrase Click here, because the problem results from overuse of an element rather than simply its use. Let’s look at the Shiny thing antipattern:

Antipattern name: Shiny thing

Most frequently sighted: On Web pages created by teams, on which visual impact or technology takes precedence over usability.

Root causes: The desire to create impact without getting the basics right first and a lack of awareness of good UX design principles.

Anecdotal evidence: “The hard part’s done; now we can sort out the content.” “But it looks really cool!”

Background: Flash and other technologies can create a huge visual impact on a site. A team can sometimes lose sight of the needs of users in the process of creating visual impact.

Symptoms and consequences:

  • Some or all users are unable to access the site’s content—particularly users using accessibility software.
  • Users must download one or more plugins to view the content.
  • Users experience increased download times.
  • The site is not coherent in its message.

Typical causes: Overrepresentation of technologists or visual designers on the product team.

Known exceptions: Some Web sites that are aimed at very specific, well-understood user groups for which such content is appropriate.

Good guidance is just one factor in creating an effective design, and it’s essential to apply it at the right time. Applying the Shiny thing antipattern early in the design process could help the design team identify an alternative solution—perhaps removing a Flash solution from consideration altogether or providing access to the content through parallel channels and making the Flash option only a secondary approach.

Developing Antipatterns

“By couching a UX problem in a format that is familiar to software engineers—and readily understandable by others—we make bridging the divide between disciplines easier.”

By couching a UX problem in a format that is familiar to software engineers—and readily understandable by others—we make bridging the divide between disciplines easier. Perhaps more importantly, antipatterns provide a common language and frame of reference for discussing problems—both within the product team and with those in other areas of a business.

In some cases, it might be useful to create an antipattern that brings together several aspects of a user experience and shows how they can work together. This can help overcome a perception that the UX team is focusing on the narrow detail of a problem that non-specialists might perceive as trivial.

While there are undoubtedly many ways to create an antipattern, one of the most effective methods is simply to gather your UX team together and engage in a roundtable discussion about a problem. This gives team members in different UX specialties an opportunity to exchange views on the problem—away from the constraints a specific project might impose.

Antipatterns can provide a framework that lets a UX team foster and communicate a shared understanding of why an existing solution does not work effectively. Based on this shared understanding, the team can then develop guidance for the rest of the organization and promote a more effective, user-centered approach to design.

2 Comments

In education, non-examples are frequently used when teaching complex concepts. Non-examples, which are, in many ways, the same as your concept of antipatterns, have long been regarded as an effective way of teaching individuals how to identify the attributes of a concept and how to discriminate between like concepts.

A bonus to the use of non-examples / antipatterns is that, when they are well-chosen, they are likely to elicit an emotional response, which is great for helping individuals to remember what they have seen.

This is definitely a timely article, particularly when so many articles and books are appearing that describe the benefits of design patterns.

I’m a fan of how you format your patterns—so much so I blog about antipatterns using Bill Scott’s antipattern presentation as source material.

I’m not sure the advent of WYSIWYG editors has much to do with antipatterns though, and I also think “Shiny Thing” is far too broad and vague to be considered an antipattern—any more than “clean predictable UI” is a good design pattern—but the intent of the article is spot on.

Join the Discussion

Asterisks (*) indicate required information.