Design Patterns Introduction


In essence, patterns are structural and behavioral features that improve the “habitability” of something — a user interface, a website, an object-oriented program, or a building. They make things easier to understand or more beautiful; they make tools more useful and usable.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 lit- erature) and thus, by definition, are not novel. They aren’t off-the-shelf components; each implementation of a pattern differs a little 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 an interface, a pattern catalog isn’t the place to find it!

Patterns are:

1- Concrete, not general

All designers depend upon good design principles, like “Prevent errors,” “Create a strong visual hierarchy,” and “Don’t make the user think.” It’s rather hard, however, to design an actual working interface starting from fundamental principles! Patterns are concrete enough to help fill the space between high-level general principles and the low-level “grammar” of user interface design (widgets, text, graphic elements, alignment grids, and so on).

2- Valid across different platforms and systems

Patterns may be more concrete than principles or heuristics, but they do define ab- stractions—the best patterns aren’t specific to a single platform or idiom. Some even work in both print and interactive systems. Ideally, each pattern captures some minor truth about how people work best with a created artifact, and it remains true even while the underlying technologies and media change.

3- Products, not processes

Unlike heuristics or user-centered design techniques, which usually advise on how to go about finding a solution to an engineering or design problem, patterns are possible solutions.

4- Suggestions, not requirements

You should almost always follow good design principles and heuristics, of course. And organizations need designers to follow style guides so that their products stay self-consistent. But patterns are intended to be only suggestions; you can follow them or reject them, depending on your design context and user needs.

5- Relationships among elements, not single elements

A text field is not a pattern. The spatial relationships between a text field and a piece of help text near it, however, might be a pattern. Likewise, changes in a set of elements over time—as a user interacts with the software—may constitute a pattern, though some patterns capture only static relationships.

6- Customized to each design context

When a pattern is instantiated in a design, the designer should adjust the pattern as needed to fit the situation. You could use some of the pattern examples verbatim, but as long as you understand why the pattern works, why not be creative? Fit the pattern to your particular users and requirements.Some very complete sets of patterns make up a “pattern language.” These patterns resemble 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, icons, colors, fonts, etc.). The set in this book isn’t nearly as complete, and it con- tains techniques that don’t qualify as traditional patterns. But at least it’s concise enough to be manageable and useful.

How and when you cay use these patterns?


If you don’t have much design experience, a set of patterns can 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. Just as expanding your vocabulary helps you express ideas in language, expand- ing your interface design “vocabulary” helps you create more expressive designs.


Each pattern in this book has at least one example. Some have many; they might be useful to you as a sourcebook. You may find wisdom in the examples that is missing in the text of the pattern. If you’re a designer who knows the patterns already, the examples may be the most useful aspect of the book for you.


If you talk to users, engineers, or managers about interface design, or if you 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. (The terms “singleton” and “factory,” for instance, were originally pattern names, but they’re now in common use among software engineers.)

Comparison of design alternatives

If you initially decided to use Module Tabs to organize material on a page and it’s not working quite as well as you hoped, you might use these patterns to come up with al- ternatives, such as Titled Sections or an Accordion. Other sets of “either/or” patterns are presented in this book, often with reasons to choose one pattern or another. Skilled designers know that presenting alternative designs to clients frequently leads to a better choice in the end.


Each pattern description tries to capture the reasons why the pattern works to make an interface easier or more fun. If you get it, but want to do something a little different from the examples, you can be creative with your “eyes open.” You could also use the book to jumpstart your creative process by flipping through it for ideas.