The Case for HCI Design Patterns

COMMON GROUND:

A Pattern Language for Human-Computer Interface Design

Jenifer Tidwell
Comments and reviews requested; send to: jtidwell@alum.mit.edu

Note: This page was last updated in 1999. Please visit the author's latest UI patterns work at http://designinginterfaces.com. Thanks!

Preface: The Case for HCI Design Patterns

Twenty years ago, Christopher Alexander shook the architectural world with his landmark book The Timeless Way of Building. His thesis was that one could achieve excellence in architecture by learning and using a carefully-defined set of design rules, or patterns; and though the quality of a well-designed building is sublime and hard to put into words, the patterns themselves that make up that building are remarkably simple and easy to understand by laymen.

The patterns that he and his colleagues defined -- published in a second volume, A Pattern Language -- are an attempt to codify generations of architectural wisdom. They are not abstract principles that require you to rediscover how to apply them successfully, nor are they overly specific to one particular situation or culture. Instead, they are somewhere in between: a pattern describes possible good solutions to a common design problem within a certain context, by describing the invariant qualities of all those solutions.

For example, he recommends using the "Entrance Transition" pattern with homes or any other building that "thrives on a sense of exclusion from the world." The pattern describes what one must do to a doorway so that someone entering it feels as though they are coming into a private, safe space:

"Make a transition space between the street and the front door. Bring the path which connects street and entrance through this transition space, and mark it with a change of light, a change of sound, a change of direction, a change of surface, a change of level, perhaps by gateways which make a change of enclosure, and above all with a change of view." (From A Pattern Language, pg. 552.)

Note that the pattern is not just proscriptive. It describes something positive, something you can try to build, even though you would naturally vary it according to the particular situation. It doesn't simply say, "Never build a doorway without a change of level." Note also that it carries values -- the value of a private space, the value of emotional comfort. Alexander's goal is not to make a building which is merely trendy, or efficient, or even good-looking; he is looking for ways to create a genuinely good experience for people, via their built environment.

In recent years, parts of the software engineering community have enthusiastically embraced the patterns concept, due in no small part to the 1995 book Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Like the Alexandrian patterns, these patterns of object-oriented software provide design solutions that are concrete enough to immediately put into practice, with good results, and yet are sufficiently abstract to apply to countless situations, limited only by the imagination and skill of the pattern user.

We badly need the benefits of such a pattern language in the field of HCI design.

The Need for a Human-Computer Interface Pattern Language

There is plenty of good literature out there on the high-level principles of good interface design, and it is getting ever better as this young field matures. We all know by now that we ought to use direct manipulation, immediate feedback, proper affordances, judicious use of sound and animation, protection from accidental mistakes, gentle error messages, and so on. But if you're a novice designer, it's hard even to remember all these principles, let alone use them effectively! And it's difficult sometimes to make the tradeoffs among these principles when they come into conflict; we often have to figure out the best solution by guessing, or by resorting to other means.

1. Test it with users

One excellent way to verify your guesses, of course, is to test your design with potential users. Lots has been written on usability testing and other field methods, and it's all important. Before the design phase begins, we must understand our users' concerns and learn to empathize with them; their feedback guides and inspires us while we explore different design possibilities; and late in a project, they help us refine and build the chosen design. In the field of human-computer interfaces, we have learned -- faster than in many other fields -- the value of an iterative design process that directly involves the end users.

But how do you come up with those initial designs? Once you understand where the user is coming from and what the artifact needs to do, what comes next? What further questions do you ask? What assumptions should you make? How do you put it all together into a design that might work? This creative leap is always harder than it sounds. And it costs us far less, in terms of time and usability testing, to make good guesses and design choices right at the beginning.

2. Follow the style guides

Then there are GUI style guides, both the toolkit-standard ones and custom company-wide style guides. They work fine if you want your company's applications to all look and behave just so, or if you want to make sure you're following the accepted conventions of the toolkit you happen to be working with. Sometimes it's important to know these details. But they are transient -- toolkits, trends, and operating systems come and go, and as soon as the world gets comfortable with one, another arises to take its place. Remember the transition from Windows 3.1 to Windows 95?

Furthermore, by constraining yourself to the relatively small number of tools that most toolkits give you, and to the ways of using them that convention dictates, you limit the expressiveness of your interface to that which is currently acceptable. ("I used a combo box there because that's what everyone does.") And no style guide can infallibly tell you how to strike a balance between two opposing high-level principles.

3. Do what other people do

I have seen inexperienced user interface designers work through design decisions by depending on other people's designs, rather than on their own design skill. They ask themselves questions like, "What techniques or layouts have I seen lately that do what I'm trying to do?" or even "What do the standard Microsoft packages do?" This approach isn't that bad, really -- observation of successful interfaces is part of the learning process, and at least they're not trying to reinvent everything from scratch. (The worst user interfaces reinvent everything in bizarre ways. So do the best ones; take a look atKai's Power Tools.)

But this can be a scattershot approach. The designer's experience may be limited to software of certain types, or made by certain companies, and they may not be closely related to the kind of software being designed. Furthermore, the other interfaces that the designer draws from may not be good ones in the first place. So the designer ends up with an impoverished decision-making ability, despite all good intentions.

(A familiar scenario occurs if the designer is really a software developer by vocation. His or her sphere of experience probably includes mostly developers' tools and the Web, neither of which may have anything to do with the user interface they are designing. We've all seen the results!)

Of course, experienced designers don't entirely escape this mode of thinking, either. Reinventing techniques isn't really practical most of the time -- consciously or subconsciously, they apply what they know, and reuse good solutions they've seen before. The difference lies partly in the depth of experience from which they draw: a seasoned designer has seen, analyzed, or built interfaces of many diverse kinds. And it also lies in the skill with which they apply that experience. They don't clumsily or timidly copy a technique, afraid they'll somehow ruin it by changing it; rather, they understand the design principles and process enough to confidently adapt a good idea to a new use in a new context. They understand what works and what doesn't -- the common ground -- across different media and contexts.

How can the HCI community help inexperienced designers move away from clumsy designs and labor-intensive processes towards this state of confidence and skill, without spending years learning it all the hard way?

To begin with, we could start building a human-computer interface pattern language. A language of this sort is a set of interrelated patterns, which share similar assumptions, terminologies, and contexts. At its best, such a language would both aid individual interface designers in their day-to-day work (as the Design Patterns book clearly does for many software engineers), and also help the whole industry develop better tools and paradigms.

More specifically, it would help individuals build better interfaces by:

Capturing the collective wisdom of other designers in a way that can be immediately used, even by less-experienced designers. When difficult design problems arise, and there are conflicts between basic design principles, a pattern solution may be found that is appropriate for that particular context.
Giving us a common language that we can speak with our fellow designers, with our interdisciplinary design teams, and with our customers. Participatory design may especially benefit when designers and users can talk about the same concepts, in the same terms, with fewer misunderstandings.
Allowing one to think "outside the toolkit," by creatively applying familiar patterns in new ways. One of the great paradoxes of design is that one's creativity is often improved by imposing constraints on what one may create. By constraining a designer to work within the pattern, but with flexibility in visual appearance and interaction details, new specific solutions may emerge that are better than those commonly found in today's software.
Helping to keep one focused on essential values, such as simplicity, fidelity to a consistent model, aesthetic beauty, and emotional comfort.
Expressing design invariants that can be encoded in software, while allowing the specific solution details to vary as necessary (through design/test/evaluate iterations, for example, or over time as software slowly evolves through different versions). It's too much to expect that all patterns will work this way, since the point is good design, not good programming; but sometimes it works out.

Likewise, a good pattern language can benefit the HCI design community:

It would be a new, more meaningful vocabulary for talking about why certain interfaces do or don't work. We talk now about the wonders of wizards, popup menus, and combo boxes, when they almost certainly won't be around in twenty years -- but the patterns behind them, that make them work, will still be valid (and were already valid a century ago, in some cases).
It would enable us to more methodically draw on expertise in related fields, such as book design, consumer electronics, the design of control panels (for cars, airplanes, power plants), video games, the Web and hypertext, and speech-driven interfaces. If a pattern holds true in both UI design and another field, we can learn the specifics of implementation in that other field and imagine how we could apply them to our interfaces. Of course, many of us have already done that, though without the use of the term "patterns" -- but imagine how much more effective we could be if we think about it at the right level of abstraction!
By isolating the qualities that make certain trendy metaphors, idioms, and widgets work so well, we can learn from them and then move beyond them, without losing their lessons from our collective memory. How many excellent interface ideas have been lost because they became unfashionable, or because they never gained wide acceptance due to economic forces or bad implementations?
They may serve as a solid practical foundation on which to build new user interface tools or concepts, such as virtual reality, sound-based interfaces, or next-generation Web sites. If we know what patterns work in other diverse fields, then we can better direct our efforts towards creating good artifacts in the new ones. It would be a shame to start developing a new design idea, say a new 3D interface, and waste vast amounts of effort rediscovering the same good old design patterns that have always worked in the familiar 2D spaces.

A Sample Pattern Language

The pattern language presented here is merely a start. It does not yet fulfill all the above goals, though the patterns were developed with them in mind. The ones defined here need refinement, and more patterns should be added over time, since this is far from a complete set.

Each pattern description defines a context of use, a problem the designer needs to solve, a set of "forces" pushing the designer in different directions, and a primary rule -- and sometimes additional secondary rules -- on how those forces might be resolved to best solve the problem. Examples are also provided, both good and bad; sometimes the bad examples show inappropriate uses of the pattern, and other times they show a situation in which the pattern should have been used but wasn't.

Note that the pattern names and problem descriptions avoid the use of GUI-centric terms whenever possible (e.g. mice, menus, dialogs), so that you may more easily think about them being used outside the GUI world. Most of them do work that way. That was a condition of acceptance into this language: if a pattern is invariant across such different forms as paper, hardware, video games, and desktop GUIs, there must be truth in it. In fact, some patterns, such as User's Annotations, are not even in common usage yet in desktop GUIs.

Please read these patterns actively! Think about other examples that you might have seen, both from the world of desktop GUIs and from other fields. Consider how you would use them to design a new interface, or redesign an existing one (VCRs almost always provide entertaining cases of poor design). Look at an interface you like, and see if what you like about it can be captured by some of these patterns -- keep in mind that a pattern language can serve not only as rules for building a design, but also as a system for deconstructing an artifact and classifying its pieces. Finally, imagine how you might apply the pattern in a fully three-dimensional interface, or in a "Star Trek" interface, or some other new or fantastic technology. Would it work there? Why or why not?

Christopher Alexander posits that good patterns improve with time and widespread use. The object-oriented software development community has discovered that this is true, since there are now lots of people in that field developing their own pattern languages and reviewing them with others. The patterns in the original Design Patterns book have been augmented and refined, as is done in John Vlissides' Pattern Hatching. There is vigorous discussion going on at conferences, in magazine columns, over mailing lists, and in local special-interest groups worldwide.

The HCI design world could start engaging in similar discussions. If you have thought about patterns as they relate to user interface design or development, write about it. If you have additions to or criticisms of the patterns defined here, speak up, so that these can be improved. Read the literature on patterns and develop your own language, in contrast to this one.

Above all, use these patterns if you find them at all helpful. A pattern language is ultimately worth only what its users can get out of it. There is always room for improvement in the design process for conventional GUIs, and recent developments in HTML and Java are giving us the means to build much more creative Web and desktop interfaces than we had in the past, both technically and in terms of user acceptance of "unusual" interfaces.

If the success of patterns in architecture and software engineering is any indication, both our industry and our customers will benefit greatly from this effort.

Comments to: jtidwell@alum.mit.edu
Last modified May 17, 1999