The Second Edition is out!
Visit designinginterfaces.com to read excerpts and learn more.

About Patterns

In essence, patterns are structural and behavioral features that improve the "habitability" of something -- a user interface, a Web site, an object-oriented program, or even a building. They make things more usable, easier to understand, or more beautiful; they make tools more ready-to-hand.

As such, patterns can be a description of best practices within a given design domain. They capture common solutions to design tensions (usually called "forces" in pattern literature) and thus, by definition, are not novel. They aren't off-the-shelf components; each implementation of a pattern is a little different from every other. They aren't simple rules or heuristics either. And they won't walk you through an entire set of design decisions -- if you're looking for a complete step-by-step description of how to design a UI, this isn't the place!

In this work, patterns are described literally as solutions to design problems, because part of their value lies in the way they resolve tensions in various design contexts. For instance, a UI designer who needs to pack a lot of stuff into a too-small space can use a Card Stack. All that remains to the designer is to work on the information architecture -- how to split up the content into pieces, what to name them, etc. -- and what exactly the Card Stack will look like when it's done. Tabs? A left-hand-side list or tree? That's up to the designer's judgement.

Some very complete sets of patterns make up a "pattern language." These are a bit like visual languages, in that they cover the entire vocabulary of elements used in a design (though pattern languages are more abstract and behavioral; visual languages talk about shapes, colors, fonts, etc.). This set isn't nearly so complete, and it contains techniques that don't quite qualify as patterns. However, it is concise enough to be manageable and useful.

How to Use These Patterns

As mentioned before, this work doesn't present a step-by-step process for constructing a UI design. The categories of patterns are arranged more or less by scale, and therefore by their approximate order in the design progression -- large and important decisions about content and scope are made first, followed later by page design, and finally, the details of interaction with forms and canvases. But design is never quite linear, and these patterns shouldn't be your entire universe of design possibilities:

  • If you don't have years of design experience already, a set of patterns may serve as a learning tool. You may want to read over it to get ideas, or refer back to specific patterns as the need arises.

  • Each pattern in this collection has at least one example. Some have many; they might be useful as a sourcebook. You may find wisdom in the examples that is missing in the text of the pattern.

  • If you talk to users, engineers, or managers about UI design, or write specifications, then you could use the pattern names as a way of communicating and discussing ideas. This is another well-known benefit of pattern languages.

  • Each pattern description tries to capture the reasons why the pattern works to make a UI easier or more fun to use. If you get it, but want to do something a little different from the examples, you can be creative with your "eyes open."
One more caution: A catalog of patterns is not a checklist. Each design project has a unique context, and even if you need to solve a common design problem (like how to fit too much content onto a page), a given pattern might be a poor solution within that context. No reference can substitute for good design judgement. Nor for a user-centered design process: careful requirements gathering, prototyping, and usability testing should be done in every design project.

Ultimately, you should be able leave a reference like this behind. Experienced designers will have internalized these ideas to the point at which they don't notice they're using them anymore; the patterns become second nature.

Other Pattern Collections

The text that started it all was written about physical buildings, not software. Christopher Alexander's A Pattern Language, and its companion book The Timeless Way of Building, established the concept of patterns and described a 250-pattern multilayered pattern language. It is often considered the gold standard for a pattern language because of its completeness, its rich interconnectedness, and its grounding in the human response to our built world.

In the mid-1990s, the practice of commercial software architecture was profoundly changed by the publication of Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. This is a collection of patterns describing object-oriented "micro-architectures." If you have a background in software engineering, this is the book that probably introduced you to the idea of patterns. Many other books about software patterns have been written since. Software patterns such as these do make software more habitable -- for those who write the software, not those who use it!

The first substantial set of user-interface patterns was the predecessor of this patterns collection, Common Ground. Many other collections and languages followed, notably Martijn van Welie's Interaction Design Patterns, and Jan Borchers's book A Pattern Approach to Interaction Design. Very recently, a full-fledged Web site pattern language was published, called The Design of Sites. I highly recommend it, especially if you're designing traditional Web sites. If you're building applets or desktop applications, or if you're pushing the boundaries in either domain, take a look at all of these; you might find inspiration in any of them.