ABOUT THE PATTERNS IN THIS BOOK

So there's nothing really new in here. If you've done any web or UI design, or even thought much about it, you should say, "Oh, right, I know what that is" to most of these patterns. But a few of them might be new to you, and some of the familiar ones may not be part of your usual design repertoire.

These patterns work for both desktop and web-based applications. Many patterns also apply to such digital devices as palmtops, cell phones, and TV-based devices like digital recorders. Ordinary web sites might also benefit, but I'll talk more about that topic in the next section.

Though this book won't exhaustively describe all the interface idioms mentioned earlier, they organize part of the book. Three chapters focus on the more common idioms: forms, information graphics, and WYSIWYG editors (like those used for text and graphics). Other chapters address subjects that are useful across many idioms, such as organization, navigation, actions, and visual style.

This book is intended to be read by people who have some knowledge of such interface design concepts and terminology such as dialog boxes, selection, combo boxes, navigation bars, and white space. It does not identify many widely accepted techniques, such as copy-and-paste, since you already know what they are. But, at the risk of belaboring the obvious, this book describes some common techniques to encourage their use in other contextsfor instance, many desktop applications could better use Global Navigationor to discuss them alongside alternative solutions.

This book does not present a complete process for constructing an interface design. When doing design, a sound process is critical. You need to have certain elements in a design process:

• Field research, to find out what the intended users are like and what they already do

• Goal and task analysis, to describe and clarify what users will do with what you're building

• Design models, such as personas (models of users), scenarios (models of common tasks and situations), and prototypes (models of the interface itself)

• Empirical testing of the design at various points during development, like usability testing and in situ observations of the design used by real users

• Enough time to iterate over several versions of the design, because you won't get it right the first time

The topic of design process transcends the scope of this book, and plenty of other books and workshops out there cover it well. Read them; they're good.

But there's a deeper reason why this book won't give you a recipe for designing an interface. Good design can't be reduced to a recipe. It's a creative process, and one that changes under you as you workin any given project, for instance, you won't understand some design issues until you've designed your way into a dead end. I've personally done that many times.

And design isn't linear. Most chapters in this book are arranged more or less by scale, and therefore by their approximate order in the design progression: large decisions about content and scope are made first, followed by navigation, page design, and, eventually, the details of interactions with forms and canvases and such. But you'll often find yourself moving back and forth through this progression. Maybe you'll know very early in a project how a certain screen should look, and that's a "fixed point"; you may have to work backward from there to figure out the right navigational structure. (No, it's not ideal, but things like this do happen in real life.)

That said, here are some ways you can use these patterns:

Learning

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. Just as expanding your vocabulary helps you express ideas in language, expanding your interface design "vocabulary" helps you create more expressive designs.

Examples

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.

Terminology

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 usage among software engineers.)

Inspiration

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."

One more word of caution: a catalog of patterns is not a checklist. You cannot measure the quality of a thing by counting the patterns in it. Each design project has a unique context, and even if you need to solve a common design problem (such as 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 judgment. Nor can it substitute for a good design process, which helps you find and recover from design mistakes.

Ultimately, you should be able to leave a reference like this behind. As you become an experienced designer, you will have internalized these ideas to the point at which you don't notice you use them anymore; the patterns become second nature. They're part of your toolbox from then on.