Download a free copy of “The New Design Fundamentals” ebook, a curated collection of chapters from our Design library. Note: this post is an excerpt from “Designing Social Interfaces,” by Christian Crumlish and Erin Malone, which is included in the curated collection.
With the growing expectation of seamless experiences, it is important for designers to see the emerging standards and to understand how one experience of a site and its interactions affects expectations for the next site. By working with standard and emerging best practices, principles, and interaction patterns, the designer takes some of the burden of understanding how the application works off the user, who then can focus on the unique properties of the social experience she is building.
To start, we do define these three things differently. They live along a continuum, from prescriptive (rules you should follow) to assumptions (a basic generalization that is accepted as true) to process (ways to approach thinking about these concepts).
Principle: A basic truth, law, or assumption
Principles are basic assumptions that have been accepted as true. In interaction design, they can lend guidance for how to approach a design problem, and have been shown to be generally true with respect to a known user experience problem or a set of accepted truths.
For example: be learnable — create systems that are easily learned and provide cues for users to predict how things work from one area to another.
Principles don’t prescribe the solution, though, like an interaction pattern does; instead, they support the rationale behind an interaction design pattern or set of best practices.
Practice (or best practice): A habitual or customary action or way of doing something
Best practices are funny things. They are often confused with principles or interaction patterns. They fall along the continuum and are less prescriptive than an interaction pattern solution — at least in our definition. We often include best practices inside an interaction pattern.
For example: in a mobile context, design for touch. Make sure buttons, forms and other elements are large enough to interact with and accommodate human fingers without accidentally triggering neighboring elements.
The best practice helps clarify how to approach a design solution, and is generally the most efficient and effective way to solve the problem, although not necessarily the only way.
Pattern: A model or original used as an archetype
When we first started working with interaction design patterns, we defined a pattern as: common, successful interaction design components and design solutions for a known problem in a context.
Patterns are used like building blocks or bricks. They are fundamental components of a user experience and describe interaction processes. They can be combined with other patterns as well as other pieces of interface and content to create an interactive user experience. They are technologically and visually agnostic, meaning we do not prescribe particular technological solutions or visual design aesthetics in the patterns. User experience design patterns give guidance to a designer for how to solve a specific problem in a particular context, in a way that has been shown to work over and over again.
The notion of using interaction design patterns in the user experience design process follows the model that computer software programming took when it adopted the concepts and philosophies of Christopher Alexander. Alexander, an architect, wrote the book A Pattern Language. In his book, he describes a language — a set of rules or patterns for design — for how to design and build cities, buildings, and other human spaces. The approach is repeatable and works at various levels of scale.
Alexander says that “each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.”
In addition to developing this language of elemental repeatable patterns, he was concerned with the human aspect of building. In a 2008 interview, Alexander says that his ideas “make [homes] work so that people would feel good.” This human approach and concern for the person (as user) is part of what has appealed to both software developers and user experience designers.
The idea of building with a pattern language was adopted by the computer software industry in 1987, when Ward Cunningham and Kent Beck began experimenting with the idea of applying patterns to programming. As Ward says, they “looked for a way to write programs that embraced the user, where users felt supported by the computer program, not interrogated by the computer program.”
This approach took off, and in 1995, the book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (known as the Gang of Four) was published.
In 1997, Jenifer Tidwell published a collection of user interface patterns for the human-computer interaction (HCI) community based on the premise that capturing the collective wisdom of experienced designers helps educate novice designers and gives the community as a whole a common vocabulary for discussion. She specifically stated that she was attempting to create an Alexandrian-like language for interface designers and the HCI community. The evolution of that site and her work became the book Designing Interfaces, published in 2005 by O’Reilly Media.
Several others published collections on the Web, including Martijn van Welie, a long-time proponent of patterns in the interaction design realm, which in turn inspired my (Erin’s) team at Yahoo! to publish portions of our internal interaction pattern library to the public in 2006.
I (Erin) had joined Yahoo! in 2004 to build a pattern library for the ever-growing user experience design team and to create a common vocabulary for the network of sites that Yahoo! produced for its hundreds of millions of global users. We built the library in a collaborative manner, utilizing the most successful, well-researched design solutions as models for each pattern. Designers from across the company contributed patterns, commented and discussed their merits, added new information as technology and users changed, and moderated the quality and lifecycle of each pattern.
In 2006, spearheaded by Bill Scott, we were able to go public with our work with a subset of the internal library. The work was very well received by the interaction design and information architecture community, and inspired many in their design work. From 2007 to 2010, [my co-author] Christian further evangelized the library to bridge the gaps between design and development and open source communities. Since our first edition, several other pattern libraries have joined the growing body of work, including pattern collections for mobile, for Android specifically, for supporting responsive code libraries, and many other companies have publicly published their libraries (MailChimp, BBC, Intuit Small Business’s Harmony ecosystem, Google and their Material Design patterns) in order to share their knowledge, inform third-party developers and inspire the design community.
The notion of having a suite of reusable building blocks to inform and help designers develop their sites and applications has gained traction within the interaction design community as the demands for Web and mobile interfaces have become more complex. When the Web was mostly text, there wasn’t a whole lot of variety to how a user interacted with a site, and the toolkit was small. The complexity of client applications was difficult at best to duplicate online. But that was then. Now, whole businesses and industries rely on easy-to-use Web-based software (SAAS) and mobile applications to conduct their business. There is more need than ever to have a common language for designers and developers. And because social is now integrated into every facet of interactive experiences, it is important to put a stake in the ground about just what those pieces should be and how they should and shouldn’t behave.
The importance of anti-patterns
The term “anti-patterns” was coined in 1995 by Andrew Koenig in the C++ Report, and was inspired by the Gang of Four’s book Design Patterns.
Koenig defined the term with two variants:
- Those that describe a bad solution to a problem that resulted in a bad situation.
- Those that describe how to get out of a bad situation and how to proceed from there to a good solution.
Anti-patterns became a popular method for understanding bad design solutions in programming with the publication of the book Anti-Patterns: Refactoring Software, Architectures, and Projects in Crisis, by William Brown, et al.
For our purposes, anti-patterns are common mistakes or a bad solution to a common problem. It is sometimes easier to understand how to design successfully by dissecting what not to do. In the world of social experiences, often the anti-patterns have some sort of jarring or malicious side effects, like social group faux-pas or, in the extreme, identity theft.
The anti-patterns we illustrate in Chapters 2 and 3 will point out why the solution seems good and why it turns out to be bad, and then we will discuss refactored alternatives that are more successful or gentler to the user experience.