Whenever objects are created for people
to use, design is pervasive. Design may be done methodically
or offhandedly, consciously or accidentally. But when people
create software—or any other product—decisions are
made and objects are constructed that carry with them an intention
of what those objects will do and how they will be perceived
and used.
The education of computer professionals has often concentrated
on the understanding of computational mechanisms, and on engineering
methods that are intended to ensure that the mechanisms behave
as the programmer intends. The focus is on the objects being
designed: the hardware and software. The primary concern is to
implement a specified functionality efficiently. When software
engineers or programmers say that a piece of software works,
they typically mean that it is robust, is reliable, and meets
its functional specification. These concerns are indeed important.
Any designer who ignores them does so at the risk of disaster.
But this inward-looking perspective, with its focus on function
and construction, is one-sided. To design software that really
works, we need to move from a constructor’s-eye view
to a designer’s-eye view, taking the system, the users,
and the context all together as a starting point. When a designer
says that something works (for example, a layout for a
book cover or a design for a housing complex), the term reflects
a broader meaning. Good design produces an object that works
for people in a context of values and needs, to produce quality
results and a satisfying experience.
What Is Software?
In the context of a book on software design, it should be
obvious that we are concerned with designing software. It is
far from clear, however, just what that phrase means. We can
approach software from many different perspectives, each with
its own implications for design. In this book, we emphasize software
as a medium for the creation of virtualities—the
world in which a user of the software perceives, acts, and responds
to experiences.
The creation of a virtual world is immediately evident in
computer games, which dramatically engage the player in exploring
the vast reaches of space, fighting off the villains, finding
the treasures—actively living in whatever worlds the game
designer can imagine and portray. But the creation of worlds
is not limited to game designers. There is also a virtual world
in a desktop interface, a spreadsheet, and the Internet. The
difference between interface and world was recognized by the
designers of the Xerox Star—the progenitor of the modern
graphical user interface—in their focus on what David Liddle
(Chapter 2) refers to as the user's conceptual model.
Later projects have used other terms—such as conceptual
model, cognitive model, user’s model,
interface metaphor, user illusion, virtuality,
and ontology—all carrying the connotation that a
space of existence, rather than a set of devices or images, is
being designed. The term virtuality highlights the perspective
that the world is virtual, in a space that is neither a mental
construct of the user nor a mental construct of the designer.
Today, we are all familiar with the virtuality of the standard
graphical user interface—with its windows, icons, folders,
and the like. Although these virtual objects are loosely grounded
in analogies with the physical world, they exist in a unique
world of their own, with its special logic and potentials for
action by the user. The underlying programs manipulate disk sectors,
network addresses, data caches, and program segments. These underpinnings
do not appear—at least when things are working normally—in
the desktop virtuality in which the user works.
Software is not just a device with which the user interacts;
it is also the generator of a space in which the user lives.
Software design is like architecture: When an architect designs
a home or an office building, a structure is being specified.
More significantly, though, the patterns of life for its inhabitants
are being shaped. People are thought of as inhabitants
rather than as users of buildings. In this book, we approach
software users as inhabitants, focusing on an how they live in
the spaces that designers create. Our goal is to situate the
work of the designer in the world of the user.
The view of software that we adopt in this book is, of course,
not the only appropriate or valuable one. Designers can master
software, like any technology, only by understanding it from
contrasting perspectives. These perspectives provide a larger
context for our discussions.
Software engineering
The phrase software design is often used to characterize
the discipline that is also called software engineering—the
discipline concerned with the construction of software that is
efficient, reliable, robust, and easy to maintain. The substantial
body of literature on software design as an engineering activity
(for example, Pfleeger, 1991; Rumbaugh, 1991; Blum, 1992; Brooks,
1975, 1995), is complementary to the concerns developed in this
book.
Interface design
In a way, the title of this book is misleading. Bringing
Design to Software implies that the object of design is software,
leaving out considerations of the interface devices that are
the inevitable embodiment of software for the user. Design cannot
be neatly divided into compartments for software and for devices:
The possibilities for software are both created and constrained
by the physical interfaces. In today's world of computer applications,
the vast majority of applications present themselves to users
in a standard way—a visual display with a keyboard and mouse.
But the future of computing will bring richer resources to physical
human–computer interactions. Some new devices are already
in use on a modest scale—for example, pen-based personal
digital assistants (PDAs), virtual-reality goggles and gloves,
and computers embedded in electromechanical devices of all kinds.
Researchers are exploring further possibilities, including tactile
input and output devices, immersive environments, audio spaces,
wearable computers, and a host of gadgets that bear little resemblance
to today's personal computer or workstation. Many current textbooks
and reading collections on human–computer interaction (for
example, Shneiderman, 1992; Dix et al., 1993; Preece et al.,
1994; and Baecker et al., 1995) include sections on interface
devices. As experience with a wider variety of devices accumulates,
the design of interaction based on new combinations of devices
and software will be an important emerging topic in what we have—for
the moment—called software design.
Human–computer interaction
Whenever someone designs software that interacts with people,
the effects of the design extend beyond the software itself to
include the experiences that people will have in encountering
and using that software. A person encountering any artifact applies
knowledge and understanding, based on wide variety of cognitive
mechanisms grounded in human capacities for perception, memory,
and action. Researchers in human–computer interaction have
studied the mental worlds of computer users, developing approaches
and methods for predicting properties of the interactions and
for supporting the design of interfaces. Although it would be
overstating the case to say that the cognitive analysis of human–computer
interaction has led to commonly accepted and widely applied methods,
there is a substantial literature that can be of value to anyone
designing interactive software (for example, Card et al., 1983;
Norman and Draper, 1986; Carroll, 1991; Helander, 1988). Practical
applications of HCI research are promoted by organizations such
as ACM SIGCHI, the Human Factors and Ergonomics Society (see
Perlman et al., 1995), and the Usability Professionals Association.
Art
The experience of a person who is interacting with a computer
system is not limited to the cognitive aspects that have been
explored in the mainstream literature on human–computer
interaction. As humans, we experience the world in aesthetic,
affective, and emotional terms as well. Because computing evolved
initially for use in the laboratory and the office, noncognitive
aspects have been largely ignored, except by creators of computer
games. Yet, whenever people experience a piece of software—whether
it be a spreadsheet or a physics simulation—they have natural
human responses. They experience beauty, satisfaction, and fun,
or the corresponding opposites.
As computing becomes integrated into technologies for entertainment,
and as the typical user moves from the well-regimented office
to the home recreation room, software designers will need to
focus more on the affective dimensions of human response (see,
for example, Laurel, 1993). We can learn from the history of
other human communication media, and can adapt the principles
and techniques of novelists, film makers, composers, visual artists,
and many other designers in what are loosely called the arts.
Designing for the full range of human experience may well be
the theme for the next generation of discourse about software
design.
What Is Design?
Perhaps even more difficult than the task of defining software
is the task of defining design. A dictionary provides
several loosely overlapping meanings, and a glance at the design
section in a library or bookstore confuses the issue even more.
Although we label it with a noun, design is not a thing.
The questions that we can ask fruitfully are about the activity
of designing. The authors of our chapters did not produce
a simple definition; rather, each contributes to an answer by
providing a perspective on what people do when they design.
Design is conscious
People may refer to an object as being well designed
whenever it is well suited to its environment, even if this suitability
resulted from a process of unintentional evolution. In this book,
we concentrate on what happens when a designer reflects on and
brings focus to the design activity. Complex systems can evolve
without a coherent master design—for example, cities (see
Alexander, 1964) and the Internet (see Krol, 1994)—but even
in these cases, conscious design is at work in creating the individual
pieces and relationships that make up the whole.
Consciousness about designing does not imply the application
of a formal, consistent, or comprehensive theory of design or
of a universal methodology. Systematic principles and methods
at times may be applicable to the process of design, but there
is no effective equivalent to the rationalized generative theories
applied in mathematics and traditional engineering. Design consciousness
is still pervaded by intuition, tacit knowledge, and gut reaction.
Design keeps human concerns in the center
All engineering and design activities call for the management
of tradeoffs. Real-world problems rarely have a correct
solution of the kind that would be suitable for a mathematics
problem or for a textbook exercise. The designer looks for creative
solutions in a space of alternatives that is shaped by competing
values and resource needs. In classical engineering disciplines,
the tradeoffs can often be quantified: material strength, construction
costs, rate of wear, and the like. In design disciplines, the
tradeoffs are more difficult to identify and to measure. The
designer stands with one foot in the technology and one foot
in the domain of human concerns, and these two worlds are not
easily commensurable.
As an example, it is easy for software designers to fall into
a single-minded quest, in which ease of use (especially for beginning
users) becomes a holy grail. But what is ease of use?
How much does it matter to whom? A violin is extremely difficult
for novices to play, but it would be foolhardy to argue that
it should therefore be replaced by the autoharp. The value of
an artifact may lie in high-performance use by virtuosos, or
in ease of use for some special class of users, such as children
or people with disabilities. There is room for the software equivalents
of high-strung racing cars alongside automatic-transmission minivans.
In Chapter 5, Paul Saffo explores the dimensions of what matters
to consumers of high technology. He introduces a concept that
he calls the threshold of indignation—the point in
the tradeoff curve where, for different groups of users, the
perceived value is exceeded by the perceived hassle. A multidimensional
understanding of what concerns users is critical to an understanding
of where new software and electronics technologies will lead
in practice.
Design is a dialog with materials
The ongoing process of designing is iterative at two levels:
iteration by the designer as a piece of current work develops,
and iteration by the community as successive generations reveal
new possibilities for the medium. The cycle of an individual
designer's reflection in action is described in detail
in an interview with Donald Schön (Chapter 9), and is illustrated
in Shahaf Gal's account of a student mechanical-design project
(Chapter 11). As Schön and Gal point out, designing is inherently
complex—every choice by the designer has both intended and
unintended effects. Designing is not a process of careful planning
and execution, but rather it is like a dialog, in which the dialog
partner—the designed object itself—can generate unexpected
interruptions and contributions. The designer listens to the
emerging design, as well as shapes it.
Design always implies a medium of construction, and new technologies
bring with them new domains for design. Architecture as we know
it appeared with the technology for building with stone. Graphic
design emerged with the technologies of printing, and modern
product design flourished with the development of plastics that
expanded the possible variety of forms for everyday products.
The computer has produced the field of interaction design,
in which new kinds of virtualities can be created and modified
with a velocity that is unprecedented. The effect of new prototyping
media on industries as a whole is reflected in a discussion of
the cultures of prototyping by Michael Schrage in Chapter
10.
Design is creative
It is one thing to lay out a list of criteria for good design.
It is quite another thing to do design well. Many books have
been written on systematic methods for design, and in particular
for the design of interfaces and interactive systems (for example,
Hix and Hartson, 1993; Newman and Lamming, 1995). These texts
provide useful guidance, yet designing is a creative activity
that cannot be fully reduced to standard steps, and that cannot
even be comprehended as problem solving. As David Kelley
argues in Chapter 8, a designer lacks the comforting restraints
of a well-organized engineering discipline, because designing
is inherently messy; it includes, but goes beyond, the ability
to be creative in solving problems. It begins with creativity
in finding the problems—envisioning the needs that people
have but do not recognize.
For the artist–designer, depicted by Gillian Crampton
Smith and Philip Tabor in Chapter 3, interaction design is more
an art than a science—it is spontaneous, unpredictable,
and hard to define. The skill of the artist–designer is
not reducible to a set of methods, and is not learned through
the kind of structured curriculum that serves in science and
engineering. On the other hand, it is not a mysterious gift.
There is a long and rich tradition of education in the design
fields; it draws on the interaction between learner and teacher,
designer and critic.
Design is communication
Previous sections have described the interaction between the
user and his world, and the interaction between the designer
and her materials. What matters most is the interaction between
these two interactions. A virtuality is neither just what the
designer thinks it is, nor what any particular user thinks it
is. It exists in the ongoing dialog between designers and users.
To succeed in designing, we need to understand how designers
convey meaning.
At a surface level, designed artifacts communicate content.
As Crampton Smith and Tabor point out, even an object as mundane
as a railway timetable conveys meanings at multiple levels. Skilled
designers in every discipline know how to manage these layers
of meaning. In addition, an active artifact—whether it be
a computer program or a coffee maker—communicates to users
about its use. A device as apparently simple as a door communicates
to its users through convention. A door with a flat plate near
shoulder level says "Push me!" One with a round knob
says "Twist here." Although these messages are constrained
by the physical mechanisms, they are also a matter of convention
and learning, as every tourist finds out in trying to deal with
everyday objects in an unfamiliar culture. John Rheinfrank and
Shelley Evenson (Chapter 4) explain how these physical affordances
are one constituent of a broader design language in which
a variety of meanings is being communicated, including the functional,
the cognitive, the connotative, and the aesthetic. Whenever a
designer constructs an object for human use, she is drawing on
a background of shared design language in the community and culture.
As is true of any human language, what is visible in a statement
is only a small part of the full picture. A hearer of the sentence
"I’m going to kill you!" cannot interpret the
intended meaning without knowing the situational context—was
it said to a friend walking onto the tennis court, in an anonymous
note mailed to the President, or by a parent to a child who has
just left dirty clothing on the bathroom floor again? The literal
meaning is but the shadow of the meaning in context.
The same is true for the artifacts that we build, including
software: People do not approach them in isolation. Every object
appears in a context of expectations that is generated by the
history of previous objects and experiences, and by the surroundings
in the periphery—the physical, social, and historical
context in which the object is encountered. In Chapter 7, John
Seely Brown and Paul Duguid describe the border resources
that every designer draws on in creating something that is new—and
that inevitably also takes meaning from what came before. They
argue that widespread blindness to the periphery in software
design has led to designs that may extend the literal functionality
of traditional forms, but that are inappropriate in the larger
human context.
Design has social consequences
Much of the discussion on software design uses examples from
generic mass-distribution software, such as word processors,
operating systems, spreadsheets, graphics programs, and games.
Although many key concerns of software design are addressed in
these applications, others are not. These highly visible applications
are part of a larger picture that includes a vast number of vertical
applications (for example, a medical-office billing application)
and systems designed for a specific workplace setting. In these
more targeted applications, the designer can see and take into
account the specific effects of the design on the people who
will inhabit it.
In Chapter 14, Sarah Kuhn looks at the organizational aspects
of software design, which come to center stage when we build
integrated computer systems for specific organizations and workplaces.
The needs and concerns of the people in those workplaces can
lead to complex—and, at times, controversial—design
considerations, which we can address only by making the social
and political dimensions an explicit part of the analysis and
of the design dialog. The designer takes on a role that includes
organizational as well as technical design, and can enlist workers
directly in this process through techniques such as participatory
design.
In Chapter 6, Peter Denning and Pamela Dargan introduce a
technique for addressing work content as the central focus of
design, which they call action-centered design. Their
experience in working with traditional software engineering techniques
has pointed out areas of failure, which designers can address
by shifting attention to the structure of the work rather than
concentrating on the structure of the information systems that
support the work.
Design is a social activity
In concentrating on the activity of an individual designer,
we can fall into the error of assuming that the overall quality
of a design is primarily a result of the qualities and activities
of the creative individual. As Kelley points out, the designer
operates in a larger setting, which is both facilitated and constrained
by interactions with other people.
In Chapter 12, Donald Norman dramatically recounts how design
in a large organization is shaped by factors and forces that
transcend the considerations of an individual designer. He describes
two levels at which an organization constrains the space of possible
designs: the explicit level of working with the differing goals
and needs of the many parties in a large organization, and the
tacit effect of an organization's unique culture.
Norman's saga of how organizational structures can complicate
the activity of designing is complemented by Laura De Young's
analysis of what a software development organization can do to
facilitate customer-oriented design (Chapter 13). De Young draws
examples from her work as a consultant and from the experience
of Intuit—the producer of the extremely successful home
financial application, Quicken—to identify the principles
that designers can follow within any organization to focus the
design process on the quality of the user's experience.
How Do Software and Design Fit Together?
As the preceding sections make clear, you will not find a
simple definition of software design in the rest of this book.
Although the book initially emerged from a gathering intended
to produce such a definition, the dialog led instead to a flowering
of distinct perspectives, which expanded in unique directions
from a common core of issues. In developing those perspectives
into a book, we have worked to enrich the dialog among them.
Each chapter explores its authors' chosen concerns, in its authors'
voices. Interleaved with the chapters are brief profiles,
each describing a successful project or program that exemplifies
the book's concepts in practice.
The resulting text requires work from you. It is not digested
and homogenized into a single message that a software designer
can conveniently summarize and apply. The integration will come
as you consider how the questions that are raised here might
apply to your own concerns and activities. What is common to
all the authors is a concern for the situated nature of design—a
sensitivity to the human context in all its richness and variety.
Bringing Design
to Software