Written any good books lately? Smashwords.com
Excerpt for Design: Creation of Artifacts in Society by Karl Ulrich, available in its entirety at Smashwords


Design: Creation of Artifacts in Society

Karl T. Ulrich

Published by the University of Pennsylvania at Smashwords.


Copyright 2005–2011 by Karl T. Ulrich


This work may be reproduced free of charge under a Creative Commons license so long as (1) the reproduced excerpt is at least one complete chapter in length, (2) full citation is made of the complete book, and (3) no charge other than the actual cost of reproduction is passed along to end users.


Smashwords Edition 1.0

PDF version formatted for viewing in Calameo on a monitor.
Other formats available at http://www.ulrichbook.org/



ISBN 978-0-9836487-0-3


Written, designed, illustrated, and photographed by Karl T. Ulrich, except where noted.


Cover Photo: Glen Mullaly (collection of spindle adapters for 45 rpm records)


DESIGN

creation of artifacts in society

Karl T. Ulrich

Contents

Preface

  1. Introduction to Design

  2. Problem Solving and Design

  3. Design Problem Definition

  4. Exploration

  5. Users, Experts, and Institutions in Design

  6. The Architecture of Artifacts

  7. Aesthetics in Design

  8. Variety

  9. Conclusion

Acknowledgments

About the Author

Colophon




Preface

As a freshman entering MIT I intended to be a physician, but early in my first year I made new friends who were taking mechanical design courses. They were always carrying around bags of interesting components and displaying metal parts they had made in the machine shop. I was bitten early by the design bug and took all the courses I could on the subject. My identity as designer was solidified in 1979 as a winner of the MIT “2.70” design contest (now 2.007), an outcome that gave me near celebrity status in the hacker-designer crowd at MIT. I was fortunate to have as professors Ernesto Blanco, Woodie Flowers, David Jansson, Warren Seering, and others who were deeply committed to design education.

Karl Ulrich, age 19, winning the MIT “2.70” design contest. Source: MIT.

I did my doctoral work in the MIT Artificial Intelligence Lab, focusing on fundamentals of design theory and machine learning, and developed a whole new perspective on problem solving and design from Randy Davis, Marvin Minsky, Patrick Winston, and many other really interesting students and faculty in that lab. The AI Lab also had the best shop on campus, so after hours I designed and built cool stuff like a recumbent bicycle.

In the 25 years since I was a student at MIT, I’ve been lucky to lead a professional life that blends teaching design, doing design, and researching design, a luxury afforded by the culture of the Wharton School and the University of Pennsylvania.

My roots are in engineering design, and much of my professional life has been centered on product design. However, in the past 15 years, stints as an entrepreneur and a university administrator have broadened my conception of design to include the creation of services, businesses, and organizations. I intend for this book to be a synthesis of what I know about design based on the varied perspectives of teacher, researcher, and practicing designer.

Narberth
Pennsylvania
United States


Chapter 1

Introduction to Design

Here are some of the human activities characterized as design:







The word design presents definitional challenges. Designers tend to view their own particular sphere of activity as the universe of the human activity of designing. For example, one of the twelve schools at the University of Pennsylvania is the School of Design. The school does comprise two clearly recognizable design activities—architecture and urban design—but also fine arts and historic preservation. At the same time, the trade journal Design News, with a subscription base of 170,000, focuses quite narrowly on engineering design, a domain not included in Penn’s School of Design. I can’t think of another human endeavor with such confusing intellectual jurisdictions.

Part of the problem is the English language. What we call design in English goes by several different words in other languages. For example, in German the words konstruktion, bauart, entwurf, planung, and design all refer to different activities that we call simply “design” in English. (See the appendix to this chapter for an overview of the etymology of the word and synonyms in other languages.)

Fortunately, at the level at which I treat design in this book, the activity of design is fundamentally similar across a wide variety of domains.

Design is conceiving and giving form to artifacts that solve problems.1

I use artifact in a broad and atypical sense to describe any product of intentional creation, including physical goods, services, software, graphics, buildings, landscapes, organizations, and processes. These artifacts can be categorized into domains, within which specialization of design methods can be useful.

Exhibits 1-1 through 1-8 are some examples of artifacts in different domains, all designed.2 Each artifact was conceived and given form to solve a problem. The form for artifacts need not be geometric. For example, the computer program in Exhibit 1-1 takes the form of a nested list of symbols. The problem need not be a pressing societal need, but rather any perceived gap in a situation or experience. For example, the Insalata Caprese is a wonderful artifact, but hardly addresses a problem in the deepest sense of the word.

Exhibit 1-1. A computer program to find the smallest divisor of an integer N, written in Scheme, a dialect of the programming language LISP. Source: Abelson and Sussman, 1996.


Exhibit 1-2. Insalata Caprese, allegedly originally from the island of Capri in the Campania region of Italy.

Exhibit 1-3. Connecting rods for an automotive engine. Source: LN Engineering.

Exhibit 1-4. The logo for Xootr brand scooters. Source: Lunar Design.

Exhibit 1-5. A glass staircase for the Apple Store in Osaka, Japan. Source: Koji Okumura




Exhibit 1-6. The Sony Cyber-shot digital camera. Source: Sony Corporation.



Exhibit 1-7. The Eclipse jet. Source: Eclipse Aviation.


Exhibit 1-8. Fisher Fine Arts library at the University of Pennsylvania. Designed by Frank Furness and completed in 1890. Source: Wikipedia.

Unifying Framework

From code to cameras and logos to libraries, design domains are highly diverse, and the tools and methods used by designers in these domains can be highly specialized. However, the activity of design across all domains can be usefully unified by a single framework.

I adopt an information processing view of design, largely consistent with that articulated by Herbert Simon in the 1960s (1996). From this perspective, design is part of a human problem-solving activity beginning with a perception of a gap in a user experience, leading to a plan for a new artifact, and resulting in the production of that artifact (Exhibit 1-9).3 This problem-solving process includes both design and production of the artifact. Design transforms a gap into a plan, which might, for instance, be represented with drawings, computer models, recipes, or parameter values. Production transforms a plan into an artifact.

Note that the same word design is used in English as both noun and verb. The noun form may refer to both the activity of designing (e.g., Sammy is responsible for design of the Alpha 2000) and the plan that results from that activity (e.g., Sammy completed the design of the Alpha 2000).

Exhibit 1-9. Design and production are the two activities that deliver artifacts to address gaps in the user experience.

In my model, the user is positioned at the start of the design process. The word user, while awkward, is a term of art in professional practice. Equally ugly synonyms include customer, client, stakeholder, and consumer. We can’t even reliably substitute the term human, as users can be animals or aliens. (Instances of design for aliens are exceptional, of course, but consider that NASA’s two Voyager spacecraft carry with them “golden records” designed in part for extraterrestrial users.)

Exhibit 1-10 further decomposes the design portion of the model into four steps. This is a codification of a process that may be implicit for many designers, yet these elements can be discerned in some form in most design efforts:

  • Sense gap. Design begins with a perception of a gap in the user experience. Without a gap, there is no motive for design. The gap may be perceived by users themselves or by observers.

  • Define problem. In effect, problem definition is the creation by the designer of an explanation of why the user experiences a gap. This diagnosis can be thought of as an identification of user needs that are not being met in the current state and/or the recognition of criteria for a high-quality solution. Problem definition is implicit in many design efforts, particularly when users are themselves designers, but is generally an explicit part of professional design efforts, expressed in the form of a design brief, customer needs list, or other document. Chapter 3 focuses on problem definition.

  • Explore alternatives. Given a problem, designers almost always explore alternatives. (This step is sometimes called search.) I devote Chapter 4 to exploration.

  • Select plan. Exploration typically exposes more than one solution, so design requires some sort of evaluation and selection from among alternatives. Some designers consider many alternatives simultaneously when selecting a plan. Others articulate, evaluate, and refine plans iteratively and select the first plan that is good enough.

Exhibit 1-10 shows design as proceeding from left to right, from gap to plan. While this general flow is typical, the steps are rarely completed in a strict sequence. Exhibit 1-11 reflects the coding of a particular episode of design into three categories (roughly corresponding to my steps defining, exploring, and selecting) as a function of time (Günther 1996). In this instance, the designers jumped back and forth considerably among activities of the three types.

Exhibit 1-10. Design can be thought of as four information processing steps.

Exhibit 1-11. Actual allocation of design team time to three categories. Source: Günther 1996.

In addition to the iteration occurring among steps, the overall design process is typically executed multiple times, as the first artifact produced rarely results in a complete closing of the gap in the user experience. This iteration may occur across different time scales, ranging from high-frequency iterations by a single individual, perhaps over minutes or hours, to low-frequency iterations over multiple generations of artifacts within an entire society. For example, Rybczynski (2000) provides a detailed chronicle of the evolution of the screw and screwdriver as many iterations of problem solving over hundreds of years.

In the model I present here, design proceeds from gap to plan to artifact. In modern enterprises, the order is sometimes reversed. The designer sometimes begins with an artifact and searches for a gap that it might fill. For instance, DuPont discovered the compound polytetrafluoroethylene (i.e., Teflon) accidentally and then proceeded over many decades to find gaps that the artifact could address. This approach is typical of endeavors for which effective exploration methods are lacking—for example, pharmaceuticals and basic materials. The reverse sequence of design steps is sometimes called technology push because it begins with a solution rather than with a gap.4

What Is Good Design?

Design is difficult in that it absorbs substantial cognitive effort, typically requires multiple iterations, and rarely results in an optimal artifact, even in situations for which the notion of optimality can be defined. The few design domains that have been described by formal mathematical languages are, in the nomenclature of computational complexity, NP-complete search problems, meaning that the theoretically optimal solution cannot reliably be found.5 Most design domains have not even been formalized, making the inherent complexity even greater and the prospect of optimality even more distant. However, users can generally still evaluate the quality of the outcome of the design process, and different artifacts designed to address the same gap can certainly exhibit markedly different levels of quality.

Design quality is derived from how well the artifact satisfies user needs, and thereby closes the perceptual gap in the user experience. The quality of an artifact is linked to at least these characteristics of the design process:

  • How well did the designer diagnose the gap in the user experience? Is the problem as understood by the designer consistent with the causes of the gap experienced by the user? In simple terms, did the designer understand the problem?

  • Has the scope for exploration been defined in a way that the space of possibilities includes high-quality solutions? In the nomenclature of cognitive psychology, has the design problem been framed in a way that allows for the discovery of high-quality solutions?

  • Did the designer succeed in finding high-quality designs within the solution space that has been defined? Often this result depends on both the skill and knowledge of the designer and on the ease and accuracy with which the designer can forecast the quality of a design without actually having to produce it.

Of course, although not an attribute of the design process per se, the fidelity of production of the plan is also a determinant of user satisfaction.

In sum, did the designer understand the problem, frame it in a way that exploration could potentially lead to a good solution, find such a solution within the solution space, and deliver an artifact consistent with the plan?

Another way of thinking about design quality is to identify defects that can arise in the design process. For each element of the process, there is at least one potential defect: The designer may fail to accurately diagnose the gap in the user experience. The designer may frame the exploration problem in a way that excludes many high-quality designs. The designer may only be able to explore a limited portion of the solution space, finding only a few relatively lower-quality solutions. The artifact produced may not be an accurate embodiment of the plan.

Design Is Everything?

The marketing consultant Regis McKenna wrote a famous article in Harvard Business Review entitled “Marketing Is Everything” (1991). I know several designers whose blood boiled in response to this title. A common refrain among designers is that indeed design is everything (and certainly subsumes marketing). I’m sympathetic to this view, having observed a lot of dysfunctional managerial and political processes that would have been substantially improved by posing a challenge as a design problem and then applying the basic design process. (How often have you participated in a group effort for which no one had clearly articulated the problem, explored alternatives, or carefully selected a plan from the alternatives?)

However, a lot of human problem solving is not really design. The interactive, incremental, ongoing development and refinement of abilities that occurs between a coach and a performer doesn’t quite strike me as design. Trading of financial instruments on Wall Street does not involve much of what I think of as design. Construction of a building to faithfully execute a plan, even with the application of remarkable skill and craft, is hardly design.

The next chapter takes on directly the question of how design relates to human problem solving more generally. For now, let me just state that I believe that much of human problem solving would benefit from more design process, not less; however, I don’t believe that “design thinking” addresses all challenges we face as individuals, managers, politicians, organizations, and institutions.

This Book

The central theme of this book is that a unifying framework informs the human activity of design across all domains. With few exceptions, each idea in this book applies to graphics, environments, products, software, services, machines, and buildings. I dream that the design process could be integral to the primary, secondary, and postsecondary education of all individuals in modern society. This book is an attempt to lay out some of the ideas that would form that education.

Earlier I alluded to the Nobel Prize–winning economist Herbert Simon and his information processing view of design. Simon was brilliant, and his book Sciences of the Artificial contains some beautiful ideas about design. In some ways it was the first serious intellectual treatment of design as a problem-solving activity across domains. But, despite all his merits, Simon didn’t connect theory tightly to the practice of creating real artifacts. With this book I aim to marry deep concepts to the way real artifacts are created in society. I also hope to cover some of the big ideas that have been developed in the fifty years since Simon wrote about design.

This is a book about ideas. It is not a handbook for doing design. I am writing for three audiences. First, I am writing for designers with an interest in ideas about the design process. This isn’t a huge population. I have spent my whole professional life working with the nuts and bolts of design, and I know that few designers have much patience for ideas like those in this book. One of the reasons they became designers was to do design, not think about design. Second, I am writing for those who do not think of themselves as professional designers, but who have an intellectual interest in design. This is a bigger group than the first, but clearly still not a mass audience. Third, this book is intended for university students and their instructors. There are very few design courses that are part of what might be considered general education in universities. This is unfortunate. However, there are a lot of courses on design or related to design in which one or more of the chapters in this book will be useful. For example, I use the chapters on aesthetics and variety in my product design course, which is intended to develop professional skills in those who want to design products.

This book assumes no specific disciplinary training. Economic principles are typically defined and any engineering concepts used are explained. The mathematics, though scarce, is basic. However, there is certainly an underlying tone to the book that arises from my own training and worldview as a structured thinker with education in engineering and computer science.

The book has eight more chapters:

  1. Problem Solving and Design

  2. Design Problem Definition

  3. Exploration

  4. Users, Experts, and Institutions in Design

  5. The Architecture of Artifacts

  6. Aesthetics in Design

  7. Variety

  8. Conclusion

Not all issues related to design are included here. For example, I don’t write much about organizations, within which most real design gets done. I may address this and other topics in future editions. I believe good designers have a bias for action and learn through iteration. I created this book in that spirit.

Notes

1 This definition draws on those proposed by at least two others. Edgar Kaufmann Jr., curator of the industrial design department at MOMA 1946–1948, wrote that “design is conceiving and giving form to objects used in everyday life” (Kaufmann 1970). Klaus Krippendorf and Reinhart Butter (1984) wrote, “Design is the conscious creation of forms to serve human needs.”

2 See the three-volume set Phaidon Design Classics for 999 “industrially manufactured objects of aesthetic value and timeless quality” (2006). Although they assume a more limited definition of design than I adopt in this book, the Phaidon Classics are nevertheless a fascinating collection of artifacts.

3 Terwiesch (2007) provides a comprehensive discussion of product development as problem solving. Product development is a specific economic activity that includes design tasks.

4 See Terwiesch and Ulrich (2009) for a more comprehensive treatment of various modes of innovation in industrial practice.

5 NP means that the time required for an agent to find a solution increases with the size of the problem according to a relationship that is not polynomial (e.g., exponential, factorial, etc.). In other words, the problem “explodes” in magnitude in a way that finding a truly optimal solution is impossible in a reasonable amount of time, even with very fast computing.

References

Abelson, H., and Gerald Jay Sussman. 1996. Structure and Interpretation of Computer Programs. Cambridge, MA: MIT Press.

Günther, J., E. Frankenberger, and P. Auer. 1996. “Investigation of Individual and Team Design Processes in Mechanical Engineering.” In Analysing Design Activity, eds. N. Cross et al. Chichester, UK: John Wiley and Sons Ltd.

Kaufmann, Edgar. 1970. Introductions to Modern Design: What Is Modern Design & What Is Modern Interior Design. New York: Museum of Modern Art Publications in Reprint.

Krippendorff, K., and Reinhart Butter. 1984. “Product Semantics: Exploring the Symbolic Qualities of Form.” Innovation 3 (Spring): 4–9.

McKenna, Regis. 1991. “Marketing Is Everything.” Harvard Business Review 69 (1): 65–79.

Phaidon Design Classics. 2006. Vols. 1–3. London: Phaidon Press.

Rybczynski, Witold. 2000. One Good Turn: A Natural History of the Screwdriver and the Screw. New York: Scribner.

Simon, Herbert A. 1996. The Sciences of the Artificial. Cambridge: MIT Press.

Simpson, John, and Edmund Weiner, eds. 1989. The Oxford English Dictionary. New York: Oxford University Press.

Terwiesch, Christian. 2007. “Product Development as a Problem-solving Process.” In Blackwell Handbook on Technology and Innovation Management, ed. Scott Shane, 143–172. New York: Wiley-Blackwell.

Terwiesch, Christian, and K. T. Ulrich. 2009. Innovation Tournaments: Creating and Selecting Exceptional Opportunities. Boston, MA: Harvard Business Press.

Appendix: The Word Design

The word design comes to English via French from the Latin root signum and means literally to mark out. It was first used in English in the sense I use it in this book in the seventeenth century (OED 1989). By now, the word has assumed many meanings and covers a lot of territory in the English language. Exhibit 1-12 shows the words in several other languages that are used similarly to the way design is used in English. German has perhaps the most different terms for more precisely characterizing the different notions of design. Many of these words come from Latin roots, which are probably recognizable to most readers. Interestingly, the English word design is popular in other languages and has been adopted either exactly or phonetically (e.g., dezain in Japanese). In some of these languages, a word similar to design derived more directly from Latin and/or French has a different meaning. For example, in Italian, disegnare has the very narrow meaning “to draw,” and either the English word design or the word progettazione (verb progettare) is used to refer to the activity of design; in French, the word désigner means to designate, not to design, and either design, dessein, or conception is used.

Exhibit 1-12. Words in several other languages used in a way similar to the English word design. The most similar terms are outlined with boxes.

Chapter 2

Problem Solving and Design

Benjamin Franklin was an irrepressible problem solver, tackling challenges as diverse as fire prevention, higher education, and home heating. Yet I don’t think of him as first and foremost a designer, perhaps because of some significant differences between problem solving and design. This chapter attempts to disentangle the real and perceived differences between design and problem solving and to elucidate both barriers and opportunities for the application of “design thinking” to problem solving more generally.

Exhibit 2-1 is a photograph of a pair of bifocals from Benjamin Franklin’s time. Franklin is widely credited with the invention of bifocals, although there is some controversy about this attribution. In a letter to George Whatley in 1785 (Exhibit 2-2), he explains the difficulty of seeing both the food on his plate in front of him and the faces of his guests at the end of the table. He describes a way to address this difficulty by combining lenses in the now familiar bifocal configuration.

Exhibit 2-1. A pair of “Franklin-type” bifocals from the late eighteenth century. Source: The College of Optometrists (British Optical Association Museum), London.

Franklin’s narrative (provided in the appendix) follows the design process I described in Chapter 1 and that is articulated in Exhibit 2-3. Franklin sensed a gap (vision out of focus), defined a problem (objects at different distances require different optical correction), searched for a solution, and then selected a plan (a lens formed from two halves, each with a different diopter).

Exhibit 2-2. Letter to George Whatley from Benjamin Franklin describing the creation of bifocals to address the problem of vision correction for both near and far distances. The text of a portion of this letter is in the appendix. Source: United States Library of Congress.

This process is almost exactly the way I describe problem solving in a course I teach on the subject. Exhibit 2-4 shows how I articulate the problem-solving process to my students. An agent operating in the world senses a gap between the current state and some desired state. The agent then defines a problem or problems, generates alternative solutions, selects an approach, and finally takes action by implementing the solution. In most cases the problem solver then assesses whether the gap has indeed been closed and, if not, the problem-solving process may be repeated iteratively.1 This problem-solving process is almost exactly the design process in Exhibit 2-3. There is one conceptual difference and several practical distinctions. The conceptual difference between design and problem solving is the difference between plans and outcomes. The design process results in a plan for action, but not necessarily in a realization of that plan. One nice aspect of the way problem solving is typically taught and practiced is the relative emphasis on action, learning from that action, and improving on the initial solution as a result of that learning. Of course, many good designers are also complete problem solvers, remaining engaged in their challenges through the implementation, testing, and refinement of the artifacts they design. Because problem solving essentially includes the steps in the design process, problem solving is the more general human activity of which design is a critical element.

There are other practical distinctions, though, beyond that of implementation and action. They derive from the relative emphasis of design on the creation of new artifacts and from the relative importance of time in some problem-solving challenges. These and other distinctions are clarified by a taxonomy of problem types, which includes design problems.

Taxonomy of Problems

While pretty much all problem solving can be thought of as a process by which a gap in an agent’s experience is closed, a taxonomy of problem types allows us to tighten the distinction between design problems and other types of problems. The categories in the taxonomy and their relationships are illustrated in Exhibit 2-5. The first distinction in the taxonomy is between problems for which there is an existing artifact or operating system and those for which there is no such artifact. This distinction separates all problems into two broad categories: design problems and system improvement problems. The other categories map either across or within these two divisions.


Exhibit 2-3. Design and production address gaps in the user experience. The design process can be thought of as four steps.

Exhibit 2-4. A generic problem-solving process. Problem solving addresses a gap between the state of the world and a desired state from the perspective of an agent.

Exhibit 2-5. Six types of problems, one of which is design problems.

Design problems

The bulk of the book focuses on design problems. The hallmark of design problems is that the designer creates a plan for a new artifact in response to a gap. A central feature of design problem solving is the exploration of alternatives.

Selection problems

Selection problems are a subset of design problems in which the alternatives are already well articulated or relatively easy to discover. The central challenge is to select from among those clearly articulated alternatives. For example, when a firm needs to install a new accounting system, the problem solver can typically readily identify the available alternatives. These alternatives are the systems available on the market, as the firm would rarely create its own accounting system from scratch. The challenge is evaluating the alternatives and then selecting one. I include selection problems within the larger category of design problems because even with the most straightforward selection problems, the problem solver does have to at least articulate the alternatives, which is a form of exploration.

System improvement problems

Unlike design problems, system improvement problems concern modifications to existing artifacts or systems. The problem-solving process for system improvement problems typically involves the comparison of existing performance with some notion of ideal performance. Then, the problem solver focuses on exploring alternative approaches to improving performance. For example, the admissions process for business schools is a tricky undertaking requiring high levels of efficiency, fairness, and predictive accuracy. Most schools are continually attempting to improve the performance of the system. While creating an admissions process from scratch is clearly a design problem, improving an existing admissions process is qualitatively different. Some elements of difference, for example, are that improvement tends to comprise several incremental changes, often applied sequentially; the focus of problem solving is often defect reduction, which has a forensic quality to it; and system improvement typically benefits from a wealth of data from the existing system. None of these attributes is typical of design problems.

Tuning problems

A particular flavor of system improvement problems is tuning problems. Tuning problems are limited to incremental adjustments to parameters of an existing artifact. For example, consider the process for making plywood. A log is positioned on a machine (essentially a large lathe) that spins the log while a wide blade peels off a 2.5-meter-wide ribbon of wood veneer. That ribbon is subsequently cut into rectangular pieces, stacked into a sandwich with glue between the layers, and then squeezed in a heated press to cure the adhesive. Like most manufacturers, plywood makers are continually engaged in system improvement problems. One such problem is the tuning problem associated with the veneer-making process. The process parameters include, among others, rotational speed, blade shape, cutting angle, cutting pressure, and log moisture content. There are of course infinite possible combinations of these variables. The tuning problem is to find the combination that both achieves the best performance (wood utilization, consistency, surface finish, etc.) and delivers consistent results under varying conditions. A variety of methods have been developed for solving tuning problems. See particularly “optimal design” methods, which are appropriate in cases where mathematical models of the artifact exist (Papalambros and Wilde 2000) and experimental methods, which are appropriate for cases where analytical models are elusive (Ulrich and Eppinger 2011).

Crises

A crisis is simply a problem that must be solved quickly. In economic terms, the opportunity cost of time is very high for crises (e.g., a patient is bleeding, a company is failing, coal miners are trapped, public opinion is forming in the wake of an event). Crises can be design problems or system improvement problems. For example, when the crew of Apollo 13 said, “Houston, we have a problem,”2 everyone soon knew that the problem had to be addressed quickly or the astronauts would die. The Apollo 13 crisis comprised, among others, a design problem—how to create an air filter from available materials (Exhibit 2-6)—as well as a system improvement problem—how to minimize the electrical current draw from the systems in the aircraft.

Wicked problems

Rittel and Webber (1973) defined a class of problems as wicked, kind of a catch-all term for problems that are extraordinarily hard to solve, and for which even clear definition is difficult. I like the term wicked problem, but have never felt it was defined with adequate precision. Here I use the term to refer to problems for which stakeholder objectives are fundamentally in conflict. Examples of such problems include territorial disputes in and around Jerusalem, global warming, public school reform, and terrorism. Like crises, wicked problems can be either design problems or system improvement problems.

Deliberate Process, Importance, and Time

My view of problem solving and design is process oriented. My students often ask whether a deliberate process is always the best way to solve a problem.

I know of only two studies that have looked at the question of effectiveness of structured problem solving processes. Griffin (1997) studied the effectiveness of structured product development processes, a fairly close cousin of design processes (Terwiesch 2007). She found that firms that adopted structured development processes completed complex projects more quickly than those that did not.

Tyre and colleagues (1993) studied the effectiveness of structured problem-solving processes in addressing manufacturing problems at the Saturn division of General Motors. They found that the use of structured problem-solving processes (essentially the process articulated in Exhibit 2-4) was associated with both better solutions and faster completion.

This limited scientific evidence is consistent with my beliefs based on experience. At a minimum, structured processes act as checklists to ensure that no critical information processing task is omitted.


Exhibit 2-6. The air filter designed and built by the Apollo 13 crew from available materials when faced with a crisis. Source: NASA.

The question of whether a deliberate process is always warranted can be illuminated with some conceptual thinking. Exhibit 2-7 lays out two relevant dimensions. First, how important is getting the right solution? Second, how urgent is the problem? These two dimensions can be thought of in economic terms for the sake of relative quantitative comparisons. The first (horizontal) dimension can be thought of as the economic value of getting a near-optimal solution compared to the value of getting a typical solution.3 For example, in branding a video recording and storage product, how much is the name TiVo worth compared to Replay? (My answer on that one is “millions.”) Compare this to the value of figuring out exactly what to eat for breakfast one morning. (It’s worth something to me, but not much.)

Exhibit 2-7. The use of deliberate process depends on the opportunity cost of time and the relative value of achieving the optimal outcome.

The second (vertical) dimension represents the opportunity cost of time. What is the cost of not having a solution? We can think about this in terms of cost per hour. For example, when formulating a solution for how to turn around a troubled company, one can think about the negative cash flow to be averted by that plan, which might be a million dollars per day (i.e., tens of thousands per hour).

The relative position of a problem on these two dimensions informs the question of whether to apply a deliberate problem-solving process, and if so, what type. For problems for which the value of an excellent solution is worth not much more than that of an average solution, there isn’t much point to investing in problem solving, and so problem solvers may resort to just picking default solutions or to automated problem-solving techniques based on simple heuristics.

In the upper right portion of the exhibit, an excellent solution is valuable and time is extraordinarily precious. Examples of such settings would be action sports like soccer or hockey, or at the extreme, life-or-death military engagement, such as dogfighting between aircraft. In these settings, there is not time for even the most streamlined deliberate problem solving. Action must be reflexive and instantaneous. Humans cope with such situations only with extreme levels of skill, specialization, and practice, and they perform well only within a narrow range of problem types.

In the middle right portion of the exhibit, outcomes are still quite valuable, but time is a little less costly. Even in a life-or-death setting like a rescue in a collapsed coal mine, the problem solver has hours to deal with the crisis, not seconds. Some use of problem-solving process is warranted (e.g., the exploration of alternatives), but typically the problem solver will deploy a great deal of resources, perhaps pursuing several potentially redundant solutions at once. Typically, problem solvers responsible for addressing crises are deeply experienced, and so do not need to learn and adapt their problem-solving methods as they go.

Most of us spend most of our professional lives in the lower right portion of the exhibit. Problems are important, with the best solutions typically worth thousands or millions of dollars more than average solutions. And problems typically are not so urgent as to prevent us from devoting days, weeks, or months to their solution. We plan events. We brand products. We form new ventures. We design buildings. We staff organizations. For these problems, deliberate process is warranted. There is no reason not to carefully define the problem, explore alternatives, evaluate and select from the alternatives, and iteratively refine a solution.

Why the resistance to structured processes?

If a deliberate problem-solving process is warranted for a large fraction of the problems we face as professionals, why do humans so resist such processes? This resistance ranges from passive neglect to active loathing. I believe there are at least three reasons for the resistance. First, the application of structured processes is hard work, and most of us resist hard work when possible. Second, problem solvers rarely observe how well they might have done with the application of a structured process. That is, the opportunity cost of not applying a structured process is rarely obvious, and so the impetus for applying a process may not be well understood. The third reason is largely a conjecture on my part, but is interesting to think about.

I believe that for most of our evolutionary past, humans benefited from a bias for action. When faced with a decision of whether to flee or fight in the face of an enemy, those who reflected carefully on the problem and explored alternatives did not survive long enough to reproduce. This is an oversimplification, of course. One of the hallmarks of human behavior, going back tens of thousands of years, is that we use our brains to plan for the future. However, until the most recent few thousand years, this planning applied to small groups of people, perhaps over a time period of just one season. We were not prepared biologically for managerial life in a mass society. Today, we often make decisions as professionals that matter to thousands of people over time scales of many years. When faced with such decisions, deliberate processes are fully warranted, and yet our biological impulse may be to just act.

Design and Innovation

I wrote the bulk of this book at the same time I was coauthoring a book on innovation (Terwiesch and Ulrich 2009). Because of this confluence of activities, I was forced to reflect on the similarities and differences between design and innovation. Design and innovation are quite similar endeavors, but there are at least three distinctions.

First, innovation is typically broader in scope than design, and includes the entire set of activities that create a new match between a solution and a need. Design is often one of these activities, but so are market launch, the ramp-up of operations, and the management of regulatory issues.

Second, and related closely to the first distinction, innovation is often thought of as an economic activity whose basic unit of analysis is the innovation system, whereas design is an activity typically thought of at the level of a particular artifact or project. This is a tendency in practice more than a theoretical distinction. General managers in firms and other institutions worry about their innovation “pipelines” or “systems.” When viewed as a system, innovation includes the more focused activity of design.

Third, design usually proceeds from the identification of a gap to the creation of a solution. Innovation can frequently proceed in the other direction, an approach sometimes called technology push. With technology push, an innovator begins with a new or existing solution and then searches for possible applications of that solution. This approach is typical of the pharmaceutical innovation process, in which a newly discovered chemical compound is screened for possible medically useful properties. Technology push also occurs frequently in innovation involving basic materials.

The Culture of Designers

Designers share some elements of common culture, even though diverse design domains typically possess idiosyncratic subcultures. Design culture sometimes clashes with, for example, the cultures of politicians, lawyers, and some managers. As I reflect on the unique aspects of design culture, I identify three key elements.

Optimism versus criticism

Designers are optimistic. They are accustomed to facing problems and solving them. This optimism contrasts with the culture of criticism one often finds in some other professions. For example, lawyers are trained to imagine the worst possible outcomes and protect against them. Designers are trained to imagine the best possible outcome that one might be able to create with a novel artifact. It is no surprise that these two groups of professionals often find themselves in a clash of cultures.

Prototyping and iteration

Good designers tend to have a bias for building, trying, and refining artifacts, rather than perfectly refining a theoretical plan. The design culture is one of prototyping and testing as much as it is one of conceptual exploration. This bias makes sense when faced with a high level of uncertainty and a lack of theory, as is often the case for design problems. The bias for action can be detrimental for problems in which data and analysis are powerful tools for finding solutions, as is the case for some problems in engineering and management.

Elegance

Designers tend to strive for elegance. It bothers most designers to create something sloppy even if it works. While elegance is an ill-defined concept, I think it tends to comprise originality, beauty, surprise, and an efficient use of resources. Many have tried to articulate what makes for good design. One effort I like is by Paul Graham (2004), a software entrepreneur, who argues that good design is, among other things, daring, timeless, slightly funny, and hard (but looks easy).

Nontraditional Design

This book is mostly focused on designed physical objects, although in Chapter 1 I offered a more general view of design and a more general notion of artifacts. I believe that most of the ideas in this book apply to the design of organizations, social systems, business models, and services as well as they do to the design of physical goods.

For example, consider the design of a business model. Exhibit 2-8 includes a template for essentially any business (Panel A). The template includes a customer acquisition process and a solution delivery process. An infinite number of possible business models can be created through exploration of the various alternatives for the elements of this generic model. For example, NetJets is a company that pioneered the commercialization of fractional jet ownership. Panel B in the exhibit shows the instantiation of the template with the key elements of the NetJets model. Panel C is a potential new business model that is an incremental perturbation of the existing NetJets model.

I believe that a structured process of exploration can be applied to the creation of new business models like that of NetJets as well as to the exploration of alternative models. This process is essentially similar to the way many effective designers explore alternatives for the design of physical objects and systems. Although most good designers of physical goods exhibit great discipline in exploring many alternatives, this discipline seems less well developed in the creation of businesses. In a course I teach in the MBA program at Wharton, I have tried to develop design thinking among business students faced with nontraditional design problems, and I believe this effort has been largely successful. An even further extension of design thinking to the creation of social systems and government policies seems quite promising.

Concluding Remarks

There is a lot of human problem solving that is not really design. However, I believe that much of human problem solving would benefit from more design process, not less. The hallmark of design is an exploration of alternatives and careful selection from among those alternatives, an approach that tends to make for good problem solving. I would also like to see greater diffusion of the culture of design, one of optimism, elegance, and a bias for action.

Exhibit 2-8. Design applied to business models.

Notes

1 Karl Popper (1999) argued that “all life is problem solving” and that the basic elements of all problem solving are (1) recognizing the problem, (2) attempting alternative solutions, and (3) eliminating approaches that do not work.

2 This quote isn’t quite right. Astronaut James Lovell actually said, “Houston, we’ve had a problem,” but the present tense sounds better.

3 The notion of optimality is a bit loose here because most problems cannot be formalized in a way that optimality can really be defined. One way to think about the definition of the value of a near-optimal solution is to think about the probability distribution over the quality of solutions for a given problem. One might think of the horizontal axis in Exhibit 2-7 as the value of the standard deviation of this distribution.

References

Graham, Paul. 2004. “Taste for Makers.” In Hackers and Painters: Big Ideas from the Computer Age, 130–145. Sebastopol, CA: O’Reilly Media. http://www.paulgraham.com/taste.html.

Griffin, Abbie. 1997. “The Effect of Project and Process Characteristics on Product Development Cycle Time.” Journal of Marketing Research 34 (1): 24–35.

Papalambros, Panos Y., and Douglass J. Wilde. 2000. Principles of Optimal Design: Modeling and Computation. Cambridge: Cambridge University Press.

Popper, Karl. 1999. All Life Is Problem Solving. London: Routledge.

Rittel, H., and M. Webber. 1973. “Dilemmas in a General Theory of Planning.” Policy Sciences 4: 155–169.

Terwiesch, Christian. 2007. “Product Development as a Problem-solving Process.” In Blackwell Handbook on Technology and Innovation Management, ed. Scott Shane, 143–172. New York: Wiley-Blackwell.

Terwiesch, Christian, and K. T. Ulrich. 2009. Innovation Tournaments: Creating and Selecting Exceptional Opportunities. Boston, MA: Harvard Business Press.

Tyre, M. J., S. D. Eppinger, and Eva M. H. Csizinszky. 1993. “Systematic Versus Intuitive Problem Solving on the Shop Floor: Does It Matter?” Working Paper 3716, MIT Leaders for Manufacturing Program, July.

Ulrich, K. T., and Steven D. Eppinger. 2011. Product Design and Development. New York: Irwin/McGraw-Hill.

Appendix

Following is an excerpt from Benjamin Franklin’s letter to George Whatley dated May 23, 1785. Whatley was a philanthropist and close friend of Franklin’s.

By Mr. Dollond’s saying, that my double Spectacles can only serve particular Eyes, I doubt he has not been rightly informed of their Construction. I imagine it will be found pretty generally true, that the same Convexity of Glass, through which a Man sees clearest and best at the Distance proper for Reading, is not the best for greater Distances. I therefore had formerly two Pair of Spectacles, which I shifted occasionally, as in travelling I sometimes read, and often wanted to regard the Prospects. Finding this Change troublesome, and not always sufficiently ready, I had the Glasses cut, and half of each kind associated in the same Circle, thus, [Franklin’s sketch follows].

By this means, as I wear my Spectacles constantly, I have only to move my Eyes up or down, as I want to see distinctly far or near, the proper Glasses being always ready. This I find more particularly convenient since my being in France, the Glasses that serve me best at Table to see what I eat, not being the best to see the Faces of those on the other Side of the Table who speak to me; and when one’s Ears are not well accustomed to the Sounds of a Language, a Sight of the Movements in the Features of him that speaks helps to explain; so that I understand French better by the help of my Spectacles.


Chapter 3

Design Problem Definition

As I explained in the preceding chapters, I decompose the activity of design into four steps. This chapter focuses on problem definition and Chapter 4 focuses on exploration, the two middle steps, shown again in Exhibit 3-1.1

Exhibit 3-1. The design process can be thought of as four steps.

In a confusing mix of terminology, designers in different domains use different labels for problem definition. In architecture, problem definition is called programming (Duerk 1993). In industrial design it is research. In product design, problem definition is termed identifying customer needs. In engineering design, it is called establishing specifications.

Fundamentally, defining the problem is an articulation of what the designer sets out to accomplish, what gap the designer is attempting to close. The problem definition is the what but not the how. Conceptually, the definition of a design problem can be thought of as comprising two elements: (1) the basic function of the artifact and (2) the desirable qualities of an artifact that performs that function. For instance, Exhibit 3-2 is a new wood-fueled stove for use in developing regions of the world. The basic function of the artifact is to provide heat for cooking. The desirable qualities of the artifact include minimizing wood consumption, minimizing emission of pollutants, and providing stable support for cooking vessels. In this chapter I treat these two elements of product definition in turn, and then address the iterative nature of most problem definitions.

The Function of the Artifact

The function of an artifact is what it does as opposed to its structural characteristics (Crilly 2010). A theoretical ideal in design—one that avoids predetermining the solution—is to describe function in a way that does not imply a particular approach. Yet, describing function necessarily requires some such assumptions.











Exhibit 3-2. The wood-fueled Biolite cooking stove for developing regions of the world. The stove includes a fan for enhancing the flow of combustion air, which is powered by a thermoelectric

device. Source: Biolite.

Problem hierarchies as a way to describe function

Theodore Levitt famously wrote that “people buy ¼-inch drill bits but need ¼-inch holes” (Levitt 1977). Of course, people don’t really need ¼-inch holes either, but rather, they need, for instance, to fasten a book shelf to the wall. Indeed, any statement of a design problem, of the basic function of an artifact, reflects a decision about the level of abstraction at which the problem will be tackled, and assumptions about how the function will be addressed.

Exhibit 3-3 illustrates some possible levels of abstraction for a restatement of the Levitt problem “drive a 6 mm drill bit at 1000 rpm.” The function can be stated more broadly by asking why as follows.

Q: Why do you want to drive a drill bit?

A: Because I want to make a hole.

Q: Why do you want to make a hole?

A: Because I want to fasten a book shelf to the wall.

and so forth…

The answers to a sequence of “why” questions form an abstraction hierarchy of design problem definitions. One such hierarchy is shown in Exhibit 3-3.

The simple hierarchy of Exhibit 3-3 belies a more complex relationship among problems. There are typically multiple motives for solving a particular problem and there are multiple approaches that can be taken to solve it. Exhibit 3-4 illustrates a portion of a network of problem statements emanating from one of the more abstract problem statements in Exhibit 3-3— “In what way might we educate ourselves?” Articulating a design problem unavoidably reflects the designer’s decision about the level of abstraction at which the design effort will focus.

Is there a correct level of abstraction? On the one hand, making design problems more abstract is good because doing so opens up additional avenues for exploration, broadening the range of solutions the designer considers. On the other hand, the more abstract the problem becomes, the less likely the designer will be able to significantly close the gap in the user experience. A power tool designer had best not abstract the design problem so much that he or she is trying to close gaps in higher education, a challenge for which the designer is likely ill suited. In the Toyota Production System, one of the techniques for problem solving is called the “five whys method,” which is intended to get to the root cause of a problem (Ohno 1988). That method, of asking “why” five times, appears to be a good heuristic in design as well, forcing the designer to consider alternative definitions of the design problem, which may be somewhat more abstract than initially assumed.



Exhibit 3-3. Problem hierarchy for the initial problem definition “In what way might we drive a 6 mm drill bit at 1000 rpm?”


Exhibit 3-4. Problem network based on the question “In what way might we educate ourselves?”

Formal descriptions of function

In most cases, the basic function of artifacts is described using unstructured text, as in “drive a 6 mm bit at 1000 rpm.” However in some domains, problems can be described more formally. For instance, in architecture, problem definition, or programming, often includes an adjacency diagram as shown in Exhibit 3-5. The most basic function of the facility for the Camden Community Center might be stated as “provide a physical space for programs that enhance the health and well-being of the San Jose community.” An elaboration of that basic function specifies the types and sizes of spaces required and the desired relationships among those spaces. It does not contain any description of the form, position, orientation, or materials that would comprise the eventual building. In this sense it is still the what and not the how.

There have been several attempts in the design theory community to create formal languages for describing function (Finger and Dixon 1989), and there have been modest successes in narrow domains of application, such as electro- and fluid-mechanical systems and digital circuits (Mead and Conway 1980). There have also been efforts to create informal functional languages to facilitate the practice of design (Fowler 1990; Hubka and Eder 1988). These languages are sometimes used to create diagrams consisting of functional elements, expressed as linguistic terms like convert energy, connected by links indicating the exchange of signals, materials, forces, and energy. Some authors of informal functional languages provide a vocabulary of standard functional elements, while others rely on users to devise their own. Functional elements are sometimes called functional requirements or functives, and these diagrams have been variously called function diagrams, functional descriptions, and schematic descriptions (Pahl and Beitz 1984).

Exhibit 3-5. Bubble, or adjacency, diagram for Camden Community Center (San Jose, California). Source: Sabrina Phillips.

Desirable Qualities in the Artifact

The basic function of an artifact is rarely all the user cares about. For instance, even if a paperweight does its job of preventing paper from blowing about, the user probably also cares how it looks. In this case, while aesthetics is not a basic function of the paperweight, it is a quality of that artifact that must concern its designer.

Needs

In the field of product design, the desired qualities in an artifact are called needs, a term I’ll adopt here. User needs are usually represented as a list of thirty to one hundred desired qualities of an artifact. That list is in essence a causal model of the relationship between artifact characteristics and user satisfaction. The list is an understanding by the designer of what the user cares about and what characteristics drive preference and satisfaction. If the artifact possesses those qualities, the user will be satisfied. Exhibit 3-6 is a list of 66 needs for a hand cart, derived from one-on-one interaction with potential users using the methodology of Ulrich and Eppinger (2011). In practice, needs are derived from both verbal interaction with potential users and from passive observational studies of potential users grappling with the basic problem the designer is trying to solve.

While needs are desired qualities of a solution, and ideally do not embody a preconceived design concept, they clearly reflect some assumptions about the direction of the solution. The qualities listed in Exhibit 3-6 suggest a human-powered, wheeled device. Many of the qualities in Exhibit 3-6 would be irrelevant for a different assumed design direction; for instance, a valet service that transported belongings on behalf of the user. Similarly, additional needs would almost certainly be important if the designer pursued a remote-controlled, electric-powered cart.

Stakeholders

When user-innovators create artifacts for themselves, the activity of defining the problem and articulating needs may never be formally conducted—needs remain implicit for the designer. When professional designers create artifacts for others, some process of understanding and documenting needs is almost always adopted in practice. When potential users are essentially aligned in their interests, they may be thought of as a market segment or user community and treated somewhat alike. However, in some cases, an artifact is intended to address the needs of a collection of stakeholders whose needs are not aligned. The same prison must serve both inmates and guards. The same school lunch must be tasty (for kids), healthy (for parents), and inexpensive (for school districts). Problem definition therefore benefits from a deliberate identification of stakeholder groups with interests in the resulting artifact, and from an articulation of the distinct needs of those stakeholder groups.

Do users really need most artifacts?

In the context of this chapter, needs are desired qualities of an artifact, rather than the attributes of the artifact that are needed in some fundamental sense. For instance, Exhibit 3-7 is the Hardee’s Monster Big Burger, which features two 1/3-pound patties of beef, three slices of cheese, four strips of bacon, and mayonnaise on a buttered roll. No one needs this artifact, yet it clearly delivers satisfaction to individuals in the market segment targeted by Hardee’s. (Incidentally, I am not arguing against the creation of the Hardee’s Big Burger; I’m only observing that it is clearly not a healthy solution to meeting the basic need for everyday calories.)

Designers adopt a moral stance when creating artifacts. The dominant perspective in the practice of product design is of the designer as agent for a for-profit enterprise, and “needs” are those qualities that will lead to the greatest satisfaction for target consumers. Other perspectives are common and valid, including the perspective that designers have an ethical responsibility to create artifacts that are “good” for users. Of course, in doing so, designers are forced to make tricky judgments. Should Hardee’s really not offer users the possibility of an occasional fatty, salty, and yummy (to some) experience? If not the Monster Big Burger, what about buttered popcorn, or premium ice cream?

Meeting the needs of mindful adults possessing full information can probably be reasonably justified by some designers, even if addressing those needs may detract from health or other desirable objectives. Designers can probably not reasonably justify addressing needs in ways that are manipulative or deceptive.

Specifying and Quantifying Design Problems

Measurement is part of the religion of modern management. As annoying as attempts to measure everything can be, measurement has unambiguously led to dramatic and remarkable performance improvement in many human endeavors, including manufacturing, athletics, science, and medicine.



Exhibit 3-6. A list of needs for a personal hand cart. The needs in boldface are the primary needs, generalizations of the more detailed secondary needs.


Exhibit 3-7. The Hardee’s Monster Big Burger.

What need does this artifact address? Source: Hardee’s.

In design, quantification and measurement allow precision in defining problems. For instance, while a desirable quality of an automobile might be economical operation, that need can be made precise by specifying that the fuel economy exceed 20 kilometers per liter of fuel. In product design, these quantified needs are often called specifications (Ulrich and Eppinger 2011). In architecture, they are often called performance requirements (Duerk 1993).


Continue reading this ebook at Smashwords.
Download this book for your ebook reader.
(Pages 1-36 show above.)