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

Common Ground

Introduction

The patterns contained in this work address the general problem of how to design a complex interactive software artifact. They are intended to be used by people who design traditional user interfaces, Web sites, on-line documentation, video games, and other such things. Others who may be interested include people who implement such artifacts, or test them for usability, or manage teams who design and implement them. The language does not attempt to address implementation issues, however.

These patterns are intended to form an Alexandrian pattern language, as found in Christopher Alexander's book A Pattern Language, and not a catalog such as is found in the book Design Patterns. This means in part that they are intended to be used together synergistically, in a way such that the whole is more than the sum of its parts. Like other such pattern languages, it does not break new theoretical ground or present innovative new techniques -- it's more than likely that you have seen examples of every pattern in here. Instead, it captures ordinary design wisdom in a practical and learnable way.

The intended goal of this pattern language is deliberately broad: to support high-quality interaction between a person and a software artifact. The artifact may support one or more of a broad spectrum of activities, ranging from the most passive -- absorbing information with little or no interactivity -- to the hands-on creation of other objects. Consider some of the varieties of software out there today:

Traditional desktop GUI software
Web sites
Palmtops and handhelds
Controllers for industrial processes
Video games
On-line documentation
Multimedia educational software
Speech-based interfaces
Design tools for graphics and visual arts
Scientific visualization
Collaborative, multi-person work spaces

These are incredibly diverse in their specific goals, their degrees of interactivity, their balance between the verbal and the non-verbal, and other factors. But from a designer's perspective, there's more commonalities among them than you may think. For one thing, many of them bear strong similarities to older, more traditional media. Software is very young, and we're still learning how to take full advantage of its unique characteristics; in the meantime, both users and designers carry over what we already understand about print media (books, paper forms, charts), mechanical things (appliances, cars), physical spaces (architecture, urban design), and other real-world artifacts. Therefore, many patterns in this language draw as much from these other realms as from software.

Another similarity among all these kinds of software (and other media) is their basic purpose. The best ones all provide their users with a successful and satisfying experience, by doing one or both of these things well:

They shape the user's understanding of something, through a stylized presentation that unfolds the content to the user in an appropriate way. A successful artifact will enable its users to completely understand and effectively use the content being presented.
They enable a user to accomplish a task, by progressively unfolding the action possibilities to the user at an appropriate pace as the user interacts with it. A successful artifact will "flow" so well that it lets its users focus entirely upon the task at hand, causing the artifact itself to fade from the user's awareness.

These twin goals, along with corollary issues such as learnability, user empowerment, and enjoyability, define "high-quality interaction" for the purposes of this pattern language. Some artifacts concentrate more upon one aspect than the other, depending upon their context of use. The two aspects are almost orthogonal, but not quite: something which chiefly provides a set of actions still has to present those actions in a comprehensible way, and something which chiefly presents a set of facts or ideas may have to provide the user with actions they need to interact with the artifact.

In both cases, there is an "unfolding" process going on between the artifact and the user. In something which presents facts or ideas (such as a map), that unfolding may be top-down, in which the "big picture" is shown first and the users work their way down into the details as they need. Or, it might be in the form of a fictional narrative, in which the author uses language and character to let the central themes slowly unfold. The basic shape of the content might take the form of one of these "primary patterns:"

Narrative. Examples include works of fiction, nonfiction books, and news articles written in the "pyramid" form. These are usually linear, and usually verbal, but the unfolding process may work in different ways, as described above.
High-density Information Display. Maps, tables, and charts fall under this category. Users may approach one of these with the intent of getting a big picture, or of finding specific details; the patterns chosen to build it should support both.
Status Display. A wall clock, a car's dashboard, and a VCR display are all forms of a status display; they are used to monitor the state of something that will change, and like High-density Information Display, the user must be able to find specific information quickly as well as get a big picture.

In an artifact which presents actions, such as a GUI "wizard," the user may first be presented with a small range of available actions, one of which is taken; then a new set of possible actions is shown, and the user takes one of those; and so on. Alternatively, the range of actions At any one time might be very wide, as with some direct-manipulation interfaces. Ultimately, the artifact lets the user accomplish some principal task, which may require smaller supporting tasks to be accomplished first, which may in turn require still smaller supporting tasks. The sense of "flow" comes from being able to do these with an appropriately small amount of time and effort, so that the user never loses focus on their principal task (as Brenda Laurel discusses in Computers as Theatre).

The primary patterns for actions -- their basic shapes -- might include these familiar genres:

Form. Tax returns and catalog orders are typical examples, and interactive forms are very common in computer interfaces. The user is expected to provide preformatted information, often in a linear fashion. The available actions are fairly narrow, prescribed by cultural expectations.
Control Panel. A lightswitch is a very simple example, offering an extremely limited choice of actions; a TV remote control is more complex; a nuclear power plant's control room may reach the limit of a human being's ability to comprehend complexity. Control Panels are used to set the state of one or more things. Cultural constraints often help define the available actions, but as illustrated by the examples, there is a wide range of action availability, so the unfolding process can take place in many ways.
WYSIWYG Editor. A typewriter or word processor, a drawing program, and a forms designer such as Visual Basic are all typical examples. These offer many possible actions to the user at once, including various kinds of direct manipulation, and the results of those actions are usually immediate -- they thus support quick, iterative, creative work that often leads to the aforementioned sense of "flow.'
Composed Command. Command-line-driven software of all kinds, such as the UNIX operating system or software debuggers, fall into this category; so does one person telling another person what to do, or a person verbally addressing a computer (as in Star Trek). The available actions may be extremely broad, especially if natural language is fully used. This pattern is linguistic where WYSIWYG Editor is graphic: both are highly interactive and user-driven, both offer broad ranges of actions with complex unfolding techniques, and both usually provide immediate feedback. These all work to support complex tasks.
Social Space. This includes the on-line equivalents of "real" social spaces -- newsgroups, email lists, chat rooms, and so on. This pattern is unusual in that the artifact is merely a mediator between people, not a direct participant in a dialogue with the user, nor a passive provider of content. Nevertheless, it still reveals content (the conversations taking place) and provides actions (what the user can do in that space), but in a very stylized manner.

These primary patterns form the backbone of this pattern language. They set the tone for an artifact -- when a user identifies an unfamiliar artifact as belonging to one of these (or others not explicitly defined in this language, such as a spreadsheet), he or she tends to make some initial assumptions about its behavior, based on cultural expectations of how these things usually work. ("What does it do? How am I expected to interact with it? What do I do first? How will it react?") At the end of this introduction, there is a description of each primary pattern's "sublanguage," or a set of interrelated patterns that often work well to support that pattern.

Note that the patterns aren't meant to be straitjackets -- for instance, they can be used in combination with each other, such as putting bits of Narrative into the cells of a Tabular Set, or using a Form as an adjunct to a WYSIWYG Editor -- but the boundaries are basically respected by mainstream artifacts, and for good reason. Usability is improved when users' expectations, subconscious or explicit, are followed. On the other hand, experiments, cutting-edge interfaces, and art often make it a point to violate those boundaries. How you deal with the existing boundaries all depends upon your purpose.

The next set of patterns captures ways of unfolding an artifact's content or available actions. Some apply to content, some apply to actions, some to both; there's no reason to be dogmatic about their use.

Navigable Spaces is highly interactive, letting users move through the artifact at their own pace, and in their own directions.
Overview Beside Detail also lets users work at their own pace, but presents a more structured, two-level view of information or actions.
Step-by-Step Instructions prescribes a sharply limited set of actions to the users, usually in a linear fashion, moving progressively through stages.
Small Groups of Related Things loosely organizes visual content into distinct groups, usually done hierarchically, so that a user can see both the "big picture" and fine detail.
Series of Small Multiples organizes visual content into a single (possibly long) series of discrete images, bringing out differences between them by emphasizing their basic continuity; it can be used to implement a High-Density Information Display.
Hierarchical Set is a way of implementing a High-Density Information Display with a strict tree-like organization.
Tabular Set also implements High-Density Information Display, but as a table; again, users can see both the big picture and fine detail.
Chart or Graph is yet a third implementation of High-Density Information Display, but a more graphic one than the other two.
Optional Detail On Demand lets users reveal hidden actions or content at their own discretion.
Disabled Irrelevant Things blocks certain actions or content according to the current state of the artifact, usually driven by user interaction.
Pointer Shows Affordance temporarily reveals possible actions according to the user's explicit focus of attention.
Short Description temporarily reveals content according to the user's explicit focus of attention.

Other categories of patterns describe an artifact's use of space and other resources, navigational techniques, different kinds of actions, the interrelationships between an artifact's "working surfaces," and so on.

There's one thing you should keep in mind about this language, however, that is atypical of other Alexandrian pattern languages. Most of these patterns can be used at many different levels of scale. A Form, for example, may be the dominant pattern in one artifact, while being a minor helper task in another. Likewise for a High-density Information Display such as a chart or a table. Small Groups of Related Things is recursive by definition, much like Composite in Design Patterns, and the concept of a working surface is also recursive -- any single surface can be composed of a set of Tiled Working Surfaces, for instance.

Because of this scale issue, I haven't yet been able to draw a coherent diagram of the whole language, nor define clear linear paths through it. I am open to suggestions on how best to do this. For instance, the sublanguages are not much more than suggestions, based on which patterns seem to go well with each other; it shouldn't be interpreted as exclusive or proscriptive.

How to Use This Pattern Language

At one level, this language is a way to describe existing artifacts. Using it as such should be fairly simple: read through the language, and pick out the patterns that you see. The problem statements and forces in the pattern descriptions may help you understand how the artifact does what it does, and what tradeoffs its designer may have been considering.

At a much deeper level, you can use this language as a tool to help you design an artifact. Please understand that it is no substitute for creativity or a good process. It is not a silver bullet. To use any pattern language effectively, you must start with an understanding of the artifact's purpose and audience, as is the case in any design methodology. (How can you pick a design solution if you don't know what the relevant factors are?) And to get the most benefit out of it, I believe you must allow the design to progress iteratively. Allow it to grow organically, by weeding out the bad ideas as you go and letting the good ones flourish. Start with the broad strokes and work down into the fine details; with each iteration, check your designs against reality, so that you can discover the bad choices and get rid of them.

(This reality may take the form of the viewpoints of different stakeholders, such as users, technical writers, testers, customer educators, and marketers. If they "speak" the same pattern language you do, so much the better -- let them in on the fun. They might have some excellent design ideas. In my experience, they almost always do.)

It is common in software to start with a "conceptual model," or a model of objects, relationships, behaviors, and states that describes the artifact independently of the user interface. Upon first reading, these patterns may seem to describe just the surface of an artifact -- the way it looks and the way it behaves. But the patterns may also be used to help design the conceptual model behind the interface. For example, content presented as Navigable Spaces might be implemented with one "object" per space, with object relationships corresponding to the links between the spaces. A Hierarchical Set should be the visible manifestation of a tree structure. A Form may present a series of editors for each property of an object, maybe with subforms for subobjects.

Some designers start from the user's perspective. They first design the interface, based on the user's needs and goals, and then design the underlying model to match it. This works well if you have the luxury of being able to affect the design the whole artifact. Conversely, you could start with the conceptual model -- perhaps it is an unchangeable requirement -- and then choose interaction patterns that have high fidelity to that model, assuming the model is a good one to start with.

The point is, users are going to build their own mental models about the artifact from what they can see. If there is consistency between the underlying model and the interface, and the interface is designed well enough to convey that model effectively to the intended audience, then the users will build mental models which correspond pretty well to the artifact's underlying model. Then the artifact has integrity. The user can more easily predict the artifact's behavior. Errors, if they happen at all, become comprehensible. The interface is easier for the designer to maintain over time, as the model changes.

In any case, I am not going to present a failsafe method for using this pattern language. In the first place, it has not been used enough to generalize from successful examples. Secondly, and perhaps more importantly, I'm not convinced that it will fundamentally change the processes that designers already use to design artifacts. A pattern language should make the processes smoother, more effective, faster, and hopefully with better end results; but there is already a wealth of knowledge out there on how to do design. As pointed out above, user contact and iteration are the keystones of good design.

Just as a proof of concept, here is an example of how the pattern language may be used to build a user interface design.

Example: Order Entry

This is a semi-fictional account of a UI design session using these patterns. The artifact we designed is real -- it is an order-entry application for a phone company, intended as a demo and working example of the use of my company's software. The design session did follow this general framework, although the patterns were never explicitly mentioned.

(Technically, it was a redesign session. A previous version of this software had been designed as basically a set of Tiled Working Surfaces, and it hadn't worked very well. The main dialog was too small to allow the contained subforms to grow, for one thing, and it was all getting too complex. The models we had used turned out not to match the way our customers generally thought about the order-entry process, either. Furthermore, the underlying software structures were changing drastically. These factors made it worthwhile to redesign the whole thing from scratch, rather than incrementally modify the existing design.)

Primary Pattern: The users will be typing in preformatted information, and occasionally browsing for information that's already been typed in. The primary pattern we picked was Form; no other option seemed to make sense.

Posture: As mentioned above, the application was intended for use as a demo -- it would be seen by potential customers who have short attention spans, and our salespeople would not have long to demo it, and could spend little or no time on setup or long explanations. Therefore, we chose Helper Posture. (A real order entry system would require Sovereign Posture, to support the people who use the software eight hours a day, five days a week.)

Working-surface Organization: Here we thought carefully about what kinds of information would need to be provided, and how they broke down into obvious groupings -- customer information, order information, services and their various features. We considered how those information groups related to each other, in terms of part-whole relationships. (It turned out to be more or less a hierarchy.) We also thought carefully about use cases -- what happens when a customer calls? What information do they give, and when? What does the order entry person need to tell them? How does the order entry person need to navigate through the application, to keep up with a customer? Our discussions at this point were heavily informed by the feedback we had gotten from the previous design of the interface.

We decided on a Central Working Surface where most of the order entry actually gets done (a Java JFrame), with an auxiliary dialog for looking up specific customers and orders. The order entry frame itself was composed of a Stack of Working Surfaces, representing the various forms needed to take customer information, order information, etc.

Since these forms related to each other in a hierarchical fashion, we eschewed tabs (a linear presentation) in favor of a Hierarchical Set along the left side of the Stack of Working Surfaces.

Information Organization: We wanted to allow a summary of a given customer's entire order to be visible, both for practical reasons and for a more effective demo. But sometimes more than a summary is necessary; for instance, a customer may call and ask about the status of one particular feature of one service of one order, which is getting into very fine detail. Thus, we chose to use Optional Detail On Demand, in the form of a Hierarchical Set (which we'd already chosen) in which the nodes could be open or closed by the user.

Actions: We thought about which actions an order entry person would take, such as creating new orders, adding new services to an order, and switching to another customer. We divided these up into sets of Convenient Environment Actions and Localized Object Actions. Because we had chosen Helper Posture, we decided to create verbiose text buttons for each these actions, and then we decided where to put them (on the outer frame for the Environmental Actions, on the individual forms for Object Actions).

Again, because it was a Helper Posture application, we didn't bother using patterns such as User Preferences (no user would use it for very long) or Actions for Multiple Objects (potentially confusing and expensive to implement).

Kinds of Information to be Supplied: Each panel for the different kinds of information (customer, order, service, feature) is its own Form. For each of these Forms, we had to figure out what logical groups of information existed and in which order the Form would present the information. We sometimes used Small Groups of Related Things to visually organize it according to the natural groupings, such as a labeled box around the fields for an address.

At this point, we didn't have enough information about the details of the various model objects (customers, orders, services, features) to go into the next design iteration. But some of the patterns available to us here would be Forgiving Text Entry, Structured Text Entry, Choice from a Small Set, and Choice from a Large Set; modifying these still further would be Disabled Irrelevant Things and Good Defaults.

So, with the design discussion temporarily at an end, we put what we had on paper (in pencil, for easy modification). Some informal usability tests were performed with this paper prototype, to try out the initial design; then an on-line prototype was built, for higher fidelity. The feedback we got from these usability tests indicated that the interface basically performs well. Once people actually tried to play with it, we found that some of the navigation between forms needed to be changed (it was then tested again), but we were happy enough with the final results to begin implementing the interface.

Example: Telephone Interface

(unfinished)

Control Panel - The whole front of the phone.
Small Groups Of Related Things - The various groups of buttons: numbers, function buttons, etc.
Helper Posture - Only in your face while doing dialing, not too imposing on my desk.
Background Posture - The blinking 'Hold' indicator. (also Status Display)
Important Message - The ringer.
Remembered State - Redial button, stored numbers (bound to 'Quick Dial' buttons).
Go Back to a Safe Place - The 'Release' button, or the hook.
Composed Command - The dialing process (sometimes could be better supported by speech recognition)
Quick Access - 911, 411, *SP, etc.
User Preferences - The 'Quick Dial' buttons and the numbers they are bound to.

Social Space - Conversations and multi-way conversations are supported by the medium the telephone connects to.
Narrative - Voice mail can be seen as a Narrative triggered by the user.
Optional Detail On Demand - Slide-out panel that shows more functionality, in more sophisicated phones.
Iconic Reference - Pictures indicating quick-dial buttons, like fire, police, pizza, etc.
Editable Collection - Voice mail 'unheard' and 'saved' messages.
Step-by-Step Instructions - Automated account information available from the phone company, credit card company, etc.

Sublanguages

Each primary pattern tends to use certain other patterns more than others; they are loosely grouped together here as sublanguages. Some other highly recognizable patterns also have sublanguages that should be familiar to users of these artifacts, particularly Navigable Spaces and Step-by-Step Instructions.

Narrative:
Clear Entry Points, Go Back One Step, Go Back to a Safe Place, Bookmarks, Optional Detail On Demand, User's Annotations, Convenient Environment Actions

High-density Information Display:
Series of Small Multiples, Hierarchical Set, Tabular Set, Chart or Graph, Navigable Spaces, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Short Description, User's Annotations

Status Display:
Hierarchical Set, Tabular Set, Chart or Graph, Choice from a Small Set, Sliding Scale, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Important Message, Short Description, Personal Object Space, User Preferences

Control Panel:
Choice from a Small Set, Choice from a Large Set, Sliding Scale, Convenient Environment Actions, Localized Object Actions, Pointer Shows Affordance, Small Groups of Related Things, Optional Detail On Demand, Disabled Irrelevant Things, Good Defaults, Remembered State, Reality Check, Important Message, Short Description, Interaction History, Personal Object Space, User's Annotations

Form:
Choice from a Small Set, Choice from a Large Set, Editable Collection, Sliding Scale, Forgiving Text Entry, Structured Text Entry, Good Defaults, Remembered State, Step-by-Step Instructions, Small Groups of Related Things, Disabled Irrelevant Things, Pointer Shows Affordance, Optional Detail On Demand

WYSIWYG Editor:
Toolbox, Set of Object Actions, Actions for Multiple Objects, Convenient Environment Actions, Optional Detail On Demand, Disabled Irrelevant Things, Pointer Shows Affordance, Short Description, Personal Object Space, User Preferences, Scripted Action Sequence, Remembered State, Reality Check, Demonstration, User's Annotations

Composed Command:
Convenient Environment Actions, Localized Object Actions, Actions for Multiple Objects, Scripted Action Sequence, Forgiving Text Entry, Reality Check, Progress Indicator, Interaction History

Social Space:
Interaction History, Convenient Environment Actions, User Preferences

Navigable Spaces:
Map of Navigable Spaces, Clear Entry Points, Go Back One Step, Go Back to a Safe Place, Interaction History, Bookmarks, Pointer Shows Affordance, Short Description, Disabled Irrelevant Things, Progress Indicator, User's Annotations

Step-by-Step Instructions:
Go Back One Step, Go Back to a Safe Place, Progress Indicator, Map of Navigable Spaces, Interaction History, Optional Detail On Demand, Disabled Irrelevant Things, Convenient Environment Actions, Good Defaults

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

Narrative

Examples:

User's guide to a software package
News article
Movie or TV show
Voice-mail message
Weather forecast
Traffic report

Context: There is a need to convey information to the user; the information is closely interrelated, but of diverse kinds, and there may be some subjectivity involved.

Problem: In what form should the information be displayed to the user?

Forces:

Many kinds of information are easier to absorb and remember when they are conveyed via natural language than when they are presented as raw data.
The artifact's or author's point of view should sometimes be explicitly acknowledged, such as when credibility is an issue; narrative does this well, whereas other forms of data presentation are more anonymous.
Many people find narrative to be more pleasant than raw data or symbolic representations.
Natural language can convey subjectivity -- values, interpretations, and opinions -- in a way that no other information presentation can.
Natural language is difficult for computers to generate and parse, but easy for humans.
Natural language presented as "straight text" has to be read or skimmed linearly to find specific information.

Solution: Convey the information via natural language. Use all you learned in high-school English class about good writing. If users might be skimming the text to find specific data items, use color, fonts, and white space to set off items of interest; for readability in some situations, try using "senselining."

Notes: [ Unfinished. I think this is a very important pattern to understand, but I don't understand it yet. Natural language has wonderful, subtle gradations of meaning and emphasis that raw data can't have. How do we decide it's best to, say, give a weather report in a narrative form, rather than as a table? I suspect that some factors are: memorability, subjectivity and biased interpretation (which is not always a bad thing), effort required to absorb and understand the information. ...Maybe we should turn the question around, and ask when we should NOT use narrative, since narrative is the default way that we humans communicate. ]

Random other notes...

Storytelling is a huge part of this pattern, but it's really outside the scope of this pattern language

Narrative is declarative, where Step-by-Step Instructions is imperative; both use natural language

Brenda Laurel's quote on the use of narrative in an interactive artifact: "Narrative includes both the story being told (content) and the conditions of its telling (structure and context). ... Within that [narrative] framework, interface designers can adopt strategies from narrative theory, such as including multiple representations of events and information, or using characters as a means of representing material with an explicitly acknowledged point of view." (pg. 182 in my copy)

Give two examples: an image from The Weather Channel's daily weather report (tabular data and icons), and a cut-and-paste from the Mass. weather site (narrative).

Howard Wainer talks about senselining. Strunk & White talks about good writing. Nielsen talks about writing for Web pages. Who talks about colors and fonts and whitespace?...

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

High-density Information Display

Examples:

Email software that shows long lists of stored messages, e.g. Netscape or MS Exchange
Good maps, such as the USGS topographic maps and NOAA charts
Large, detailed object diagrams for object-oriented software

Context: There is a need to convey lots of information, either of a homogeneous type or interrelated in some way, but all of roughly equivalent importance.

Problem: In what form should the information be displayed to the user?

Forces:

The user wants to quickly find specific information.
The user also wants to quickly get a "big picture" of what the information is about.
The user shouldn't have to do any more thinking, or manipulation of the artifact, than is absolutely necessary.
The user may be frustrated, or led to a poor decision, by not being able to see all the available information.

Solution: Pack as much information into one working surface as possible, following the precepts of good graphic design, with an organization that accurately reflects the underlying structure of the information. Make the information dense enough so that the eyes do not have to move far from one thing to another, and so that scrolling is unnecessary whenever possible. Sparingly use bright color and/or imagery to highlight specific objects or state information relevant to the task at hand, so that the user doesn't have to read text or scan linearly to find important things. Use negative ("white") space or subtle color, rather than boxes or lines, to organize the information. Don't be shy about using large areas, or small fonts, or tiny controls and peripheral things if the information display is the most important task of the artifact.

Resulting Context: This is a rather high-level pattern; you are still left with a decision on exactly how you present the information. The answer partly depends upon the information's structure. If it's a hierarchy, for instance, you could use a Hierarchical Set. If the information is geographically structured, a map might be appropriate. Data sets of high dimensionality demand more sophisticated display techniques, often leading designers to combine the three spatial dimensions, color, and time; for very complex data sets, you may want to create Navigable Spaces that let the user wander through the complete information space.

The rest of the answer depends on what the user is trying to do -- whether they need qualitative or quantitative information (or both), for instance, or whether it's more important to find one datum, or to see that datum in context with the rest of the data, or to get a big picture. If quantitative information is needed, and the items to be presented have a similar substructure, then a Tabular Set may work well (and it can be creatively combined with other kinds of views, such as an outline). Or use Chart or Graph to give a visual representation to a "flat" data set, especially when a strong qualitative sense of the data is needed.

Notes: When a great deal of information is well-organized and presented in a visually reasonable fashion, the human mind is amazingly good at viewing it all, finding specific pieces of information in it, and getting the big picture out of it. Try to take advantage of human cognitive skills to enhance the data display.

It's easy to confuse "too much clutter" with "too much information" -- it's likely that most cases of the latter are actually misunderstood cases of the former. If a user complains to you that "There's too much stuff to see at once," see if the problem isn't really that it's just badly presented: too many boxes (imagine a 50x10 grid of white edit boxes on a gray background!), too many or too few colors, a hard-to-read font, poor use of negative space or widgetry, etc.

For good discussions of these issues, see Edward Tufte's books, particularly The Visual Display of Quantitative Information and Envisioning Information. Ben Shneiderman's latest edition of Designing the User Interface has an excellent chapter on information visualization, with plentiful examples from the software world.

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

Status Display

Examples:

Status bar on Windows applications
Train, bus, or airline schedule
Airplane cockpit
VCR display
Computer's performance monitor

Context: The artifact must display state information that is likely to change over time, especially if that state information represents many variables.

Problem: How can the artifact best show the state information to the user?

Forces:

The user wants one place where they know they can find this state information.
The information on it should be organized well enough so that the user can find what they need at a glance, and interpret it appropriately.
It needs to be inobtrusive if the information's not critically important, but...
It does need to be obtrusive if something important happens.

Solution: Choose well-designed displays for the information to be shown. Put them together in a way that emphasizes the important things, deemphasizes the trivial, doesn't hide or obscure anything, and prevents confusing one piece of information with another. Never rearrange it, unless the user does it themselves. Call attention to important information with bright color, blinking or motion, sound, or all three -- but use a technique appropriate to the actual importance of the situation to the user (such as Important Message).

Resulting Context: If there is a large set of homogeneous information, use High-density Information Display and the patterns that support it (Hierarchical Set, Tabular Set, Chart or Graph); if you have a value which is binary or is one of a small set of possible values, use Choice from a Small Set. Visually group together discrete items which form a logical group (Small Groups of Related Things), and do this at several levels if you have to. For example, date and time are usually found in the same place.

Tiled Working Surfaces often works well with a Status Display, since it hides nothing -- the user does not need to do any window manipulation to see what they need to see. (You might even let the users rearrange the Status Display to suit their needs, using Personal Object Space.) If you don't have the space to describe what each of the displayed variables are (e.g. Background Posture), or if your users are generally experts who don't need to be told (e.g. Sovereign Posture), then use Short Description to tell the users what they are.

Notes: Use the positioning of an item within the Status Display to good effect; remember that people born into a European or American culture tend to read left-to-right, top-to-bottom, and that something in the upper left corner will be looked at most often.

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

Form

Examples:

Tax forms
Job application forms
Ordering merchandise through a catalog
Ordering a pizza over the phone

Context: The user has to provide preformatted information, usually short (non-narrative) answers to questions.

Problem: How should the artifact indicate what kind of information should be supplied, and the extent of it?

Forces:

The user needs to know what kind of information to provide.
It should be clear what the user is supposed to read, and what to fill in.
The user needs to know what is required, and what is optional.
Users almost never read directions.
Users generally do not enjoy supplying information this way, and are satisfied by efficiency, clarity, and a lack of mistakes.

Solution: Provide appropriate "blanks" to be filled in, which clearly and correctly indicate what information should be provided. Visually indicate those editable blanks consistently, such as with subtle changes in background color, so that a user can see at a glance what needs to be filled in. Label them with clear, short labels that use terminology familiar to the user; place the labels as close to the blanks as is reasonable. Arrange them all in an order that makes sense semantically, rather than simply grouping things by visual appearance.

Visually, arrange the blanks and labels according to a spatial grid; align the edges of the stronger graphic elements, like boxes, where you can. Give them a neat look and a good visual rhythm, but don't let a strong geometry overwhelm the meaning of what is written or provided -- big arrays of edit fields (or whatever) look scary! If there are a lot of them, at least separate them into subgroups (Small Groups of Related Things); again, do this according to the meaning of the information, not just what looks good.

Provide reasonable default values wherever possible, to lessen the amount of work that the user has to do (Good Defaults). If the user provides information that makes some parts of the form irrelevant, disable them (Disabled Irrelevant Things). Likewise, if the user provides some clue which enables a software-based form to predict what information will be filled in elsewhere, then have the software do it for them. For example, if a user is providing their address and phone number, the town they provide might only have one area code in it -- so fill in their area code for them. But don't do it wrong; that's worse than not doing it at all, because the user then has to both notice the error and correct the form.

Be forgiving about the format of what the user provides, as much as is possible (Forgiving Text Entry). But if the required information simply must follow a certain format, then an empty, featureless text field is the worst possible thing to have to fill in. You never know if you're doing it right. Always offer a clue about what is expected by constraining the user's input in a reasonable way (see Structured Text Entry for one example), and don't resort to validating afterwards, giving the user a nasty message about how wrong their input was. Giving an example right there on the form is a better idea, but still not as good as a visual constraint.

(Sometimes, cultural factors make visual constraints unnecessary. A login screen, for instance, usually just has fields for "User name" and "Password" -- the possible input strings are constrained, of course, but 99.9% of its users will understand exactly what is expected, and constraints or extra information will be more trouble than it's worth. See Don Norman's The Design of Everyday Things for lengthy discussions of physical and cultural constraints.)

Resulting Context: You must pick controls for each of the pieces of information to be supplied. These may include:

Choice from a Small Set, if the user should pick one or more from a set of 10 or fewer choices (give or take).
Choice from a Large Set, if there are more than 10 choices.
Editable Collection, if the user should construct a list of items.
Sliding Scale, if the possible values vary linearly between an upper and lower bound.
Forgiving Text Entry, if the recipient of the information is capable of parsing whatever text the user provides, which could vary widely.
Structured Text Entry, if the recipient needs the information in a very specific format and cannot parse a potentially wide variety of responses.

Notes: No one ever fills in forms for fun. They do it because they want something (as with a catalog order), or because they are compelled to do it (taxes), or because it's their job (data entry). It's pointless to be cute or clever, and if you make the user have to read extra instructions, or go back to redo something they misunderstood the first time around, or jump around the form to fill in things "out of order," they will be irritated.

If you can find a non-contrived way to use something other than a form, do so. For instance, why ask someone to laboriously fill in a day, month, and year when you can just have them pick a day from a calendar? [Use three pictorial examples here: a date as a Forgiving Text Entry, a date as a Structured Text Entry, and a date as a calendar widget.]

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

Control Panel

Examples:

Stove and oven controls
Airplane cockpit
Power plant control room
Physical or electronic CD player

Bad Examples:

Most remote controls for TVs, stereos, and VCRs
Cellular phones

Context: The artifact must provide a way for the user to either change its state, or command it to do something.

Problem: How can the artifact best present the actions that the user may take?

Forces:

The user wants one place where they know they can find the necessary controls, without having to hunt for them.
The controls on it should be organized well enough so that the user can find what's needed, with minimal effort and with no confusion.
There might be a lot of controls involved, some of which may be complex.

Solution: For each function or state variable that is part of the user's mental model, choose one well-designed control that performs the function or displays the variable's value; put them all together such that the most commonly-used controls are the most prominent. Similar functions may have similar-looking controls, but make sure that they aren't so similar that the user gets confused about which is which, even if their labels are different. (Hence the remote controls and cellular phones that are bad examples. They usually have rows of buttons that all feel alike to one's fingers -- and these are the kinds of things that people like to use without being able to look at them!)

When someone uses the controls, give immediate feedback that something is happening; this could be visual feedback, verbal, aural, tactile, etc. The best controls are often those that also display the current state (thus combining Control Panel with Status Display), since it makes sense to people to affect something in the same place they see it.

If the thing(s) being controlled has an obvious and familiar spatial layout, use it in the control panel. In The Design of Everyday Things, Don Norman makes an example out of stoves -- their burners are arranged in a 2x2 grid, but the controls for them are usually not, and users have to stop and think about which goes with which. If analogous spatial arrangement doesn't make sense in a given situation, then try instead to group the controls semantically. Ideally, the controls relevant to a given high-level task will end up clustered together (Small Groups of Related Things), so the user doesn't have to hunt all over the control panel for the next needed control.

Resulting Context: Appropriate controls now have to be chosen. Some patterns you can use are Choice from a Small Set, Choice from a Large Set, Sliding Scale, or even an interactive Chart or Graph. Make it clear which controls represent artifact-wide actions (see Convenient Environment Actions), and which represent actions upon one object (see Localized Object Actions) -- and indicate which object is being acted upon, of course!. When a given control is not meant to be used at a given time, disable it (Disabled Irrelevant Things).

To help naive users figure out what's what on a counterintuitive display, or on one that's meant for experts, you could employ Short Description or Optional Detail On Demand. To alert the user to side effects and to unexpected situations, use Reality Check and Important Message, respectively.

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

WYSIWYG Editor

Examples:

Illustrator, PowerPoint, Macdraw, and other drawing software
Text editors such as Word, WordPerfect, and Netscape Composer
GUI builders such as Visual Basic or JBuilder
Paper sketchpad
Newspaper layout [what are those pasteup things called?]

Context: The artifact is used as a tool or environment in which other artifacts may be created (particularly those with visual aspects).

Problem: How can the artifact best present what is being created, and what the user needs to do to create or change it?

Forces:

People already have the skills to draw, write, sculpt, arrange, etc.
The user wants to see what they're creating immediately, as they work with it; this instant feedback leads to a strong sense of engagement with the work.
It's faster or easier for a user to do certain operations visually, rather than programmatically or linguistically -- but not all operations.

Solution: Always show the user an accurate and up-to-date representation of the artifact they are creating ("what you see is what you get"); allow the user to interact directly with it as they add to it, delete from it, modify it, and so on. If additional information or tools are necessary to permit such interaction, such as object handles, then design them so that they don't significantly interfere with the user's ability to see the whole creation.

Sometimes it is easier to let the tool do certain mechanical jobs, such as precise layout, repetitive tasks, complex geometric shapes, image or sound processing, etc. Don't make the user do these by hand unless they choose to; provide easy-to-use automation instead, in a way which is smoothly integrated into the WYSIWYG Editor itself, and which doesn't require a jarring context shift in the user's mind (see Brenda Laurel, Computers As Theatre, chapter 5).

Resulting Context: Use a Toolbox for creation of different kinds of items or structures, and Localized Object Actions (often paired with Actions for Multiple Objects) to modify them and operate on them. The Personal Object Space pattern will let the user arrange their working surface to fit the way they work best; to preserve the user's settings and state from session to session, use User Preferences and Remembered State. Interaction History allows the user to see how they've modified the artifact lately, and to roll back to a previous version if they wish. Sovereign Posture is often used with this pattern, because these kinds of artifacts usually require sustained attention and a non-trivial learning curve.

While visual affordances are a good way to show how parts of the created thing can be manipulated, they have their problems: they usually obscure the user's view to some extent, are part of the tool rather than part of the created thing itself, and contribute to visual clutter. Therefore, Pointer Shows Affordance can be used to augment or replace them (and so can Short Description, as with tooltips).

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

Composed Command

Examples:

UNIX or DOS command-line interface
SQL
Spoken instructions to an interface made for visually impaired people
One human telling another to do something
Programming and scripting languages

Context: The possible actions to be taken with the artifact can be expressed through commands, which can be composed from smaller parts, in a language-like syntax with precise and learnable rules; and the users are willing and able to learn that syntax.

Problem: How can the artifact best present the actions that the user may take?

Forces:

Expert users often find linguistic commands to be more efficient than visual representations or direct manipulation.
Sometimes the available actions cannot, or should not, be expressed graphically (perhaps because there is an intractably large set of them).
The visual channel may not be available at all to the artifact or to the user.
The artifact is able to provide feedback on the correctness and appropriateness of the given commands.

Solution: Provide a way for the user to directly enter the command, such as by speech or by typing it in. Feedback on the validity of the command, or its results, should be as immediate as is practical. The parts and syntax rules should be easy to learn, and should generate concise commands whose meaning is obvious. Offer a way to do auto-completion or a set of possible interpretations of partially-entered commands, especially if the user is unwilling or unable to learn the language -- but beware the expert user, who may find this irritating! Allow it to be turned off if necessary.

Resulting Context: The possible actions divide neatly into environmental and object actions (see Convenient Environment Actions and Localized Object Actions); let the object actions accept "wildcards" in place of the object, to effect Actions for Multiple Objects. Forgiving Text Entry lets the user give commands with a generous margin for error, which is necessary for a natural-language-style interface and pleasant for other kinds. Reality Check and Progress Indicator generally make dialogue-like actions easier for users to deal with.

Most existing Composed Command systems provide some kind of Interaction History. In the linear dialogue that this pattern imposes upon the user, a history can be invaluable; users often need to repeat previous commands, sometimes with minor changes, and they sometimes need to know what they've done recently. Composed Command also takes well to Scripted Action Sequences (also common in on-line implementations of this pattern), especially since users are already thinking in terms of grammar and composable parts.

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

Navigable Spaces

Examples:

The WWW and other hypertext systems
Myst
Museum exhibit in a set of physical rooms
Set of applications in a suite, as with the PalmPilot or a network computer

Context: The artifact contains a large amount of content -- too much to be reasonably presented in a single view. This content can be organized into distinct conceptual spaces or working surfaces which are semantically linked to each other, so that it is natural and meaningful to go from one to another.

Problem: How can you present the content so that a user can explore it at their own pace, in a way which is comprehensible and engaging to the user?

Forces:

The user wants to know where they can (or should) go next, and how it's related to where they are now.
The user wants to be able to choose where to go next.
The user doesn't want to get lost.
The concept of information spaces is a natural one for people to think about, both because it mirrors the real world and because the WWW is so commonly understood.
It's delightful to explore a new place, where the user doesn't necessarily know what's "around the corner."

Solution: Create the illusion that the working surfaces are spaces, or places the user can "go" into and out of. Start out with at least one top-level or "home" space, to which the user can easily return (Clear Entry Points). In each space, clearly indicate how you get to the next space(s), such as by underlined text, buttons, images of doors, architectural features, etc. Use the spatial locations of these links to help the user remember where the links are. Provide a map of how the spaces are interconnected (Map of Navigable Spaces), preferably one that allows the user to go directly to the spaces represented on the map. Make sure that the user can easily retreat out of a space (Go Back One Step) or return to the home space (Go Back to a Safe Place). Illustration of "Navigable Spaces"

The user will build a mental model of the content from the structure of the Navigable Spaces. Therefore, construct the spaces and their interconnections to mirror the model you want to present (which may not be the same as the actual underlying data structure). Chains, trees, and star patterns are common ways to structure Navigable Spaces (see illustration below); they are easy to understand, visualize, and navigate, and they can contain rich content.

Resulting Context: As pointed out above, Map of Navigable Spaces should be one of the first patterns you deal with, even if you explicitly choose not to use one; the same for Go Back One Step and Go Back to a Safe Place. To help show where the links are in the spaces, you can use Pointer Shows Affordance; to give additional information about where they go, use Short Description.

People using the WWW tend to depend upon their browser's Interaction History (the links you've most recently visited, in chronological order) to get around. Not surprisingly, they also depend upon their Bookmarks to keep track of places they want to go back to. These two patterns might be especially important in any large or unbounded set of Navigable Spaces, particularly if a map is impractical.

When you're dealing with power users, seriously consider the value of displaying more than one surface at a time, perhaps using Tiled Working Surfaces. It's often good to provide the user with the option of being in at least two or three spaces of their choice, especially if a user is likely to be jumping between spaces frequently. This does increase the user's cognitive load, though, so it may not be appropriate for simpler artifacts that require short learning curves.

Notes: With games, part of the fun is in figuring out where you are and where you can go next, so maps and obvious links would actually reduce the user's fun. In a way, the WWW is similar -- who could ever make a map of the WWW anyway? -- but, of course, not everyone uses it for fun.

Notice that chains are structured similarly to Step-by-Step Instructions, trees to Hierarchical Set, and stars to Central Working Surface. All three of these archetypes have very strong, simple geometric properties; they probably warrant further exploration.

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

Overview Beside Detail

Examples:

Windows Explorer and many other file-system exploration dialogs
Web sites that contain a "site contents" frame on the left, and a frame containing the current page on the right
Email readers that show you a list of messages on one side, and the content of the selected message on the other side
Many visualization tools for large hierarchies or geographical maps

Context: The artifact contains a large amount of content -- too much to be reasonably presented in a single view. This content may be cleanly partitioned into a top-level set of objects or categories, such as document names and document content, containers and their contents, or objects and their properties; alternatively, the content may be a large, continuous, very detailed data set, in which users may have specific areas of interest.

Problem: How can you present this large amount of content so that a user can explore it at their own pace, in a way which is comprehensible and engaging to the user?

Forces:

Should always be able to see where you are; keep it within visual field, not hidden or distant
User wants to move between the detail views quickly, e.g. to compare and contrast
Not enough space to show multiple detail views simultaneously; may be constrained to one working surface
Too confusing to show multiple detail views simultaneously
Lets user concentrate on one object, category, or area of interest at a time
One working surface is easy to deal with -- no window shuffling or restacking
Easy navigation, managed by one (often flat) set of objects -- a star pattern

Solution: Show the whole set of objects, or the whole undetailed data set, in one part of the display area, to act as an overview of the content. When the user selects a single object, category, or area of interest within that overview, immediately show its related content -- its detail -- in the remaining space. As the user changes the selection, update the detail area to always reflect the current selection.

Keep the overview and detail areas spatially adjacent, so that the user can easily glance back and forth, using the overview area to drive the decisions about what to look at next. If you use Tiled Working Surfaces to relate them to each other, the user doesn't need to mentally "context switch" or make any extra gestures to go from one area to the other (such as raising one window above another). This enables a sense of flow.

Resulting Context: You have to decide how the user selects the part of the overview that they're interested in. The kind of data you're working with should suggest a graceful solution: a set of objects can be selected one at at time (or perhaps several contiguous ones), while a continuous data set like a geographic map may provide a freely movable "thumbnail," drawn on top of the overview, that shows the current selection.

A set of high-level objects or categories can be linear, hierarchical, or otherwise organized by whatever principle is appropriate -- see Hierarchical Set, Tabular Set, Editable Collection, Personal Object Space, and whatever other patterns you find appropriate.

Sometimes you just can't easily partition the content into only two levels of abstraction at a time. You should always retain the high-level overview, but you could then take the detail view and make it act like a second-level overview, so that the user can drill down one more level to see yet more detail. This recursion then gives you a total of three views, and you can continue the recursion for as many levels of depth as you need to. Netscape Messenger does this to show email and news, by the way: an upper-left panel shows the mailbox or newsgroup hierarchy, an upper-right panel shows the list of messages in the currently-selected mailbox or newsgroup, and a large bottom panel shows the message currently selected in that upper-right panel. Stuart Card et. al. recommend that for zooming in on a continuous data set, use a zoom factor between 3 and 30; more than that becomes disorienting for the user.

Sophisticated users may find it too constraining to see only one detail view at a time; if so, consider allowing multiple detail views simultaneously, possibly using Pile of Working Surfaces. Just keep in mind the increased complexity of the artifact when you do that -- users may get confused about where they are. I have rarely found it necessary to do this, however.

Notes: This pattern has also been noted, though not in pattern terminology, by Stuart Card, et. al. in their book Readings in Information Visualization: Using Vision to Think. A two-paper section called "Overview Plus Detail" is devoted to this concept; in the section introduction, they explain their reasoning:

Having an overview is very important. It reduces search, allows the detection of overall patterns [in the data], and aids the user in choosing the next move. But it is also necessary for the user to access details rapidly. One solution is overview plus detail.

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

Step-by-step Instructions

Step-by-Step Instructions

Examples:

Wizards
Installation instructions for all kinds of appliances, software, etc.
Recipes
Repair manuals
Getting cash from an ATM

Context: A user needs to perform a complex task, with limited time, knowledge, attention, or space. Alternatively, the nature of the task is step-by-step, and it's meaningless to show all the action possibilities at once.

Problem: How can the artifact unfold the possible actions to the user in a way that does not overwhelm or confuse them, but instead guides them to a successful task completion?

Forces:

The user doesn't always want, or need, to understand all the details of what they are doing.
A user presented with a bunch of possible actions, in no prescribed order, may not have any practical way to figure out what to do first, second, etc.
A user who is afraid of doing something wrong may prefer that the actions they have to perform be explicitly spelled out for them.
The whole task can't be performed entirely automatically, because it requires choices or information from the user.

Solution: Walk the user through the task one step at a time, giving very clear instructions at each step. Use visual similarities in all the steps, e.g. typography and layout, to maintain a rhythm throughout the task; make each step a focal point, both visually and in the user's "attention space." If information is needed from the user, ask for it in simple terms and with brevity; by keeping it short, you can better maintain the user's sense of flow through the whole step-by-step process.

The task may branch like a flow chart, depending upon what information the user gives it, but the user doesn't necessarily need to know about all the available paths through the task. If it's not likely to confuse the user, show the steps as a Map of Navigable Spaces. If possible, allow the user to back out of the steps (Go Back One Step, Go Back to a Safe Place). If the sequence of steps as seen by the user is too long -- more than ten steps, for example -- try to break it up into manageable sub-sequences, so it doesn't get too tedious for the user. Make sure the sub-sequences relate to each other in a meaningful way, however, or the user may see it as gratuitous or annoying.

Sometimes users may want to know more about what they're doing -- Optional Detail On Demand gives you a way to present that extra information. Also, if a user has gone through a lot of steps, they have trouble remembering what they've done and why. At least provide a Progress Indicator if the number of steps grows beyond seven or eight, which is the average limit of short-term memory. If a lot of user interaction is necessary, such as for branching decisions, consider providing an Interaction History

Resulting Context: Narrative is a good choice for presenting the task steps themselves; the use of natural language to describe what needs to be done is intuitively obvious, and puts a user at ease. Go Back One Step and Go Back to a Safe Place, along with a corresponding Forward control, can be used to move through an interactive task.

To get information from the user, you can use a Form or its simpler component patterns, especially Choice from a Small Set and Forgiving Text Entry. Using Good Defaults with them allows the user to move smoothly past the points where extra data entry is unnecessary, again preserving the sense of flow. Finally, a small set of Convenient Environment Actions should give the user ways to cancel or suspend the task without having to back out of it one step at a time.

Notes: Be aware that this pattern may irritate experienced users. If a user knows exactly what they need to do, and want to do it quickly, constraint to this step-by-step presentation can feel like a straitjacket! Also, if the task to be accomplished isn't inherently linear -- i.e. you don't really have to do one step first, another step second, etc. -- you might provide an alternative "random access" presentation of the possible actions, such as a Stack of Working Surfaces.

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

Small Groups of Related Things

Context: There are many items or actions to show the user, some of which are more closely related to each other than other things. This context is extremely common, occurring in many of the high-level patterns in this language, including (but not limited to) High-density Information Display, Status Display, Control Panel, and Form.

Problem: How should the items or actions be organized?

Forces:

Large, undifferentiated masses of things can be intimidating and difficult to figure out, especially to someone seeing them for the first time.
The brain is very good at discerning groups and nested groups of things, and at getting a "big picture" from the grouping structure.
The items cannot or should not be shown on separate working surfaces; for instance, because they are part of one coherent task.
People naturally assume semantic coherence where there is visual coherence.

Solution: Group the closely-related things together, nesting them in a hierarchy of groups if needed. Keep the number of things in any one group to around ten or fewer, even if the things are other groups. Use repetition and symmetry to keep the groups from becoming visually chaotic (and don't overuse boxes, even the nice etched ones in some GUI toolkits; white space often works just as well). Make sure that the grouping is not arbitrary, but is based on the meaning of what is being shown -- as pointed out in the Forces, a user will naturally try to derive some kind of semantic meaning from the groupings, even if it's wrong.

Resulting Context: To make a visual grouping of things look good, it's tempting to shortchange their individual usability. Try not to make too many sacrifices here. For instance, a common mistake made by Form designers is to make a text box too short for the expected input, simply to make it visually fit in with the Small Group of Related Things (e.g. other text boxes) that it belongs to. Also, there's no need to be dogmatic about this pattern -- expert users of a WYSIWYG Editor, for instance, may prefer that their Toolbox just show all the available tools as densely packed as possible, to save space.

Sometimes a large group of homogeneous items work together to form a single conceptual entity. This is true about many High-density Information Displays -- data points on a scatter chart, for instance, or a column of numbers representing a single variable. This pattern shouldn't apply to them. See Edward Tufte's book Envisioning Information, in particular the chapter on "Small Multiples," for an excellent set of counterexamples: these large sets of items are meant to show small changes between individual items that share most characteristics, to make those changes stand out. The impact comes from seeing all those similar items next to each other. In many cases, that impact would be completely lost if you broke up those sets of items into small groups!

Notes: This is a very basic way of managing complexity, and is almost more of a principle than a pattern. The "ten or fewer" comes from Miller's number (7+-2), which represents, among other things, the upper limit of someone's ability to "instantly" scan a set of items. Beyond that, the time it takes to read through the items grows linearly.

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

Hierarchical Set

Examples:

Windows Explorer
Class-hierarchy diagrams
Family tree charts

Context: There are many things to show the user, and they are interrelated in a hierarchy (or can be made to appear that way). This could be in a High-density Information Display, or a Map of Navigable Spaces, or as the organizing principle for a Stack of Working Surfaces.

Problem: How should the information be organized?

Forces:

The user should see the structure of the data.
Hierarchies are easy to understand.
They are also quick to traverse, if the user knows where something is in the hierarchy.

Solution: Show the data in a tree-like structure. Keep all the nodes at a given depth from the root in the same line, plane, or arc, to emphasize their parallelism. Allow non-leaf nodes to be opened and closed, to give the user control over how much of the hierarchy is visible at any one time. Depending on expected usage, try to balance the demands of having a dense, fully-visible structure with the ability to look at the details of individual nodes; if necessary, use panning and zooming, and other patterns like Short Description and Optional Detail On Demand.

Resulting Context: You get a form of Optional Detail On Demand for free if you let users open and close parent nodes -- if someone wants to see the children of a given node, they can, or they can ignore it. Pointer Shows Affordance is a way to indicate that a node can be opened or closed. Remembered State gives you a way to set up the node states according to how the user arranged them last time.

Notes: The Windows Explorer has brought the columnar "outline view" into common usage in desktop GUIs, and every self-respecting toolkit has one; they're great for fitting a hierarchy into a narrow space, but if you don't have that space restriction, try to use something more visually interesting, like an actual 2D drawn tree. These are much better at showing and manipulating large hierarchies than outlines are, because you don't have to stack everything together in one column, then scroll forever to get a big picture. (Doing them right is a non-trivial programming problem, unfortunately.)

Some designers have come up with pretty amazing ways of viewing very large hierarchies. Circular "fisheye" viewers, 3D rotating cylinders... [find references for these, in CHI proceedings somewhere]

Beware of using trees if the relationships among the data represent a directed graph instead, such as with multiple inheritance in a class diagram. It can be done, but it's not kind to the user -- they then see one thing in several places in the hierarchy, which may be very confusing. If it's truly a graph, draw the graph and don't oversimplify it. (The term "graph" here refers to its mathematical meaning, in which a set of vertices is arbitrarily interconnected via edges.)

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

Tabular Set

Examples:

Spreadsheets
Stock price tables
Phone book

Context: There are many homogeneous things to show the user, each of which has similar additional information or subparts. This is often used in a High-density Information Display.

Problem: How should the information be organized?

Forces:

The user should see the structure of the data.
The user wants to easily look up a specific piece of information.
Putting similar information into columns facilitates quick comparison of values.
It's easy, and intuitively obvious, to sort a table according to the data in the columns.

Solution: Show the data in a table structure. Order it according to some appropriate organizing principle, such as by the value of some column (if the table's principal use is to compare items by that value) or alphabetically by item (if its principal use is to look up values). Put some white space between columns to set them apart, but not too much; the user's eye shouldn't have to work too hard to go from one column to another.

The columns themselves should be organized logically. Depending upon your purpose, they may be organized with the most commonly needed data immediately after the item name, and in decreasing order of importance as you move from left to right. Or they may be organized in groups, with the group names above the column names (Small Groups of Related Things). The best organization will depend upon the data and the user's purposes.

If it's reasonable to do so, allow the user to adjust column widths, column order, and sort order. Many user-interface toolkits for computer applications provide these capabilities.

Resulting Context: If there's no obvious way to indicate that the columns are manipulable (e.g. sortable, or with changeable widths), at least use Pointer Shows Affordance. Remembered State gives you a way to set up the column states according to how the user arranged them last time.

Notes: Howard Wainer's book Visual Revelations has a brief but good chapter about table design. It's worth reading if you will be designing a lot of these.

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

Chart or Graph

Examples:

Line charts
Scatter charts
Pie charts
Bar graphs
Timelines

Context: There is a lot of homogeneous data to show the user, possibly in multiple data sets. This is likely to be needed in a High-density Information Display, or a Status Display, or even a Control Panel.

Problem: How should the information be organized?

Forces:

The user wants to get a "big picture" quickly.
Getting specific data out of it is secondary or unimportant.
Graphs facilitate easy comparison of values to each other.
Pictures have a bigger immediate, emotional impact than numbers.

Solution: Show the data plotted against time or some other variable. Plot it together with other variables for further comparison. [unfinished]

Notes: Tufte's books go into great detail about these.

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

Optional Detail On Demand

Examples:

Windows 95 color dialog that opens to show a complete RGB color square
The "Advanced" or "Other Options" buttons that appear on many dialogs
The panel on front of some VCRs that hide everything except the basic playing controls
Footnotes
The fine print on credit card applications, purchase agreements, etc.
Visual C++ debugger tooltips that show a variable's value when the cursor hovers over the variable in the source code

Context: A large percentage of the available information or actions (termed "items" for the rest of this pattern) can be considered details, and are unneeded most of the time. This is a very common situation which can happen in any of the primary patterns -- Narrative (footnotes), High-density Information Display (extra information), Form (optional information provided by the user), and so on.

Problem: When should these usually-unneeded items be presented to the user, and how?

Forces:

The user may be confused or overwhelmed if they are presented with lots of items at once.
The most-often-used items should be right at hand, and distinct from the details that may be unneeded; this helps orient the user towards what they are most likely to need.
All the possible items should be easily available to the users that need them.
Sometimes there isn't enough space to show all the possible items.

Solution: Up front, show the user that which is most important and most likely to get used. Details and further options which won't be needed most of the time -- say 20% or less of expected uses -- can be hidden in a separate space or working surface (another dialog, another piece of paper, behind a blank panel). Mark it clearly so that a user who needs this optional detail can find it immediately. Place the "handle" to it (push button, panel door latch, etc.) very close to the primary working surface, where everything else is, so a user doesn't have to go hunting for it. Make sure that very little effort is needed to get at it.

Resulting Context: You need to figure out which items are most needed, and which are optional. Know your users' needs well. If you can't make a good enough guess on that basis, try putting a few items on the top level and the rest hidden; observe your users using the artifact, and as it becomes clear which items are the most often used, "promote" them to the top level (and "demote" the ones at the top level that never get used). In spite of this hit-or-miss approach, try to make a coherent design out of the items at the top level.

This is a very common, simple way to manage complexity in an artifact. It can sometimes fail, however. Consider a user who might always want to see the optional detail: from the designer's point of view, perhaps only 10% of the total uses of the artifact require the optional detail, but from this user's p