What does it mean to design something? Is engineering design different from other kinds of design?

1.1 WHERE AND WHEN DO ENGINEERS DESIGN?

What does it mean for an engineer to design something? When do engineers design things? Where? Why? For whom?

An engineer working for a large company that processes and distributes various food products could be asked to design a container for a new juice product. She could work for a design-and-construction company, designing part of a highway bridge embedded in a larger transportation project, or for an automobile company that is developing new instrumentation clusters for its cars, or for a school system that wants to design specialized facilities to better serve students with orthopedic disabilities.

There are common features that make it possible to identify a design process and the context in which it occurs. In each of these cases, three “roles” are played as the design unfolds. First there is a client, a person or group or company that wants a design conceived. There is also a user who will employ or operate whatever is being designed. Finally, there is a designer whose job is to solve the client's problem in a way that meets the user's needs. The client could be internal (e.g., a person at the food company in charge of the new juice product) or external (e.g., the government agency that contracts for the new highway system). While a designer may relate differently to internal and external clients, it is typically the client who motivates and presents the starting point for design. That is why a designer's first task is to question the client to clarify what the client really wants and translate it into a form that is useful to her as an engineer. We'll say more about this in Chapter 3 and beyond.

It is worth noting that the client, the user, and even the designer may not always be three or even two different people: In a small start-up, for example, the designer may be the client, and may also rely on his or her own personal experience as a user when initiating a design. Similarly, for an internal project, the roles may again merge. However, for most design projects, it is useful to distinguish between the three roles and their respective responsibilities—as anyone who has used beta versions of software can testify because all too often, software designers imagine that their own experience is sufficient for every user!

The user is a key player in the design effort. In the contexts mentioned above, the users are, respectively, consumers who buy and drink a new juice drink, drivers on a new interstate highway, and students with orthopedic disabilities (and their teachers). Users have a stake in the design process because designs have to meet their needs. Thus, the designer, the client, and the user form a triangle, as shown in Figure 1.1. The designer has to understand what both the client and users want and need. Often the client speaks to the designer on behalf of the intended users, although anyone who has sat in a cramped seat on a commercial flight would have to ask both airlines and airplane manufacturers who they think their users are!

The public also has a stake in many designs, for example, a new interstate highway. While the notion of the public may seem to be implicit in the user, this is not always the case. Explicitly identifying who is affected by a design is important, because it may raise ethical issues in design projects, as we will explore in Chapter 17.

It is clear that both designer and client have to understand what the users want and what the public demands in a design. In Chapter 2, we will describe design processes that model how engineers interact with and communicate their design thinking to clients and potential users. In Chapters 3–5, we will identify some tools to organize and refine that thinking.

Engineering designers work in many different kinds of environments: small and large companies, start-up ventures, government, not-for-profit organizations, and engineering services firms. Designers will see differences in the size of a project, the number of colleagues on the design team, and their access to relevant information about what users want. On large projects, many designers will be working on details of a project that are so confined that much of what we describe in this book may not seem immediately useful. The designers of a bridge abutment, an airplane fuel tank, or components of a computer motherboard are not likely to be as concerned with the larger picture of what clients and users want from the entire project because the system-level design context has already been established. These are detailed design problems in which more general design issues have already been decided. However, all projects begin with conceptual design. Thinking about the size and mission of an airplane will have been done before fuel tank design begins, and the overall performance parameters of the computer motherboard will be determined prior to selecting specific chips.

Figure 1.1 The designer-client-user triangle shows three parties involved in a design effort: a client, who has objectives that must be realized; the users of the design, who have their own wishes; the designer, who must design something that can be built and that satisfies everybody.

Large, complex projects often lead to very different interpretations of client project statements and of user needs. One has only to look at the many different kinds of skyscrapers that decorate our major cities to see how architects and structural engineers envisage different ways of housing people in offices and apartments. Visible differences also emerge in airplane design (Figure 1.2) and wheelchair design (Figure 1.3). Each of these sets of devices could result from a simple, common design statement: Airplanes are “devices to transport people and goods through the air,” and wheelchairs are “personal mobility devices for people who are unable to use their legs.” However, the different products that have emerged represent different concepts of what clients and users wanted (and what designers perceived they wanted) from these devices. Designers have to clarify what clients want and then translate those wants into an engineered product.

Figure 1.2 Several aircraft, each of which “safely transports people or goods through the air,” and each of which was designed for a different mission.

Figure 1.3 A collection of “personal mobility devices to transport people unable to use their legs,” that is, a set of very different wheelchairs.

The designer–client–user triangle also prompts us to recognize that the interests of the three players might diverge and consider the consequences of such divergence. The presence of multiple interests creates an interaction of multiple obligations, and these obligations may conflict. For example, the designer of a juice container might consider metal cans, but easily “squashed” cans are a hazard if sharp edges emerge during the squashing. There could be trade-offs among design variables, including the material of which a container is to be made and the container's thickness. The choices made in the final design could reflect different assessments of the possible safety hazards, which in turn could lay a foundation for potential ethics problems. Ethics problems, which we will discuss in Chapter 17, occur because designers have obligations not only to clients and users, but also to their profession and to the public at large, as detailed in the codes of ethics of engineering societies. Thus, ethics issues are always part of the design process.

Another aspect of engineering design practice that is increasingly common in projects and firms of all sizes is that teams do design. Many engineering problems are inherently multidisciplinary (e.g., the design of medical instrumentation), so there is a need to understand the requirements of clients, users, and technologies in very different ways. This requires that teams be assembled to understand and address such different needs. The widespread use of teams clearly affects how design projects are managed, another recurring theme of this book.

Engineering design is a multifaceted subject. In this book, we offer a framework to facilitate productive thought about the conceptual issues and the resulting choices made early in the design of many different engineered products.

1.2 A BASIC VOCABULARY FOR ENGINEERING DESIGN

There are many definitions of engineering design in the literature, and there is a lot of variation in how engineers describe design actions and attributes. We will now define what we mean by engineering design and also some of the related terms that are commonly used by engineers and designers.

1.2.1 Defining Engineering Design

The following formal definition of engineering design is the most useful one for our purposes:

• Engineering design is a systematic, intelligent process in which engineers generate, evaluate, and specify solutions for devices, systems, or processes whose form(s) and function(s) achieve clients' objectives and users' needs while satisfying a specified set of constraints. In other words, engineering design is a thoughtful process for generating plans or schemes for devices, systems, or processes that attain given objectives while adhering to specified constraints.

It is important to recognize that when we are designing devices, systems, and processes, we are designing artifacts: artificial, manmade objects, the “things” or devices that are being designed. They are most often physical objects such as airplanes, wheelchairs, ladders, cell phones, and carburetors. But “paper” products (or their electronic versions) such as drawings, plans, computer software, articles, and books are also artifacts in this sense. In this text we will use device, artifact, or system rather interchangeably as the objects of our design.

With further recourse to our “design dictionary,” we note the following definitions:

• design objective n: a feature or behavior that we wish the design to have or exhibit.
• design constraint n: a limit or restriction on the features or behaviors of the design. A proposed design is unacceptable if these limits are violated.
• functions n: things a designed device or system is supposed to do. Engineering functions almost always involve transforming or transferring energy, information, or material. We view energy transformation or transfer quite broadly: It includes supporting and transmitting forces, the flow of current, the flow of charge, the transfer of material, and so on.
• means n: a way or a method to make a function happen. For example, friction is a means of fulfilling a function of applying a braking force.
• form n: the shape and structure of something as distinguished from its material. We will not deal with form very much in this book, but form is central to industrial design, a very important part of product design.

Note that objectives for a design are different from the constraints placed on a design. Objectives may be completely or partially achieved, or may not be achieved at all. Constraints, on the other hand, must be satisfied or the design is not acceptable. That is, they are binary (yes or no): There are no intermediate states. If we were designing a corn degrainer for Nicaraguan farmers to be cheaply built of indigenous (local) materials, one objective might be to make it as cheap as possible, while a constraint might limit the cost to less than US$20.00. Making the degrainer of indigenous materials could be an objective if it is a desired attribute, or a constraint if it is a required attribute.

Our definition of engineering design states that designs emerge from a systematic, intelligent process. This is not to deny that design is a creative process. There are, however, techniques and tools we can use to support our creativity, to help us think more clearly, and to make better decisions along the way. These tools and techniques, which form much of this book, are not formulas or algorithms. Rather, they are ways of asking questions and of presenting and reviewing the answers to those questions as the design process unfolds.

1.2.2 Assumptions Underlying Our Definition of Engineering Design

There are some implicit assumptions behind our definition of engineering design and the terms in which it is expressed. It is useful to make them explicit.

First, design is a thoughtful process that can be understood, and therefore both taught and learned. Without meaning to spoil the magic of creativity or the importance of innovation in design, people think while designing. So it is important to have tools to support that thinking, to support design decision making and even design project management.

The formal methods we use to generate design alternatives follow naturally from our inclination to think about design. This might seem pretty obvious: There's not much point in considering new ways of looking at design problems or talking about them—unless we can exploit them to do design more effectively. Thus, our formal methods are part of the (formal) process we use to identify and clarify what a client wants (i.e., objectives), needs (i.e., constraints), and intends the design to do (i.e., its functions). We will describe such a process in Chapter 2, and we will show how it begins with a client's problem statement and ends with a functionally complete design that does everything the client wants it to do, has the desired attributes, and stays within the client's constraints.

1.2.3 Measuring the Success of an Engineered Design

How do we know whether our design is successful? We make measurements. What do we measure? Early in the design process we establish a set of metrics to ascertain or measure the extent to which a proposed design meets our design objectives:

• metric n: a standard of measurement; in the context of engineering design, a scale on which the achievement of a design's objectives can be measured and assessed.

Metrics provide scales or rulers on which we can measure the degree to which objectives are achieved. To offer a truly simple example, let us suppose an objective of being able to jump as far as possible. A metric for such a jump might be based on using a ruler to measure the distance jumped (in feet or meters). There are interesting issues that must be addressed when talking about metrics: All objectives are not easily quantified, their quantifications are not readily compared, and not all measurements are easily made. We discuss these issues in Chapter 4. We will use metrics to mean rulers or standards specifically for objectives.

Later in the design process, we establish specifications to express in engineering terms a design's functional behavior. Setting out such specifications is an essential aspect of the “best practices” of engineering design as it is currently done in industry:

• specification(s) n: a scale on which the achievement of a design's functions can be measured. Specifications are engineering statements of the extent to which functions are performed by a design.

Design specifications are stated in a number of different ways, depending on what the designer intends to articulate. Thus, specifications may specify values for particular functions or design features, procedures for calculating functions or behaviors of the design, or performance levels that must be attained by the design.

It is important to note that the vocabulary of design practice varies across different engineering disciplines and related fields such as computer science. In fact, the terms specifications and requirements are often taken as synonymous descriptors of a design's features and behaviors, as well as its functions. For the sake of clarity, we will, in Chapters 2 and 5, take a specific stance about these two terms, as follows: We will normally use requirements as shorthand for customer requirements, which are the client's statement of objectives, constraints, and functions. We will use specifications as shorthand for engineering specifications or design specifications, which are the designer's expression of what a design is intended to do in engineering terms. We will define requirements and specifications in greater detail in Chapter 2, and will explore the nature of design specifications extensively in Chapter 5.

1.2.4 Form and Function

Form and function are two related yet independent entities. This is important. We often think of the design process as beginning when we sit down to draw or sketch something, which suggests that form is a typical starting point. However, function is an altogether different aspect of a design that may not have an obvious relationship to its shape or form. In particular, while we can often infer the purpose of a device from its form or structure, we can't do the reverse, that is, we cannot automatically deduce what form a device must have from the function alone. To take a simple example, we can't look at the shape of a smartphone and know what it was supposed to do. Moreover, if we were asked to design a smartphone, is there any obvious link or inference that we can use to choose its form or shape? That is, knowing that we want to achieve the function of wireless telephony does not lead us to (or even suggest) any of the forms of smartphones.

1.2.5 Design and Systems

While our focus is on the design of “a thing,” there are two broader issues that are worth thinking about, both having to do with systems. First, no thing or device stands alone, entirely independent of its environment: It usually works in some environment and often has to interface with other devices. Thus, a definition offered by the late Herbert A. Simon, Nobel laureate in economics and founding father to several fields, including design theory: “Design is an activity that intends to produce a description of an artifice in terms of its organization and functioning”its interface between inner and outer environments.” This definition places designed objects in a systems context that recognizes that any artifact operates as part of a system that includes the world around it. In this sense, all design is systems design because devices, systems, and processes must each operate within and interact with their surrounding environments.

This leads to the second thought about design and systems. The major design challenges facing engineers in the decades to come will be less about devices of “standalone” artifacts, and more concerned with designing complex engineering systems. These have been defined as “a class of systems characterized by a high degree of technical complexity, social intricacy, and elaborate processes, aimed at fulfilling important functions in society.” Examples of such complex systems include the U.S. interstate highway system, the country's electric power grid, and the Internet. Clearly there are many more issues involved (and things to be learned) in designing such large technical systems, but the problem definition and problem-solving approaches we introduce here will be useful in attacking them.

1.2.6 Communication and Design

Finally, our definition of engineering design and the related assumptions we have identified rely heavily on the central role of communication in the design process. Some set of languages or representations is involved in every part of the design process. From the original communication of a design problem, through the final fabrication specifications, the device or system being designed must be described and “talked about” in many, many ways. Communication is a key issue. It is not that problem solving and evaluation are less important; they are extremely important. But problem solving and evaluation are done at levels and in styles—whether spoken or written languages, numbers, equations, rules, charts, or pictures—that are appropriate to the immediate task at hand. Successful work in design is inextricably bound up with the ability to communicate.

Engineering designers do not typically produce their artifacts, except in the form of prototypes and proofs of concept. While these prototypes are useful for understanding the design space and demonstrating the feasibility of the design, the ultimate product of most contemporary design is a set of fabrication specifications for others to use in making the artifacts. These fabrication specifications provide a detailed description of the designed device so that it can be assembled or manufactured, thus separating the “designing” from the “making.” This description must be both complete and quite specific; there should be no ambiguity and nothing can be left out. Indeed, this specification may be the only connection between a designer and the fabricator or maker of the design.

Traditionally, fabrication specifications were presented in a combination of drawings (e.g., detailed engineering drawings, circuit diagrams, flow charts) and text (e.g., parts lists, materials specifications, assembly instructions). We can achieve completeness and specificity with such traditional specifications, but we may not capture the designer's intent—and this can lead to catastrophe. In 1981, a suspended walkway across the central atrium in the Hyatt Regency Hotel in Kansas City collapsed because a contractor fabricated the connections for the walkways in a manner different than intended by the original designer.

In that design, walkways at the second and fourth floors were hung from the same set of threaded rods that would carry their weights and loads to a roof truss (see Figure 1.4). The fabricator was unable to procure threaded rods sufficiently long (i.e., 24 ft.) to suspend the second-floor walkway from the roof truss, so instead, he hung it from the fourth-floor walkway with shorter rods. (It also would have been hard to screw on the bolts over such lengths and attach walkway support beams.) The fabricator's redesign was akin to requiring that the lower of two people hanging independently from the same rope change his position so that he was grasping the feet of the person above. That upper person would then be carrying both people's weights with respect to the rope. In the hotel, the supports of the fourth-floor walkway were not designed to carry the second-floor walkway in addition to its own dead and live loads, so a collapse occurred, 114 people died, and millions of dollars of damage was sustained. If the fabricator had understood the designer's intention to hang the second-floor walkway directly from the roof truss, this accident might never have happened. Had there been a way for the designer to explicitly communicate his intentions to the fabricator, a great tragedy might have been avoided.

Figure 1.4 The walkway suspension connection in Hyatt Regency Hotel in Kansas City, as originally designed and as built. The change made during construction left the second-floor walkway hanging from the fourth-floor walkway, ratherthan from the roof truss.

There's another lesson to be learned from the separation of the “making” from the “designing.” If the designer had worked with a fabricator or a supplier of threaded rods while he was still designing, he would have learned that no one made threaded rod in the lengths needed to hang the second-floor walkway directly from the roof truss. Then the designer could have sought another solution in an early design stage. It was the case for many years that there was a “brick wall” between design engineers on one side and manufacturing engineers and fabricators on the other. Only recently has this wall been penetrated. Manufacturing and assembly considerations are increasingly addressed during the design process, rather than afterward. One element in this new practice is design for manufacturing, in which the ability to make or fabricate an artifact is specifically incorporated into the design requirements, perhaps as a set of manufacturing constraints. Clearly, the designer must be aware of parts that are difficult to make or of limitations on manufacturing processes as her design unfolds. The Hyatt Regency tale and the lessons drawn from it show us that communication is really important. Unless a design's fabrication specifications are complete and unambiguous, and unless they clearly convey a designer's intentions, the device or system won't be built in accord with the requirements set out by the designer. In short, design is a human activity, a social process. This means that communication among and between stakeholders remains a preeminent, consistent, and ongoing concern.

1.3 LEARNING AND DOING ENGINEERING DESIGN

Design is rewarding, exciting, fun, even exhilarating. But good design doesn't come easily. In fact, achieving excellence requires serious intellectual effort. That is why learning and doing (and teaching) design is challenging.

1.3.1 Engineering Design Problems are Challenging

Engineering design problems are challenging because they are usually ill structured and open-ended:

• Design problems are considered ill structured because their solutions cannot normally be found by applying mathematical formulas or algorithms in a routine or structured way. While mathematics is both useful and essential in engineering design, it is not possible to apply formulas to problems that are not well bounded or even defined. In the early stages of design, “formulas” are either unavailable or inapplicable. In fact, some experienced engineers find design difficult, simply because they can't fall back on structured, formulaic knowledge—but that's also what makes design a fascinating experience.
• Design problems are open-ended because they typically have several acceptable solutions. Uniqueness, so important in many mathematics and analysis problems, simply does not apply to design solutions. In fact, more often than not, designers work to reduce or bound the number of design options they consider, lest they be overwhelmed by the possibilities.

Figure 1.5 A set of ladders that “enable people to reach heights they would be otherwise unable to reach” and suggest that design objectives involve more than just getting people up to some height.

Evidence for these two characterizations can be seen in the familiar ladder. Several ladders are shown in Figure 1.5, including a stepladder, an extension ladder, and a rope ladder. If we want to design a ladder, we can't even select a particular ladder type until we determine a specific set of uses for that ladder. Even if we decide that a particular form is appropriate, such as a stepladder, other questions arise: Should the ladder be made of wood, aluminum, plastic, or a composite material? How much should it cost? And, how much should the ladder support? Can we identify the best ladder design or the optimal design? The answer is, “No,” we can't stipulate a ladder design that would be universally regarded as the best or that would be mathematically optimal in every dimension.

How do we talk about some of the design issues, for example, purpose, intended use, materials, cost, and possibly other concerns? In other words, how do we articulate the choices and the constraints for the ladder's form and function? There are different ways of representing these differing characteristics by using various “languages” or representations. But even the simple ladder design problem shows how the two characteristics of being open-ended (e.g., what kind of ladder?) and ill defined (e.g., is there a formula for ladders?) make design a difficult subject. How much more complicated and interesting are projects to design a new automobile, a skyscraper, or a way to land a person on Mars?

1.3.2 Learning Design by Doing

Teaching someone how to do design is not that simple. Like riding a bike, painting, or dancing, it often seems easier to tell a student, “Watch what I'm doing and then try to do it yourself.” There is an element of learning by doing, which we call a studio aspect, in trying to teach any of these activities.

One of the reasons that it is hard to teach someone how to do design—or to throw a ball or draw or dance—is that people are often better at demonstrating a skill than they are at articulating what they know about applying their individual skills. Some of the skill sets just mentioned involve physical capabilities, but the difference of most interest to us is not simply that some people are more gifted physically than others. What is really interesting is that a talented softball pitcher cannot tell you just how much pressure she exerts when holding the ball, nor exactly how fast her hand ought to be going, or in what direction, when she releases it. Yet, somehow, almost by magic, the softball goes where it's supposed to go and winds up in the hands of a catcher. The real point is that the thrower's nervous system has somehow acquired the knowledge that allows her to assess distances and choose muscle contractions to produce a desired trajectory. While we can model that trajectory, given initial position and velocity, we do not have the ability to model the knowledge in the nervous system that generates that data. The pitcher has a combination of muscle memory, discipline, training, and practice that allows her to repeat the pitch time and again.

In a similar way designers, like dancers and athletes, use drills and exercises to perfect their skills, rely on coaches to help them improve both the mechanical and interpretive aspects of their work, and pay close attention to other skilled practitioners of their art. Indeed, one of the highest compliments paid to an athlete is to say that he or she is “a student of the game.”

1.4 MANAGING ENGINEERING DESIGN PROJECTS

Good design doesn't just happen. Rather, it results from careful thought about what clients and users want, and about how to articulate and realize design requirements. That is why this book focuses on tools and techniques to assist the designer in this process. One particularly important element of doing good design is managing the design project. Just as thinking about design in a rigorous way does not imply a loss of creativity, using tools to manage the design process doesn't mean we sacrifice technical competency or inventiveness. On the contrary, there are many organizations that foster imaginative engineering design as an integral part of their management style. At 3M, for example, each of the more than 90 product divisions is expected to generate 30% of its annual revenues from products that didn't even exist five years earlier. So we will also introduce a few management tools that are useful in design projects.

We began this chapter by defining terms and developing a common vocabulary for design; we will do the same for management, project management, and the management of design projects in Chapter 16. For now, it will suffice to introduce the “3S model of project management.” To be successful, a design project must track scope, schedule, and spending:

• scope n: deciding what a project must accomplish to be successful.
• schedule n: making sure that resources needed to accomplish the project scope are available and used when needed to complete the project by its agreed-upon due date.
• spending n: ensuring that a design project uses only the resources necessary to complete the project on time.

Project management is the tracking of these three matters to accomplish the goals and objectives of a project. All engineering design projects can be defined in terms of their goals, resources, and a need to finish in a fixed time frame. A number of tools have been developed to help project managers track a project's scope, scheduling, and spending. These include tools for understanding and listing the work to be done, scheduling the tasks to be done logically and efficiently, assigning tasks to individuals, and monitoring both project progress and expenditures. We will explore some of these tools as they are applicable to design projects in Chapter 16.

The precision in scope and spending spoken of in the context of project management may seem somewhat at odds with the open-ended nature of design. This is certainly the case when we try to predict the final form or outcome of a design project. Unlike a construction project, where the expected results are clearly articulated, a design project, especially a conceptual design project, may have a number of possible successful outcomes, or none! This makes the task and tools of project management only partially useful in design settings. As a result, we will present only project management tools that we have found to be useful in managing design projects conducted by small teams.

1.5 NOTES

Section 1.2: Our definition of engineering design draws heavily on Dym and Levitt (1991), Dym (1994), and Dym et al. (2005). Simon's definition of design is based on a set of lectures that were published as The Sciences of the Artificial (1981). The definition of engineering systems is taken from de Weck, Roos, and Magee (2011).