Bringing Design to Software - Introduction

Bringing Design to Software
© Addison-Wesley, 1996

Introduction - Terry Winograd

In today's computer-permeated world, it can be difficult to remember that only a few years have elapsed since the microprocessor revolution enabled the computer to move out of esoteric glass-walled isolation, to become an everyday part of work and play for millions of people. In that time, the software industry has grown from a minor adjunct of the computer (hardware) industry into a major economic sector, containing some of the largest companies in the world.

Now we are witnessing a second transformation in the role that computers and their software play in people's lives. Advances in hardware technology and in software design are changing the definition of a software product. We are moving from an era in which operating systems and shrink-wrapped word processors were representative products into a new phase, in which interactive multi-player games, information webs, smart jewelry, and personal communicators will be more typical.

In step with the accelerating movement toward transcending the conventional applications of the 1980s, a new aspect of software has moved into prominence in the 1990s—one that we can associate with the term design.

At a major software producer's meeting in 1990, Mitchell Kapor, the designer of Lotus 1-2-3, called his fellow software-company executives to task for ignoring design. He issued a challenge in the form of his Software Design Manifesto (reprinted in Chapter 1).

Kapor’s call did not fall on deaf ears. He articulated a sentiment that was already stirring, and his concerns resonated with people in the software-development community. In the few years since his manifesto, software design has been moving ahead:

It is evident that software design is coming into prominence. But that should give us a moment’s pause. Just what is software design? How does it differ from programming, software engineering, software architecture, human factors, and interface design? How is software design related to other fields that call themselves design, such as industrial design, graphic design, information design, urban design, and even fashion design? It is easy to make a new label. The real work lies in generating a change of perspective that can engender new directions and new ideas.

What Is Software Design?

The Association for Software Design (ASD) delights in revealing to prospective members that they have been engaged in software design, even though their payroll records may refer to them as software engineers, as programmers, as program managers, as human-factors consultants, or as one of many other titles. The ASD membership brochure offers a definition:

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.