Have you noticed design thinking? In recent months a spate of news reports, 60 Minutes segments, and TV news reports have told how the IDEO Company and its founder, David Kelley, have developed an innovative new approach to product design. Many social service and government organizations are now looking at IDEO's design thinking as a path to process innovation in their organizations. Practitioners trying to solve wicked problems are also finding fruit in design thinking. I would like to share some reflections on these reports.
I will review computing's long history of involvement in design. Some of our software development communities, especially those under the headings of agile, participatory, and user-centered, have been design thinkers for a long time. I will offer a note of caution about the claim of some media advocates that design thinking will speed up the processes of innovation.
Design is familiar in many fields including fashion, products, architecture, engineering, science, and software development. Design is a process where we create and shape artifacts that solve problems. In software, for example, design means crafting software that does jobs users want done. Software designers intentionally support practices, worlds, and identities of the software's users. Designers have accumulated much practical wisdom that is expressed with design principles such as separation of concerns, modularity, abstraction, layering, wholeness, utility, resiliency, beauty, and timelessness. Design principles in computing guide us to ways of building machines whose behaviors are useful and meaningful in their user communities.
Seasoned designers constantly run experiments with prototypes to learn how well the machines might work and how users might react to them. Maurice Wilkes stressed this point in his 1967 ACM Turing Lecture,5 saying that a great strength in the early days was the willingness of research groups to construct experimental computers without necessarily intending them to be prototypes for commercial production. Their experiments produced a body of knowledge about what would work and what would not work. In his 1995 memoir, Wilkes strongly criticized the more recent trend to ignore the historical development and try to design from scratch, as in the personal computer world. Without the knowledge of what worked and what did not, designers have tended to repeat the same mistakes.6 Like Fred Brooks (author of No Silver Bullet), Wilkes believed that good design is a skill set with many dimensions, well worth cultivating.
Since its beginnings in the 1940s, software has had a reputation of being extremely error prone. Programmers have always been frustrated by the amount of time they need to spend locating mistakes in their own programs, and in protecting software and data from external errors. This has not been easy given the vulnerabilities inherent in the chain of transformations that designers must master (see the accompanying figure):
When combined with the general concern for getting work done on time, these error sources have led to five traditional criteria for software design:
Despite their best efforts with tools, languages, and project management, software experts felt they could not keep up with the demands for ever-larger reliable systems. In 1968, they founded the field of software engineering to apply standard engineering methods to meet two concerns:
Within computing various schools of thought have developed around specific approaches to these concerns. These schools have advanced "process models" like waterfall or spiral, or "design approaches" such as participatory, user centered, agile, or pattern. They are all after the same thing, but they weigh the criteria in different ways. Barry Boehm argued that the standard engineering design approach of careful, almost rigid process was at the strict end of a planning spectrum and agile methods were at the flexible end.2 He thought that careful planning is needed when reliability, safety, and security are important and that agility is needed when usability and evolvability are important. He exhorted the careful planning and the agile schools to collaborate on finding a common ground for better systems.
Design thinking means to intentionally focus the design around the concerns, interests, and values of the users. The current strand of design thinking that has captured much public attention and interest originated with industrial product design in the company IDEO founded in 1991 by David Kelley in partnership with several other design firms.
In 2006, Kelley founded the Stanford Design Center, which has become an intellectual center for a design thinking movement. The IDEO philosophy emphasizes that design is a team sport with three principal values:
There is a big interest in the public sector to apply design thinking to its own problems; the standard government approach of one-size-fits-all does not work for the diverse communities agencies are trying to serve. IDEO has helped agencies improve their processes, often with excellent results that receive a lot of publicity.
Design thinking is already deeply embedded into the software pattern community.
Design thinking has also been helpful in addressing wicked problems.4 Design teams generate moods of collaboration, often leading to breakthroughs for resolving their wicked problems. When the design team brings together all the various stakeholders of a company, they are often able to win the commitments from multiple divisions of the company to see new ideas through to production. It should be noted that design thinking is not the only successful method for generating collaboration: so also do Appreciative Inquiry, Charrettes, and the Straus Method.
I am wary of the claim that design thinking speeds up innovation. Design and innovation are related, but not the same. Innovation is concerned with getting a community of people to adopt a new practice often organized around an artifact or process created by a designer. The only time design thinking might accelerate innovation is when the ideation stage has been blocked by lack of ideas or by conflicts among key stakeholders.
Master designer Don Norman puts this point differently.3 He says designers working alone have a low rate of technology adoption. Technological entrepreneurs pursue the business opportunities and work hard, often over many years, to win the commitments for adoption. Design and entrepreneurship are both needed to transform new proposals into adopted practices.
Disruptive innovations, which reconfigure entire communities, are quite rare. When they do happen, they seem spectacular. Well-designed artifacts are often cited as the causes of the innovation. But this impression seldom holds up under scrutiny. Consider the iPhone. The iPhone is partly a story of design (Steve Jobs had help from IDEO with the artifact) but it is mostly a story of entrepreneurship: Apple miniaturized components, created portable apps, put many sensors into the phone, generated a community of software app developers, cloned the Apps Store from the successful iTunes store, partnered with AT&T and later Verizon, created a new class of data plans for phones, and built a new operating systemiOSto support it all. Apple caused the innovation. The iPhone was the tip of an iceberg of practices and business arrangements that made it work.
Seasoned innovators work with a "90% rule"90% of the work in achieving an innovation goes into the adoption phase. Ideation, where design thinking produces its value, is the other 10%. But many media reports would have you believe that design thinking gets you 90% of the way to innovation. I take issue with these pundits. While a collaborative team can get things done faster, often the design team is not a collaborator with the production, marketing, PR, and community outreach divisions of a company.
Design thinking calls attention to creativity and imagination in the ideation process, emphasizing collaborative, diverse, customer sensitive design teams. It also emphasizes frequent customer feedback from prototypes that elicit their reactions. Design thinking is already deeply embedded into the software pattern community, which is part of agile software development. That community has accumulated a large set of insights into what makes for successful software design. You need look no farther than that community to see how to put design thinking to work in software development.
Computing's traditional view of design is strongly flavored by its concern for building artifacts that are error tolerant or error free. Design thinking is strongly flavored by its concern for understanding what job an artifact does for its users. If the two kinds of thinking were blended together, some significant advances in software design and development would surely follow.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.
No entries found