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:

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:

  1. 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.
  2. 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:"

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:

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.

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

Copyright (c) 1999 by Jenifer Tidwell.  All rights reserved.