We now complete our discussion of representing design knowledge by turning to the representation of the design process in terms of the languages of design that we identified in Chapter 5. We take a path parallel to that of the previous chapter as we show how AI-based problem-solving methods can be used to model the ways we solve design problems, as well as how we represent the kinds of design knowledge we use to solve design problems.

Classical Design Methods

In Chapter 3, we described several prescriptive models of the design process. Inherent in these prescriptions is a disposition toward inductive reasoning wherein we try to induce or infer a solution to a design problem by filling in incomplete information or knowledge. We might contrast this with a deductive approach to design wherein, in its most prevalent implementation, we deduce solutions to our current design problem from case studies of previous designs. As discussed in Section 6.2, there is a rough analogy here between using a set of rules to analyze the meaning of a set of symptoms or conditions, in which case we are reasoning deductively, and using a set of rules to work “backward” from a set of desired goals in order to find the conditions that would allow us to achieve those goals, given the rules under which we are operating. In the latter case, clearly, we are reasoning more inductively than deductively. The classical or traditional methods that we describe in this section are clearly informed by and support the inductive nature of the design-process prescriptions presented earlier (cf. Section 3.3).♦

Design is a central activity in engineering. Indeed, Herbert A. Simon has argued that design is the central activity that defines engineering – or, at the very least, distinguishes it from the “pure” sciences – because the role of engineering is the creation of artifacts. And yet, many of us within the engineering community believe that design is a misunderstood activity that is not well represented in engineering education or research. We are very much aware that engineering science dominates the intellectual landscape of engineering today, and it is certainly arguable that analysis dominates both engineering education and research. Indeed, it has long been a concern that design is improperly taught and inadequately represented in engineering curricula and that too often design is seen as legitimate only when it can be explained in terms of analysis (as in the notion that design is “iterative analysis”).

One of the problems that design educators and design researchers have faced is a perceived lack of rigor, and this perception has in turn led to calls for a more organized, more “scientific” focus to research about design. One aspect of this perception is that design is viewed as a “soft” subject: design is not a “hard” discipline because it is not sufficiently mathematical. Another aspect is that the vocabulary for analyzing and describing design is not shared, even within the design community, although this situation has begun to improve.

We have now defined, at least tentatively, what we mean by design, and we have described several views of the process of design. In so doing, we have identified some of the ways that problem-solving strategies could be employed in the design process. Now we turn to the task of trying to outline an organizational structure or taxonomy for design. According to the dictionary, a taxonomy is the result of the “study of the general principles of scientific classification” and a classification, at least in the natural sciences, is the “orderly classification of plants and animals according to their presumed natural relationships.” Similarly here, a taxonomy of design might (1) allow us to classify design problems according to certain characteristics; and (2) facilitate the organization of the knowledge, representation, and reasoning schemes that would be useful in modeling different kinds of design.

Are such taxonomies important? Why? One viewpoint is that a scientific theory of design cannot be developed without such a taxonomy. Another is that such taxonomies allow us to compare design methods and design tools – especially those reflecting the newer computer-aided technologies the ideas of which are reflected in this discussion. Our own viewpoint is stated somewhat differently in that we would stress any increase in our ability to understand and model the thought processes involved in design as being the best reason for developing such taxonomies. As we work toward this objective, we will simultaneously increase our abilities to compare various design tools and to develop and explore new design methods. We note also that, as with our characterizations of the design process, various taxonomies and classifications have been proposed, and there is certainly some overlap of ideas among them. After we review these various taxonomies, in an order roughly corresponding to their chronological development, we will try to analyze in a principled way what we have learned from so describing the thought processes of design.

Having offered our own definition of engineering design, we now go on to study design as an activity – that is, the process of design. In this chapter, we review some of the established models of the design process. Then we go on to describe more recent articulations, some of which are rooted in the AI-based ideas mentioned earlier. Parts of the discussion may seem vague or abstract because we are trying to describe a complex process by breaking it down into smaller, more detailed pieces, but we are not going to produce a detailed cookbook that must be followed in order to complete a design. We are simply trying to picture, in words and diagrams, what is going on in our head when we are doing design.

Dissecting the Design Process

We start by looking back at the questions we asked (and others that we might have but did not) in our ladder-design exercise. In so doing, we find that we can decompose or break down the process into a sequence of steps by extracting and naming some of those steps. For example, when we ask, “How much weight should a safe ladder support?” and “For what purposes is the ladder to be used?,” we are

More than 15 years have passed since the publication of Engineering Design: A Synthesis of Views. Significant new material has emerged during this time that deserves to be incorporated into the unified view presented in the first edition. In addition, a larger group of people now believe that designing is not just analysis and that research in design offers the possibility of studying a collection of cognitive processes that allows significant insights. Thus, for this new edition, we replace the first edition subtitle with Representation and Reasoning to make its focus more explicit.

Our approach was to leave the first edition more or less untouched while adding material that clarifies, updates, and extends the original text. This new material was placed in sidebars that are keyed to appropriate points in the (original) text. Any new references were added to the end of the book to allow students and scholars to explore topics that interest them in more detail. We hope that these additions will extend the life of the book for another 15 years (or even more!).

We now turn to the representation of designed artifacts. By focusing first on objects, we risk introducing an artificial distinction into the scope and meaning of design knowledge. Clearly, design knowledge must incorporate information about design procedures, shortcuts, and so on, as well as about artifacts. Furthermore, there is some evidence that designers think about processes as they begin to represent the objects they are designing, especially when they begin to create sketches and drawings. And, of course, to fully represent objects and their attributes also means being able to fully represent concepts (e.g., design intentions, plans, behavior, and so on) that are perhaps not as easy to describe or represent as physical objects. However, because the end point of most engineering designs is a set of fabrication specifications for an object (and, occasionally, the object itself) and because engineers often think in terms of devices, we start our discussion of representation with physical objects as our focus. As a consequence, we may somewhat overlap our later discussion (cf. Chapter 6) of the representation of design knowledge and design processes.

The Languages of Engineering Design

To discuss different representations of designed objects or artifacts is to talk about the languages or symbols in which those representations are cast. That is, for us to describe an object, whether real or conceptual, in detail or abstractly, we must effectively choose a language with which to write our description.♦