Buiding
Building
User
Architectural
Feature
... To the
software
development
domain...
... Or to
the user
experience
domain
Programmer
Attribute of the
source code
Application
Software User
Attribute of the UI
Program
Source Code
• Figure 1. Analogy between architecture and software.
[ 7] Beck, K. and
Cunningham, W. “Using
Pattern Languages
for Object-oriented
Programs.” Tektronix,
Inc. Technical
Report No. CR-87-
43 (September 17,
1987), presented at
OOPSLA-87 workshop
on Specification and
Design for Object-Oriented Programming.
Available online at
http://c2.com/doc/oop-
sla87.html/
programming not become as
popular as the interactions that
were designed to support it?
March + April 2010
[ 8] Blackwell, A.F. “The
Reification of Metaphor
as a Design Tool.”
ACM Transactions
on Computer-Human
Interaction, 13, 4 (2006):
490–530.
[ 9] Blackwell, A.F. “First
Steps in Programming:
A Rationale for Attention
Investment Models.” In
Proceedings of the IEEE
Symposia on Human-Centric Computing
Languages and
Environments (2002):
2–10.
offices be designed and built by
their eventual occupants. These
people, he reasons, know best their
requirements for a particular structure. We agree, and make the same
argument for computer programs.
Computer users should write their
own programs [ 7].
Beck and Cunningham originally proposed the creation of
pattern languages for software
development, not to support
software engineers but end-user programmers. They were
interested in Smalltalk, a language originally conceived by
Alan Kay as an end-user programming environment that
would support new kinds of
artistic and creative experience
for users including children
and other non-professional programmers. The Smalltalk programming environment itself
included many UI innovations
that later evolved into successful interfaces of the Xerox Star,
the Macintosh and Windows
[ 8]. But why did end-user
We Took a Wrong Turn
It is our contention that there
was collective confusion
between ground and field: that
the cool features of the Xerox
Smalltalk environment—
windows, icons, mice—appeared
to engineers as though these
widgets were the invention,
irrespective of their application to create a transformed
user experience. Subsequently,
user-interface “patterns” have
continued to capture ways that
engineers compose these (and
other) widgets to build functional UIs. But this is missing
the point. Using the Smalltalk
widgets in that way has not
given users the power to conceive and restructure their own
experiences, and many GUI systems became even less flexible
than the command-line interfaces that preceded them.
The application of interaction patterns has remained
stuck in the “object world”—
they are still concerned with
the successful design and
engineering of a user interface.
User-interface patterns that
emphasize technical solutions
are extremely valuable, but
they are not the kind of design
pattern that Alexander envisaged; they are not primarily
concerned with the user’s experience of the designed product,
and neither do they empower
end-user programming in the
way that Beck and Cunningham
hoped to achieve.
We propose rather than
describing users’ encounter
with specific technical features,
it is possible to use patterns to
describe user experience with
the whole class of structured
information systems. This
ought to encompass users both
as consumers of standardized interface designs and as
empowered to customize and
modify the structure of information. Spreadsheets, content-management systems, word-processor macros, and home-network configuration are tools
that empower end users with
the capability of programmers,
giving them user experiences
that have the fundamental
characteristics of programming
[ 9]. The “patterns” here are not
a specific way of building a UI,
but a language for describing
user experiences with structured information.
interactions
What Would a User Experience
Pattern Look Like?
One classic example of such a
pattern in user experience was
noted 20 years ago by Thomas
Green. He had found a “sticky
