Making Design Patterns Work in Practice

by Tom Vollaro on March 19, 2010

Like many design organizations, we attempt to encode our best practices into a design pattern language.  I will not go into an in-depth history of design patterns, but I suggest a weekend reading of Christopher Alexander’s The Timeless Way of Building and Luke Wroblewski’s excellent moderated discussion as a good place to start.

While many design pattern libraries have been created in the past 10-15 years, there are only a few good examples of them being put to use (with the exception of the Yahoo! effort). Our goal is to create a set of interaction design patterns that our entire organization can use to design, develop, document and test our products. The proverbial money must now be placed where our mouth is.

In user-centered design (UCD), design patterns have taken hold due to the promise of creating reusable components, which in turn saves work and drives consistency. While this is a primary goal for creating our design patterns, we also strive toward Alexander’s “quality without a name.” This means the feeling of seamlessness and flow you achieve with a well-honed and well-used tool.  

Defining User Experience Design Patterns

 

We spent a lot of time fine-tuning and debating the definition of a pattern, the proper levels of abstraction and how it can be applied to our work. In the end, we and other pattern writers discovered we had overloaded the term. In the typical euphoric “patterns are everywhere!” stage of any pattern writing effort, we tried to define everything into a pattern. What we found by revisiting Alexander’s original idea of a language is that we can combine interaction patterns with other parts of speech which have their own distinct rules. Our user exerience (UX) pattern language can be broken down into the following categories, ranging from high to low level of abstraction.

Design Principles – the “Grammar”

A design principle defines a well-known user interaction and/or user interface principle that is generally accepted by designers within the user experience design community. These principles are supported by a body of research and practice. Design principles act as “meta patterns” that link to other interaction and user interface patterns. Two examples are: Progressive Disclosure and Use Good Defaults.

User Interaction Patterns – the “Nouns”

The bulk of our pattern language consists of user interaction patterns. In its simplest form, a design pattern is an optimal solution to a common problem in specific context(s).

• Problem (what): The problem can either be a common, recurring user problem and/or a common, recurring workflow.
• Solution (how): The core of a pattern is the solution to the problem. It is abstract enough to apply broadly to the context but concrete enough to solve the user problem or address the workflow.
• Context (where/when): Where and when this solution should be applied. This may include a specific application, a specific application state or mode, or a use case. A pattern may have multiple variations to accommodate different contexts.
• Rationale (why): The rationale provides an explanation, backed up with data, of why this solution is correct in this context.

User Interface Guidelines – the “Adjectives”

User interface guidelines describe the nuts and bolts of how to visually lay out a user interface.  Storing the guidelines in a wiki allows for these to be easily linked to, linked from and searched.  Examples include Control Sizing and Tab Order.

Task Cases – the “Verbs”

Many of the patterns’ solution definitions include user and system behaviors that are supported by the pattern. To define these behaviors so that they are re-usable across a wide range of patterns, we use task cases. A task case is a short story that describes how an actor interacts with a system to achieve a specific goal. It is an abstract, generalized, technology-free description of the essence of a problem.  (Adopted from Constantine and Lockwood’s usage-centered design.)

An Example: Item Filter

This separation allows us to clearly delineate a low level guideline (such as how to align control labels) from higher order patterns and principles. Furthermore, task cases allow us to define abstract behaviors separated from specific implementations. The following example illustrates a pattern with three variations and the corresponding principles, guidelines and task cases.

Pattern: Filter Items
Problem:  User needs to filter information the system or document provided.

Context:   Use when the system or the document provides a collection of items that are difficult to browse or manage.

Solution Variations: 

 

Principle: Progressive Disclosure

Task Case: Show/Hide Items

Guidelines: Check box, Combo box, Label alignment, Table

 

Comments

[Uxsuccess]

We are in the process of discovering and documenting our design patterns. Recruiting the engineers to help us discover them: do you have experience with a good way to capture these as they come in from the field?

[ambrose little]

Glad to hear more people are using design patterns. They rock. :)

Plug:
You might be interested in Quince--we developed it to make discovering UI/UX design patterns easier and recently enhanced it with the ability to create private libraries so folks like you can leverage the public library and still have the security to provide your context-specific design guidance: http://quince.infragistics.com