Usability Patterns FAQ
What's at this site?
This is a collection of usability patterns maintained by members of
The Usability Group
at the University of Brighton, UK.
What's its status?
It is very much a "work in progress" and always will be! Christopher
Alexander, the inventor of the concept of "pattern languages", suggests
that finding patterns is as hard as doing theoretical nuclear physics.
Patterns need to be refined and worked over by practitioners to capture
true invariants in them. Currently this collection simply contains
seeds of potential patterns. They all need considerable cultivation,
some may need thinning out, and there is plenty of room for planting more.
We welcome your comments.
Any amendments or additions made as a result of feedback from usability
practitioners will be acknowledged on this site and in any ensuing publications.
What is "usability"?
Here is a quote from the British Government Department of Trade and
Industry that stakes out the territory.
"... we need to design systems that take into account the people who
are to use them and the way they are to be used. In particular, we
need to develop new technology that is both usable and effective.
This means designing for health, safety, efficiency and even enjoyment!"
[DTI]
Where did the idea of patterns and pattern
language come from?
This is an idea developed by Christopher Alexander, [Salingaros]
(Professor of Architecture at the University of California at Berkeley
since 1963), to enable the handling of complex issues involved in urban
and building design. The ideas have been enthusiastically embraced by
the software engineering, object oriented design community. For an introduction
to the ideas from their perspective see [Lea].
There, it is the formal use of pattern rules to capture complex abstract
structures that are emphasized. It would appear that HCI design is
much closer to the architectural roots of pattern language, as the feelings
that users have about their computer systems are important to us, just
as the feelings dwellers have about their houses are relevant to architects.
(Interestingly, Apple's "Macintosh Human Interface Guidelines", [Apple
Computer, Inc.], contains a reference to Alexander's "A Pattern Language"
[Alexander, et. al., 1977]
in the "Environmental Design" section of its biblography.) Whilst the
relevance of this approach has been recognized, [Erickson,
1997] so far not a great deal has been published. References
discovered are; [Casaday, 1997],
[Fitzpatrick, et. al, 1998],
[Pemberton &
Griffiths, 1998], [Mahemoff
& Johnston, 1998]. Thomas Erickson has created a Web site
to hold references to the growing body of work in this area. [Erickson,
1998]
Patterns grew out of Alexander's disaffection with the quality of architecture
in the 1960’s, which he attributed in part to the misapplication of formal
methods in architectural design. This had resulted in buildings which
failed to fulfil the real needs of the people who lived and worked in them,
which failed to adapt to local social and physical environments and which
people simply did not like (cf. [Lea]).
Alexander contrasts these modern failed buildings with the many successful,
“living” buildings, created in other societies, buildings which for Alexander
embodied “the quality without a name”, a recognizable but indefinable quality
which floats in the semantic space bordered by terms such as “alive”, “whole”,
“comfortable”, “free”, “exact”, “egoless” and “eternal”. Alexander's patterns
are conceptual tools for helping people design buildings which might themselves
have that quality.
We are attempting here to apply this idea to the design of usable interfaces
for software systems.
What is a pattern?
"We see, in summary, that every pattern we define must be formulated
in the form of a rule which establishes a relationship between a context,
a system of forces which arises in that context, and a configuration which
allows these forces to resolve themselves in that context." [Alexander
1979, pp.253]
A pattern is the solution to a problem in a context. To put it less
succinctly, in a context or a set of situations, a problem or clash of
constraints will occur, which is amenable to resolution by a canonical
design form or solution. The pattern encompasses all three elements: the
situation, the problem of clashing constraints or forces, and the canonical
solution. An example problem in a context, from Alexander, would occur
where parents and children live in a house together (situation/context),
in which the parents would like their own space away from the children,
but still want to be able to go easily to the children if, for instance,
they are ill or anxious at night (problem). A standard solution would
be to create a separate space for the parents, still within easy reach
of the children's room. This is the pattern “Couples Realm”, number 136
among the 253 patterns presented in "A Pattern Language." Like all the
patterns it is connected both to larger patterns, which it completes, including,
in this case, “house for a couple” and “intimacy gradient”, and to smaller
patterns which in turn complete it, in this case “low doors”, “sitting
circle”, “light on two sides” and “marriage bed” among others.
At the highest level in Alexander's pattern language, we find patterns
such as “Independent regions”, “Country towns” and “The distribution of
towns”, while at the other end of the scale are detailed patterns covering
the need for a bench by a front door and for different sorts of chairs
to be provided in a room. Together the linked patterns form a Pattern
Language, a kind of informal grammar for buildings and spaces.
The solutions are not simply pre-formed parts of a building kit. A
pattern is an abstraction from any specific examples: this is what gives
patterns their generative power. They do not supply ready finished answers,
People need to exercise their own creativity to implement a pattern. In
addition, because they involve abstracting away from individual cases,
patterns are hard to discover and may take a long time to describe adequately.
What does a pattern look like?
Alexander's patterns are structured as follows:
Title
Which succinctly (and evocatively) captures the solution that the pattern
offers.
Asterisks
To mark the significance of the pattern, two asterisks marking a “true
invariant”, one marking a pattern which has made progress towards identifying
such an invariant, but which needs further work, and no asterisks indicating
confidence that an invariant has not been established, and that variations
are to be expected.
Picture
“... which shows an archetypal example of that pattern.” This may
be literal or impressionistic. A subsidiary function of the picture may
be to help the reader remember and find the pattern subsequently.
Introductory paragraph
Setting the context and linking to higher level patterns.
¤¤¤
To mark the beginning of the problem.
Headline
(In bold type) summarizing the essence of the problem.
Body of the problem
Describing the empirical background of the pattern, the evidence for
its validity, range of variation of manifestation.
Solution
(In bold type) Describing the “... field of physical and social relationships
which are required to solve the stated problem in the stated context.”
as a statement, in imperative form.
Diagram
Of the solution (For Alexander the solution should always be capable
of a diagrammatic representation.)
¤¤¤
To mark the end of the main body of the pattern.
Connections to lower level patterns
Which are required to complete this pattern.
We have minimally adapted this form. The details can be found here.
How are patterns discovered?
Here are some quotations from Alexander to illustrate how he goes about
finding patterns (which he considers to be as difficult as doing theoretical
physics!).
"In order to discover patterns which are alive we must always start
with observation." [Alexander
1979, pp.254]
"Now try to discover some property which is common to all the ones
which feel good, and missing from all the ones which don't feel good." [Alexander
1979, pp.255]
"This property will be a highly complex relationship." [Alexander
1979, pp.255]
"Now try to identify the problem which exists in entrances [artefacts]
which lack this property." [Alexander
1979, pp.256]
"Knowledge of the problem then helps shed light on the invariant
which solves the problem." [Alexander
1979, pp.257]
"Sometimes we find our way to this invariant by starting with a set
of positive examples." [Alexander
1979, pp.258]
"At other times, we may discover the invariant by starting from the
negative examples, and resolving them." [Alexander
1979, pp.258]
"And occasionally, we do not start from concrete observations at
all, but build up the invariant by purely abstract argument." [Alexander
1979, pp.259]
"In all these cases, no matter what method is used, the pattern is
an attempt to discover some invariant feature, which distinguishes good
places from bad places with respect to some particular system of forces."
[Alexander 1979, pp.260]
What makes a good pattern?
Just filling in the template does not make a pattern. Patterns
should have the following properties (taken directly from [Lea]):
Encapsulation
Each pattern encapsulates a well defined problem/solution. Patterns
are independent, specific, and precisely formulated enough to make clear
when they apply and whether they capture real problems and issues, and
to ensure that each step of synthesis results in the construction of a
complete, recognizable entity, where each part makes sense as an in-the-small
whole.
Generativity
Each entry contains a local, self-standing process prescription describing
how to construct realizations. Pattern entries are written to be usable
by all development participants, not merely trained designers. Many patterns
are unashamedly ``recipes'', mirroring the ``unselfconscious'' procedures
characteristic of traditional methodless construction. An expert may still
use a pattern in the same way that an expert chef uses a cooking recipe
-- to help create a personal vision of a particular realization, while
still maintaining critical ingredients and proportions.
Equilibrium
Each pattern identifies a solution space containing an invariant that
minimizes conflict among forces and constraints. When a pattern is used
in an application, equilibrium provides a reason for each design step,
traceable to situational constraints. The rationale that the solution meets
this equilibrium may be a formal, theoretical derivation, an abstraction
from empirical data, observations of the pattern in naturally occurring
or traditional artefacts, a convincing series of examples, analysis of
poor or failed solutions, or any mixture of these. Equilibrium is the structural
side of optimality notions familiar in computing, and can be just as hard
to find a basis for, meet, or approximate. Alexander argues for establishment
of objective equilibria based in the ``quality without a name'' even (or
especially) when surrounding aesthetic, personal, and social factors. He
also notes the elusiveness of this goal -- artefacts more often than not
fail to achieve this quality despite the best of efforts.
Abstraction
Patterns represent abstractions of empirical experience and everyday
knowledge. They are general within the stated context, although not necessarily
universal. (Each entry in Patterns is marked with a ``universality'' designation
of zero to two stars.) Pattern construction (like domain analysis) is an
iterative social process collecting, sharing, and amplifying distributed
experience and knowledge. Also, patterns with a structural basis in or
similarity with natural and traditionally constructed artefacts exploit
well adapted partitionings of the world. Sometimes, patterns may be constructed
more mechanically, by merging others and/or transforming them to apply
to a different domain. And some patterns are so tied to universals that
they emerge from introspection and intuition uncontaminated by formalism.
Heuristics based on participatory design, introspection, linkage to existing
artefacts, and social consensus all increase the likelihood of identifying
central fixed and variable features, and play a role even when that environment
is purely internal and/or artificial, but where each part helps generate
a context for others.
Openness
Patterns may be extended down to arbitrarily fine levels of detail.
Like fractals, patterns have no top or bottom -- at the lowest levels of
any design effort, some are merely opaque and/or fluid (e.g., plaster,
concrete). Patterns are used in development by finding a collection of
entries addressing the desired features of the project at hand, where each
of these may in turn require other subpatterns. Experimentation with possible
variants and examination of the relationships among patterns that together
form the whole add constraints, adjustments and situation-specific specializations
and refinements. For example, while only a small set of patterns would
typically apply in the design of a certain housing community, each house
will itself be unique due to varying micro-patterns. Because the details
of pattern instantiations are encapsulated, they may vary within stated
constraints. These details often do impact and further constrain those
of other related patterns. But again, this variability remains within the
borders of higher-level constraints.
Composibility
Patterns are hierarchically related. Coarse grained patterns are layered
on top of, relate, and constrain fine grained ones. These relations include,
but are not restricted to various whole-part relations. Most patterns are
both upwardly and downwardly composible, minimizing interaction with other
patterns, making clear when two related patterns must share a third, and
admitting maximal variation in sub-patterns. Pattern entries are arranged
conceptually as a language that expresses this layering. Because the forms
of patterns and their relations to others are only loosely constrained
and written entirely in natural language, the pattern language is merely
analogous to a formal production system language, but has about the same
properties, including infinite nondeterministic generativity.
How are patterns different
from guidelines?
An immediate reaction to the idea of patterns in HCI design may be
that it simply replicates (in a rather long winded way) what has already
been done through the introduction of style guides such as the Macintosh
Human Interface Guidelines [Apple
1992] — which actually references Alexander’s work, The Windows Interface:
An Application Design Guide [Microsoft
1987], NASA Human-Computer Interface Guidelines [Carlow
International Incorporated 1992], and very many others. However
we claim that what is missing from these style guides, and is added in
the pattern approach, is the explicit acknowledgement that whole patterns
are being recorded. This implies that the meta-information
surrounding the simple imperative instruction normally found in guidelines
is recorded — and must have been thought through. This means explicitly
setting the context in a hierarchical structure of patterns, drawing attention
to the problem that the pattern solves, conceiving of the solution to the
problem as resolving conflicts in a field of interacting social and physical
relationships, and considering and stating degrees of confidence in the
invariance of the pattern. This makes patterns an altogether richer
resource for the designer than lists of guidelines — more akin to
the resources to be found in what we have called “craft wisdom” books,
a good example of which is [Cooper
1995] — but expressed in a canonical form.
Secondly, the use of patterns implies an emphasis on the process of
developing and using guidelines, rather than on the product — a list of
imperative directions. A good pattern will have been evolved out
of the experience (both successes and failures) and observations of a number
of designers. It is susceptible to further refinement in a way that
seeks to approach the underlying invariant, rather than simply recording
more cases.
Additionally, the use of a pattern language holds out the possibility
of involving the users of software interfaces in the design and modification
of these artefacts.
How do I access the patterns in this collection?
All of the patterns held in this collection are listed in the index,
to the left of this frame (or if your browser does not support frames,
here). The patterns are listed in alphabetical
order of their titles. Just click on the title you'd like to see.
Each pattern contains links to the other patterns that it is referenced
by and references. The interconnections between patterns are given
as well in a matrix (entry in the index)
from where individual patterns can also be accessed.
Where can I find out more about patterns?
The references from preceding FAQ answers and sources cited in the
patterns in this collection are here.
