Short version: We should strive to be rational and include a reasonably wide range of ideas when we make design decisions. However, we are not fully rational, and therefore we are likely to exclude ideas simply because of our habits, bias, disinterest or fear of making a mistake.

Be Mindful of Habits, Bias, Disinterest and Fear

Humans commonly make errors in reason we make when we think we are being rational. These questions are applicable to many aspects of life. In the context of design, we can easily fool ourselves into justifying decisions rooted in habit or lack of curiosity by thinking we are making a optimal choices from a dispassionate and rational perspective.

The fields of behavioral science and behavioral economics include the study of unconscious bias during decision-making. In a classic article (see references, below), Tversky and Kahneman describe several scenarios where human biases and faulty heuristics lead to nonrational judgements and decisions. Buster Benson gives a readable and more recent summary of cognitive biases.

As engineers, we pride ourselves in rationality and analytical thinking. We're trained to get the right answer, to think there is a right answer, and put a box around it. While that analytical mindset is reasonable and preferred when doing standard analysis, say when calculating the deflection of a beam or the flow rate in a pipe, it's not helpful when making decisions early in the design process. When identifying customer requirements or generating concepts to solve a design problem, we need to be less analytical and more creative. That's not to say we abandon reason. Rather, we admit that the reductive and analytical model that serves us so well when doing engineering science, is not as helpful during concept development. Furthermore, we also admit that there are usually multiple solutions to a design problem.

Questions to consider:

• Are we choosing the familiar over the non-familiar even when the familiar may be the inferior choice? In other words, are our habits limiting our range of thinking and limiting our choices?

• Do we simply "not like" an idea without being able to give a rational reason for not liking the idea? In other words, do we have a bias (acknowledged or not) that prevents us from giving a new or challenging idea a fair consideration?

• Are we simply not interested in learning something new because … "we don't have time" (which is a good reason if it is really true) or "we are more comfortable with what we already know", or "we think that learning more about the decision won't matter"?

• Are we afraid of failing, and therefore more susceptible to habit, bias, disinterest, or simply not able to make a choice?

A failed prototype can given important information. Try to re-imagine the design process as a series of experiments designed to evaluate outcomes. If an idea or design concept does not work out, the "failure" is a learning process. To get the most out of experiments that allow failure, anticipate the results and collect data during the experiment: don't simply run a yes/no experiment.

Note: Being mindful of our habits, bias, disinterest and fear is not an argument for or against any decision. Rather, the point is to become aware of the motives for our decisions. In general, better decisions are made after rationally considering a reasonably wide range of options We should be careful that our habits, bias, disinterest and fear do not either (1) work against a rational consideration of options and/or (2) cause us to impose unhelpful limits on options to include in our rational analysis.

Be Mindful of the Relative Importance of Decisions

Mattson and Sorenson distinguish between the Vital Few and the Mundane Many. See section 3.9 in the textbook.

The Vital Few are the 10 to 20 percent of decisions "that will have a strong influence on how well the design meets the market needs." (p. 42, v 4.0)

The Mundane Many are the 80 to 90 percent of decisions that "have relatively minor influence on how well the design meets the customer needs." (p. 43, v 4.0)

The vital few decisions should take most of the design time/effort. Mattson and Sorensen say 80-90 percent of the work should involve the vital few decisions. However, these percentages seem more like conceptual ideas than true statistics.

And then this meta observation:

"One of the key decisions you will make in the design process is the decision about which choices are vital and which choices are mundane"

– Mattson and Sorenson, p. 43, v. 4.0

Goal Pyramid

Another way of prioritizing design decisions is to look at customer requirements and performance specifications in a hierarchy of importance.

Figure 1 is a slightly adapted version of the goal pyramid for performance metrics from the 5th edition of the textbook by Mattson and Sorensen. The pyramid suggests a hierarchy of goals, with higher level goals distinguishing excellent and exceptional products from merely ordinary products. The pyramid also suggests that higher level goals rest upon lower level goals. Thus, an excellent product that meets or exceeds the key requirements, must also satisfy basic requirements and constraints.

The bottom level of the pyramid consists of basic requirements and constraints. A constraint is a yes/no requirement that must be satisfied in order for the product to be viable in the market. For example, an on/off switch would be a constraint for most electronic devices. What customer would find it acceptable that turning the device off required either unplugging it or removing the batteries?

Constraints are different from basic requirements because as long as a constraint is met, there is usually no additional benefit from exceeding the performance specification associated with that constraint. In that way constraints are like boundaries on what is acceptable. As long as you are inside the constraint boundary, the device is viable. Moving further away from the constraint boundary has little benefit. For example, adding a second on/off switch to an electronic device doesn't improve the performance, and may actually harm the product by driving up the price or providing confusing features.

Basic requirements are different from constraints in that basic requirements are likely to have a range of acceptable values. Thus, it may be possible to adjust or trade-off the targets for individual basic requirements as a way of satisfying the overall set of basic needs of the market. For example, an automatic drip coffee maker would have an on/off switch (a constraint), and a carafe of sufficient size for holding the brewed coffee. The volume of the carafe would be a basic requirement: as long as the volume is in acceptable range (say 10 to 12 cups), there is no significant benefit from optimizing the volume as a performance metric. Nevertheless, the volume of the carafe needs to be considered as a performance metric because there is certainly a minimum value for the volume that would be acceptable and an upper limit on the volume that would not be practical.

Key requirements distinguish excellent products from ordinary products. Continuing with the example of the coffee maker, a key requirement might be the length of time that the coffee remains hot without developing a bad taste. Design effort to optimize the stay-hot-time will make a bigger impact on customer satisfaction than effort to optimize the volume of the carafe, or adding additional on/off buttons. Another key requirement is likely to be cost, which may be in conflict with, or limit, design choices to increase the stay-hot-time. The important idea is that once constraints and basic requirements are satisfied, the team should work to optimize the key requirements.

Implicit in this discussion of the goal pyramid is the need for appropriate goal setting. While interviews with customers and other market research will identify many market requirements, appropriately classifying the requirements as basic or key is a prerequisite to decisions about how the team should expend its human efforts and budget. Therefore, Mattson and Sorensen recommend that only a limited number, say 5 to 10, requirements are considered to be key.

The last category in the goal pyramid are stretch goals, which are beyond the key requirements. A design that achieves a stretch goal is better than excellent. It is exceptional. However, it may not be possible given the resources of the team or the budget for the product to achieve a stretch goal. Therefore, stretch goals are optional. The product is likely to ship before the stretch goal is achieved. Teams should consider stretch goals only after they are confident that their design will meet or exceed the key requirements. Furthermore, reaching for a stretch goal should not compromise performance on the key requirements.

---

References

1. Christopher A. Mattson and Carl D. Sorenson, Fundamentals of Product Development, 5th ed., 2017, Brigham Young University.

2. Amos Tversky and Daniel Kahneman, Judgement under uncertainty: heuristics and biases Science, vol 185, no 4157, Sep. 27, 1974, pp. 1124-1131, available via JSTOR as https://www.jstor.org/stable/1738360

3. Buster Benson, Cognitive bias cheat sheet, https://betterhumans.coach.me/cognitive-bias-cheat-sheet-55a472476b18