Book Review: Bringing Design to Software
By Gerd Waloszek, SAP AG, Product Design Center – 08/28/2003
This review takes a personal look at the book Bringing Design to Software edited by Terry Winograd.
Book
 |
Winograd, Terry (Ed.) Design: Software design, UI design |
Author
|
Winograd promotes the idea of moving the user interface design community away from computer science and searching contact with professional design communities. |
Review
Terry Winograd is the editor (co-editors) of the 1996 "landmark" book Bringing Design to Software, which "shows how to improve the practice of software design by applying lessons from other areas of design to the creation of software." Why present a book from 1996 in our book reviews of 2003? Is it because we started reviewing books on the SAP Design Guild Website this year? A better substantiation would be that the book was still prominently displayed on the book shelves at the CHI 2003 conference. In addition, attending the past CHI conferences gave me the impression that the "design perspective" is increasingly gaining momentum in the HCI community. This trend convinced me to remind the SAP Design Guild Website visitors of this book and to draw their attention to it. Although the article appears in our "review corner," I do not consider it to be a review. There is no point in rating a book that has become a long-time success and "landmark."
According to Winograd, Bringing Design to Software does not provide readers with "take-away" insights; instead, it "brings a collection of diverse perspectives to bear on the common topic of software design." As such, it is targeted at software designers, people who manage design organizations, students and researchers in human-computer interaction, professionals in other design disciplines, and last but not least the users. The book originates from a workshop on software design in 1992, in which several of the authors participated.
Overview
The main part of the book consists of 14 essays from notable authors. These essays present unique perspectives on design, be it software, hardware, or general product design. The essays begin with the famous "software design manifesto" by Mitchell Kapor, the designer of the Lotus 1-2-3 spreadsheet software. Kapor made this pledge for a software design profession back in 1990. He definitely belongs to the people who set the ball rolling for the "software design movement." Other prominent authors of essays are David Liddle (Xerox Star), John Rheinfrank (design languages), Peter Denning (action-centered design), John Seely Brown (simplicity), David Kelley, Donald Schön, and Don Norman – the latter tells the moving story of the Apple Macintosh power switch. (See the quotes section for all authors.)
Each essay starts with a short introduction to the authors, their professional background, and points of view. It is followed by a "profile" article that highlights key points in the essay; most often, specific software products are presented. Some of these examples, such as Apple Hypercard, Microsoft Bob, Kid Pix, the Mosaic Browser, or Lotus 1-2-3 may be unknown to newcomers to the field, not to mention the Xerox Alto and Star computers. This is hardly surprising considering that the book is seven years old and covers products from the world's fastest changing industry, the computer industry. The book also overlooks the more recent commercial failure of Microsoft Bob. Most introductions and profiles were written by Terry Winograd alone; some were written in cooperation with other authors.
Terry Winograd also wrote the introduction and a concluding reflection upon the book. The introduction starts with a short outline of the history of software design from its early beginnings in 1990 to the mid 1990s, when software design began to emerge as a profession. Winograd then goes on to tackle a couple of central questions, such as "What is software design?", "What is design?", and "How do software and design fit together?", in the course of which he explains terms and positions. This introduction is extremely useful beyond reading and understanding the book. In the reflection chapter at the end of the book, Winograd poses a number of questions that the essay authors tried to address. He invites the reader to apply these questions in the context of the perspectives dealt with by the book. The book closes with an outlook for the future of a software design profession.
Quotes
To wet the appetite for the book, I have picked out some quotes from the essays to give a flavor of the book. (There is some overlap with the quotes that Terry Winograd uses as introduction to the essays.) In retrospect, I found this collection of quotes very useful for my appreciation and understanding of the book.
Mitchell Kapor: A Software Design Manifesto
- Software design is not the same as user interface design. ... The software designer is concerned primarily with the overall conception of the product.
- The software designer should be the person with overall responsibility for the conception and realization of the program.
- ... the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience.
David Liddle: Design of the Conceptual Model
- Software design is the act of determining the user's experience with a piece of software. ... The designer's task is to specify completely and unambiguously the user's whole experience.
Gillian Crampton Smith & Philip Tabor: The Role of the Artist-Designer
- If interaction design is considered only at the end, software is driven by engineering design, of which users are rightly unaware, rather than by representations with which they interact.
- ..., interaction design is more of an art than a science. Its ultimate subject – human experience and subjective response – is inherently as changeable and unfathomable as the ocean.
John Rheinfrank & Shelley Evenson: Design Languages
- Design languages are the basis for how we create and interact with things in the world.
- ... consist of design elements and principles of composition.
- ... are used to design objects that express what the objects are, what they do, how they are to be used, and how they contribute to the experience.
Paul Saffo: The Consumer Spectrum
- ... the threshold of indignation (is) the maximal behavioral compromise that we are willing to make to get a task done.
- Our business culture forces on office workers relatively high thresholds of indignation.
- Individual consumers have extremely low thresholds of indignation.
Peter Denning & Pamela Dargan: Action-Centered Design
- The standard engineering process produces a fundamental blindness to the domains of action in which the customers of software systems live and work.
- The standard engineering process offers little to connect the actions of designers with the concerns of users.
- ... software engineers have not achieved success in the engineering design process. ... They have not developed a discipline of software production.
- The key to transforming software design and engineering into a customer-centered discipline is the development of a method of mapping human actions to software functions in a way that is intelligible to clients, designers, and engineers simultaneously.
John Seely Brown & Paul Duguid: Keeping it Simple
- As the distinction between program and content is becoming blurred, the distinction between software design and other forms of design is becoming harder to maintain.
- As the technology shifts, software designers will need to acquire many of the skills and intuitions of other designers.
David Kelley (Interviewee) & Bradley Hartfield (Interviewer): The Designer's Stance
- It might help to pose two caricatures – two hypothetical extremes. One is engineering as problem solving; the other is design as creating. ... The designer has a dream that goes beyond what exists, rather than fixing what exists.
- ... the designer wants to create a solution that fits in a deeper situational or social sense.
- ... design is messy. Engineering ... is not supposed to be messy. ... The designer can handle the messiness and ambiguity and is willing to trust intuition.
- Successful design is done in teams.
Donald Schön & John Bennett: Reflective Conversation with Materials
- ... there is no direct path between the designer's intention and the outcome.
- People become aware of bad design in its not working (JB). ... An object's failure or difficulty in use makes visible its insides (DS).
- In good design, access to functionality is more like the visibility of a door ... and less like the hidden aspects of a pen ...
Michael Schrage: Cultures of Prototyping
- The values that organizations hold shape the value that they create.
- Many organizations mean that manageability means predictability.
- Companies that want to build better products must learn how to build better prototypes.
- Prototypes are as much a medium for managing risks as they are a medium for exploring opportunities.
Shahaf Gal: Footholds for Design
- A significant challenge exists here for software designers. They need to create tools that assist designers to reflect on past steps, and to inform plans for the next foothold – while allowing the designers' creativity to emerge and to be tested in an unintentional way.
Donald Norman: Design as Practiced
- Design as practiced is considerably different from design as idealized in academic discussions of "good design."
- When you are asked to solve a problem, look beyond it.
- ... people work well in small groups, as as soon as the size of an organization gets large, communication problems arise. Organizations are in a continual struggle against this problem, with repeated attempts to "reorganize," as though there were a perfect structure that would somehow solve all difficulties. There isn't.
Laura De Young: Organizational Support for Software Design
- Software design is an art as well as a science. ... An organization can do much to support the (design) process and help to ensure success.
- One of the most difficult tasks for a designer is to create a successful design in the context of an organization or a project in which the participants do not know what they are trying to achieve. ... Goals are slippery and ephemeral, and are effective only when they are grounded in the reality of how they meet customer needs.
- ... people who do software design (and their managers) demonstrate an extreme reluctance to talk with customers.
- It is pointless – perhaps even damaging – to conduct usability tests merely because testing is fashionable or required by management. ... If designers do not have the time, energy, or authority to make changes, or if they are too deeply attached to their design to be willing to change it, there is no point in asking customers what they want.
- Customers frequently find ways to use products that designers never intended.
Sarah Kuhn: Design for People at Work
- Most people who encounter computer-based automation at work do not choose the software with which they work, and have comparatively little control over when and how they do what they do. For them, the use of computers can be an oppressive experience, rather than a liberating one.
- ... misunderstandings of the true context of work become embodied in computer-based systems, with negative consequences nor only for the people who do the work, but also for the productivity and efficiency that the system is intended to enhance.
- Computer-based systems that are poorly suited to how people actually work impose costs not only on the organization (in terms of low productivity) but also on the people who work with them.
Epilogue
For some time now, the trend has been to move the HCI community away from the computer science community and towards the design community – Terry Winograd is one of its proponents. I first encountered this tendency at the CHI 97 conference, where a panel discussion was held on this topic. My reservation is that, as Mitchell Kapor puts it, software design is different from user interface design and from traditional usability. Often the architecture metaphor is used, and the software designer likened to an architect. However, the professional spectrum in the HCI field has much diversified. There is no longer room for every user interface designer to become a software designer in the sense of being an architect who can significantly shape the design of a software product. I also doubt that every person working in the HCI field has the ambition of doing that.
In any instance, the book is useful to read, helps to widen ones own perspective of the HCI and design fields, and helps to understand the background, reasons, and origins of the current trend of moving the user interface community in the direction of the design community.
Notes
Coeditors of the book are John Bennett, Laura De Young, and Bradley Hartfield.
