What are the limits for this design problem?

5.1 IDENTIFYING AND SETTING THE CLIENT'S LIMITS

Recall that in Chapter 3 we talked about questioning our client in order to better understand the problem. One of the questions we suggested asking was

• Are there things or circumstances you want us to avoid?

  This question might also have been phrased in terms of boundaries the client did not want crossed or limits that could not be exceeded, or numbers that were to be treated as “hard caps.” Whatever the wording, we are talking about constraints:

• constraint n: a limit or restriction on the design's behaviors or attributes Constraints are typically framed as a binary yes-or-no choice: a ladder material is a conductor or it is not, or the step deflection is less than 0.05 in. or it is not. Any (and all) designs that violate these limits are unacceptable. Constraints are important to the design process because they limit the size of a design space by forcing the exclusion of unacceptable alternatives. For example, a ladder design that fails to meet OSHA standards must be rejected (Table 5.1).

TABLE 5.1 The list of safe ladder constraints extracted from the list of attributes of Table 3.1

There are limits to everything, of course, but as a practical matter we often use constraints as a kind of “checklist” to help us keep our list of possible designs to a reasonable length. Such constraints are typically expressed in terms of specific numerical values, but not always, as we can see from the safe ladder constraint list in Table 5.1. By way of contrast, objectives are much more likely to be expressed as verbal statements, for example, a ladder should be cheap.

Objectives and constraints are closely related, but they are not interchangeable. Constraints limit the size of the design space (i.e., the number of potential designs we might consider), while objectives permit us to explore what remains in that design space. Constraints enable us to reject unacceptable alternatives, while objectives enable us to select among design alternatives that are at least acceptable, or, in other words, designs that satisfice. Designs that satisfice may not be optimal or the best, but at least they satisfy all constraints. For example, we could minimally satisfy OSHA standards or we could significantly surpass those standards by making a “super safe” ladder in order to obtain a marketing advantage. Or, on the price side, a goal that a ladder should be “inexpensive” might also have a constraint that the ladder's cost cannot exceed $25. If we have both a low-cost objective and a $25 constraint, we may exclude some initial designs based on the constraint, while choosing among the remaining designs based on cost and other, non-economic objectives.

In Table 5.2 we list the constraints for the new juice container. Note that one constraint, chemically inert, is related to two of our objectives, safe and long shelf life.

5.2 DISPLAYING AND USING CONSTRAINTS

Constraints can be displayed in several ways. We can simply construct a list, as shown in Table 5.2. We can also add them to objectives trees, as we do in Figure 5.1. When we add them to the objectives tree, we need to clearly distinguish them from the objectives (e.g., we present constraints in boxes differently shaped than those used for objectives, as in Figure 5.1), and also select an appropriate place for them. In the case of the juice containers, chemically inert may be placed under both safe and long shelf life. Similarly, if we wanted to present an outline form of an objectives–constraint hierarchy, we might enter the constraints in italics or a different font. In either case, it is most important to recognize that constraints are related to but are different from objectives: they mean very different things and are used in different ways. These combined objectives–constraints trees can be a very effective way to communicate how these two very different concepts, objectives and constraints, interact especially when talking to clients or to nontechnical audiences.

TABLE 5.2 A list of constraints for the juice container design

Figure 5.1 A combined objectives (rectangles) and constraints (ovals) tree for the design of a new juice container. Compare this with Figure 4.2 that shows the “standard” objectives tree for the juice container.

In addition to expressing the client's limits on the design, we will find that constraints are also useful later in the design process, both to help us prune or narrow our space of designs, and to help us do our screening and evaluation of designs.

5.3 CONSTRAINTS FOR THE DANBURYARM SUPPORT

The constraints developed by team A for the arm support designed for Danbury School's Jessica are listed in Table 5.3, while those developed by team B are listed in Table 5.4. Particularly when placed in close proximity, these two constraints lists differ rather markedly. One difference is that team A's list has much more granularity in that it provides much more detail about the meaning of many of the constraints and the environment is which the entire design is set. Some are easily envisioned as binary choices (e.g., team A's “Must not contain any toxic material”). Others sound fuzzier and perhaps more like objectives (e.g., team B's “Design must not require more than two to three minutes for setup by an adult”). Still more interesting is the fact that the teams seem to have identified different limiting values for the same constraint: team A says that setup must be “8 min or less,” while team B says “not more than 2–3 min.” Perhaps this difference arose because of the different conversations each team had with the Danbury School's teaching staff, thus reflecting some variation in what different teachers thought was a reasonable setup time. Perhaps it reflected an unease felt by the staff when they were asked for—or encouraged, or even pushed—to provide hard numbers. And perhaps they really meant short setup times as an objective, rather than a constraint.

TABLE 5.3 Team A's list of constraints for the Danbury arm support project

TABLE 5.4 Team B's list of constraints for the Danbury arm support project

It is also interesting that team A had identified an objective (Table 4.10) of “Minimize number of sharp edges,” but that doesn't appear in any of their constraints, and we have to wonder why? Is it because this is a customized, “one of' design? Certainly, if we were designing a support arm to be marketed commercially, we would have to consider enforcing a constraint of having no sharp edges, rather than simply minimizing their number. In general, it is likely that the design of a widely used product will have to be done in a more constrained design space than client- or user-specific devices.

5.4 NOTES

Section 5.1: Constraints are discussed in Pahl and Beitz (1996). The very important notion of satisficing is due to Simon (1981).

Section 5.2: The results for the Danbury arm support design project are taken from final reports by Attarian et al. (2007) and Best et al. (2007) submitted during the Spring 2007 offering of Harvey Mudd College's first-year design course, E5: Introduction to Engineering Design.