21

First Edition

20
Design Decisions

0-
Integrated Product Design

02
e2 Handbook
ton
ps
Ca

BRIAN MAZZEO
U
BY
 21
20
Design Decisions

0-
Integrated Product Design Handbook
Brian Mazzeo

02
e2
ton
ps

First Edition
Ca

© 2020 Brigham Young University

All Rights Reserved
Ira A. Fulton College of Engineering
701 E University Pkwy, 450 EB
U

Provo, UT 84602
BY

ISBN 9798675117789
BY
U
Ca
ps
ton
e2
02
0-
20
21
 iii

TABLE OF CONTENTS

21
Preface iv

20
Chapter 1. Design is Decision 1

0-
Chapter 2. Design Decision Cycle 11

02
Chapter 3. Decision Stage: Design Drivers 19

Chapter 4. Decision Stage: Design Divergence 29

e2
Chapter 5. Decision Stage: Design Details 37
ton

Chapter 6. Decision Stage: Design Deployment 47

Credits 55
ps

Index 56
Ca
U
BY
 iv

Preface

21
Why write another handbook when there are already so many
design textbooks available?
This project started as the BYU Capstone program evolved and

20
integrated more engineering disciplines, specifically electrical
and computer engineering, and enlarged to over three hundred
students and more than forty product design teams every year.
Various projects and interactions with sponsors led to a much

0-
broader view of product development. This handbook was
designed to quickly address larger themes without indoctrinating
engineers with any particular design philosophy or process.

02
Technological developments are changing the way people are
working and designing. Computing technologies, whether
high-fidelity simulations or artificial intelligence, are increasingly
being used to help decision-makers decide how to deploy
e2
resources. Additionally, speed and agility have transformed
the product landscape due to feedback obtained through rapid
hardware development, 3D printing, continuous software
releases, and almost-immediate interactions with the market. The
shanzhai design processes have changed the ways products are
manufactured, reducing the development cycle to time frames
ton

measured in days. Agile teams can rapidly move forward if the

feedback loop is short enough. For example, startups and software
companies iterate daily, if not hourly.
Decisions are not driven only by local considerations. When
ps

viewed within the framework of design decisions, decisions to

outsource or manufacture far from the design team are design
decisions with associated risks and rewards. Thus, while engineers
are drawn primarily to numbers to define performance, other
considerations such as opportunity costs, ethics, and societal
Ca

impact must be included in evaluations of product design.

There are as many development processes as there are
organizations. Because of this, the point of view of this handbook is
to talk specifically about the central role of design decisions, which
is then supplemented by how, what, and when questions naturally
U

arising out of processes necessary for product deployment. This

deliberately-lightweight approach is intended to provide an easily-
understood and useful conceptual framework to carry out product
BY

design in many contexts.

 v

This project would not have been possible without the influence,

21
support, and feedback from many colleagues. In particular, Carl
Sorensen, Christopher Mattson, David Long, Brian Jensen, and
Allyson Gibson have been key contributors to the ideas contained
in this handbook. The design of the handbook was developed by
Lauren Hurst and Katelynn McKinnon.

20
For convenience in working with our Capstone class and for fur-
ther exploration of selected design topics, additional readings are
recommended from:

0-
Mattson, Christopher A., and Carl D. Sorensen. Product De-
velopment: Principles and Tools for Creating Desirable and
Transferable Designs. Spinger Nature, 2019.

02
I hope that you enjoy making design decisions as part of your own
product development journey.
BRIAN A. MAZZEO
e2
Provo, Utah, August 2020
ton
ps
Ca
U
BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 1
ps

Design is Decision
Ca
U
BY
 2 Chapter 1

Chapter 1. Design is Decision

21
On July 20, 1969, Neil Armstrong set foot on the moon. The Apollo
Program, with its goal of sending and returning humans to and from the
moon, required vision, tremendous expenditure of resources, and the
combined efforts of thousands of engineers. A substantial portion of the

20
resources of the entire United States centered on the success of a single
rocket system.
When fueled for flight, the 111-meter tall Saturn V launch vehicle

0-
weighed 2.8 million kilograms. It could lift not only a spacecraft but also
the lunar module and supplies for three humans to travel to the moon
and return safely home. It remains one of the largest and most powerful
vehicles ever built (Figure 1-1). Looking over history, major engineering

02
design feats like the Apollo Program are awe-inspiring.
e2
ton
ps
Ca

Figure 1-1. Apollo 10 Saturn V rocket during rollout.

The amount of design work invested in the Saturn V rocket was as enor-
U

mous as the rocket itself. Engineers drew designs on paper, transferred

design details to production facilities, and manufactured components.
Entire buildings and complexes were constructed to produce the rocket
BY

design.
An early computer was at the heart of the Apollo missions to the moon.
Humans were not up to the task of the number of navigation calculations
 Design is Decision 3

necessary to pilot to the moon or land on its surface. The Apollo Guid-

21
ance Computer (Figure 1-2) enabled astronauts to successfully pilot the
spacecraft and lunar module over half a million kilometers.

20
0-
02
Figure 1-2. Apollo Guidance Computer.
Thousands of individuals worked together to produce the design of
a reliable rocket capable of navigation to the moon and back. It was a
e2
triumph of management, labor, and effort, but it was also a triumph of
product design.

Designers make Decisions

A rocket or any other engineered object, digital or otherwise, is the
ton

embodiment of multiple design decisions. The Saturn V is the result

of decisions that ranged from the entire mission trajectory to the sizes,
materials, and placement of individual bolts. When the draftsman drew a
component in 1960, he had to make decisions about each line or arc. The
sum of those decisions resulted in a product that was fabricated, tested,
ps

and flown.
The purpose of engineering design is to make decisions. A design is sim-
ply the embodiment of decisions to achieve a particular task. That task
Ca

may be to develop a rocket, an assembly line, or software for a mobile

device. The product is the result of the grand sum of individual design
decisions.
There are two types of design decisions: direct decisions and delegat-
ed decisions.
U

• Direct decisions are those that you make personally with

the information you have at hand. The decisions may be how
to create the next line of a computer code, the hole chamfer
BY

diameter, or whether to move the start date of the next phase of a

multi-billion-dollar plant expansion. You are responsible for the
direct decisions that you may make, even if they are influenced
by the decisions of others.
 4 Chapter 1

• Delegated decisions are those that you assign or leave to

21
others, human or otherwise. For example, a delegated decision
may be how a 3D printer nozzle actually extrudes material to
build up layers. That decision is automated by thousands of lines
of computer code written by someone else. By choosing to use
the printer and its associated software, you are delegating im-

20
portant decisions to the printer to achieve the desired outcome.
Outsourcing aspects of the design, or giving design assignments
to members of your team, are examples of delegated decisions
because details of the design are determined by others.

0-
Depending on the structure of the organization in which you are work-
ing, your ability to make direct decisions and delegated decisions may be
dictated by the organizational structure. Managers may delegate deci-

02
sions about specific component specifications to you and make direct
decisions about who within the organization receives those delegated
decisions. Further, you may make the direct decision now to delegate
decisions to your future self.
e2
A direct decision within the Apollo program was to delegate important
navigation and control decisions to software running in a computer. The
computer did not make the final decisions regarding the ultimate mission
plan, but it was central to providing information to the decision makers
within the command module of the spacecraft and the mission control-
ton

lers on the ground. Importantly, as new information was received during

the course of a mission, some decisions were revised. The need to make
good decisions under time and resource pressure is common to all
design and deployment phases of a product.
ps

Engineering Decision Environment

Major tensions in the workplace arise over how, when, and by whom de-
cisions are made. If you, as a designer, can understand your Engineering
Decision Environment (Figure 1-3), you are better positioned to make
Ca

decisions. You need to understand which decisions you can delegate and
which decisions are your responsibility. For example, you can delegate
some decisions to the suppliers and manufacturers that may support your
product, but you may need to provide the specifications of that product.
It is important to understand which decisions have already been made
and cannot be changed, and which can be changed. An example of the
U

former could be the product feature set predetermined by a pre-existing

contract in place before you began working on the product. Once the
BY

Engineering Decision Environment is clear, you can successfully operate

and make design contributions in that space.
 Design is Decision 5

When you make the direct decision to use an off-the-shelf component in

21
your design, you delegate decisions related to the design of that compo-
nent to the component supplier. You delegate engineering and optimi-
zation decisions (such as component specifications and packaging) and
you also delegate decisions about the vendor supply chain. For example,
to meet a particular communication specification for a wireless protocol,

20
you often prefer to use off-the-shelf components to reduce the number of
direct decisions that your organization must make. You then pay for the
embodiment of decisions made by the supplier when you purchase com-
ponents and include them in your design. Others then pay your organiza-

0-
tion for its embodiments of your decisions in the larger design.

02
e2
ton

Figure 1-3. The Engineering Decision Environment in which you

receive delegated decisions, make direct decisions, and delegate
decisions to others.
ps

Computer systems can facilitate making decisions. There is always risk

in delegating the decision to a computer system, but you take that risk
to enable you to focus on the direct decisions within your Engineering
Decision Environment. When milling a component on a CNC machine,
Ca

you trust that the software that is operating the CNC will accurately make
the specified cuts. Usually, the computer system is more reliable than
a human operator for repetitive, tedious tasks. However, the machine
cannot determine how the part will interface with other parts. Delegated
decisions come with both risks and rewards.
U

Design Decisions Require Resources

Resources and time are required to make engineering design decisions.
BY

It may require a nanosecond of computing time or a thousand per-

son-hours. Consulting a subject-matter expert can enable you to obtain
information that would take years to acquire otherwise. Some decisions
 6 Chapter 1

require substantial periods of time, no matter what financial resources are

21
available. For example, medical trials cannot be rushed. How efficiently
you use the resources available, both time and financial, determine how
quickly and effectively you can make necessary design decisions. Your
personal compensation is often tied to the decisions you make to develop
products that your organization brings to the market.

20
The cost of decisions greatly influences the length of time and the re-
sources allocated to make them. When updates are easily made, it is less
conequential to make necessary revisions. A software update can happen

0-
in milliseconds. Because of advanced manufacturing methods and rapid
prototyping, design development times are shrinking from years to
months to days to minutes. Other decisions are much harder to rectify.
Tool costs and manufacturing setup dictate long design cycles. They also

02
dictate the investment of time necessary to allocate to decisions.
As the cost and time of revision decreases, the design process evolves for
greater flexibility despite the principles remaining constant. The amount
e2
of time in certain portions of a design process may vary or, for example,
development of decisions may be allocated less resources.
Managing many designers is a challenge. Decision costs must be calculat-
ed, either implicitly or explicitly, and given appropriate resources if good
decisions are to be made. Any critical decision that significantly affects
ton

budgets for a product development project will also need to have such a
decision justified explicitly.
Because managers and stakeholders want decisions to be made quickly,
people often think that the more resources thrown at a problem, the
faster it can be solved. Sometimes, that may be the case when prototyp-
ps

ing costs are high and iteration could be accelerated by more money.
However, the decision-making process is more often people-based and
limited by the cognitive resources of the team. Adding more people often
complicates and slows down the decision-making process. Therefore,
Ca

in the long-term, more people may help, but in the short term it can be
counterproductive.
The best solution for obtaining more design productivity is to remove the
barriers for the individuals in making design decisions. Removing dis-
tracting tasks from the designer’s plate can allow them more concentrat-
U

ed time to make good decisions necessary to advance a particular design.

Market Evaluation of Engineering Decisions

BY

A product is deployed when all the necessary decisions are made to

produce the product. Your decisions and delegated decisions are embod-
ied in the product. Whether or not the set of decisions was successful is
 Design is Decision 7

determined by the market response to your product. Desirability and

21
deliverability evaluate your design decision set.
• Desirability is how pleasing your product embodiment of the
decision set is to product receivers. For a commercial product,
the measure of desirability may be the number of consumers

20
who repeatedly purchase the product. For a software product,
this may be the number of hours of engagement with the prod-
uct. Another measure of desirability may also be the reactions of
the management who initiated the product.

0-
• Deliverability refers to the ability of the solution to be trans-
ferred, adopted, deployed, and improved by the organization
receiving the set of design decisions. It includes all of the spec-
ifications, drawings, tests, and code necessary to produce the

02
design, and also captures the decisions of the design process to
enable future users of the decisions to understand past decisions
and make future decisions to improve the design decision set.
e2
While the design team may make decisions related to a design, the team
cannot adequately evaluate the decision results. Ultimately, the market
evaluates the set of decisions. When a company releases a product, mar-
ket performance is predicted, but the design team does not know how
the product performs until others evaluate and use the product. Other
factors, such as a competing product, may cloud evaluation of market
ton

performance. In any case, evaluation of the design decision set is not

possible for the design team to do itself.
Learning to make good decisions is the key skill of a competent engineer.
It is not enough to make decisions, though. Those decisions must be
ps

communicated to others to advance the design decision set and produce

the product, which may require additional decisions delegated to others.
Because decisions must be communicated, understood, and possibly
revised, each engineer must produce the evidence necessary to retrace
those decisions. This is done through design artifacts.
Ca

Design Artifacts
A design artifact is an object used to capture the decision-making
process. Just as an archaeologist (Figure 1-4) tries to determine how
an ancient civilization lived and worked in the past by collecting and
U

studying artifacts, the decision-making process is evident through the

design artifacts that you produce. It should not take someone a decade
of studying your design artifacts to understand what it is that you were
BY

trying to do!
Good design artifacts capture information necessary to reproduce your
work, understand your work, and understand the resulting decisions that
 8 Chapter 1

21
20
0-
02
Figure 1-4. Like in archaeology, design artifacts enable others to
e2
understand the hows and whys of the decisions made advancing the
design.

were made. Artifacts can be as simple as comments in code, the Unified

Modeling Language diagram associated with your software architecture,
ton

or the sketches made to figure out how two parts will fit together. Just as
the design package of technical drawings is transferred to the workshop
floor to be produced, the artifacts must be clear to other designers and
fabricators to understand the decisions that were made.
Many engineers hate the words “paperwork” or “documentation”, think-
ps

ing that somehow these activities are worthless or do not contribute

to design. However as many experienced engineers will tell you, if the
previous engineer had left better notes about how they did certain things,
they wouldn’t have had to “reinvent the wheel” over and over again. But,
Ca

more importantly, the process of documenting work actually helps to

reorganize thinking within the designer’s head, which enables them to
better synthesize their ideas in order to communicate them clearly to
others. Product design progresses when decisions are properly recorded
and clearly communicated via design artifacts.
U

Good documentation can last decades and be studied long after it was
originally used in the product for which it was intended. A good exam-
ple of this is the software listings for the Apollo Guidance Computer
BY

(see Figure 1-5). Software decisions the designers made ended up being
critical to the entire success of the Apollo lunar landing in 1969. Many of
 Design is Decision 9

the first principles associated with

21
software engineering came from
this ambitious project. Because
the documentation was retained,
many others have learned from
their ambitious and pioneering

20
work.
While engineering design has
many flavors and has been debat-

0-
ed for decades, product design
decisions are fundamental to the
ultimate success of a project. As
a designer, you operate as part of

02
an Engineering Decision Envi-
ronment in which your decisions
Figure 1-5. Margaret Hamilton and contribute to the overall body of
the software listings produced by her decisions that define the product.
e2
team for the Apollo project.

End-of-Chapter Questions
ton

1. How can product design be viewed as a series of decisions?

2. For a design project you are considering, what is the engi-
neering decision environment in which you are operating?
3. In your engineering decision environment, what decisions
have been delegated to you and are now your direct decisions
ps

and what decisions can you delegate to others?

4. How does the market evaluate the set of design decisions
embodied in a product?
5. How do design artifacts contribute to the deliverability of an
Ca

engineered product?those decisions need to be revisited?

Additional Readings
U

1. The concepts of desirability and deliverability are explored

through the concepts of desirability and transferability on pages
BY

5-7 of Mattson and Sorensen.

2. Design artifacts are explored on pages 7-8, 18-19, and 27-31 of
Mattson and Sorensen.
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 2
ps

Design Decision Cycle

Ca
U
BY
 12 Chapter 2

Chapter 2. Design Decision Cycle

21
As a designer, the pertinent question is often: What is the next step in the
product design? The reality is that there are many design processes used
in practice. Fortunately, many processes share fundamental principles.
For many designers, like riding a bicycle (Figure 2-1), the motion of the

20
design process becomes so intrinsic that they are not conscious that they
are executing the Design Decision Cycle over and over again. For young
designers, the cycle can feel awkward, but practice makes the steps famil-
iar and natural. This chapter focuses on the routine steps that a designer

0-
executes when facing design decisions.

02
e2
ton

Figure 2-1. Cyclists continually repeat motions in order to

reach their destinations as they make decisions.
ps

The overall Design Decision Cycle order is general to many design en-
vironments. The cycle is often layered because multiple individuals and
teams are consistently running through their own design decision cycles
Ca

for delegated decisions required to make other dependent decisions. This

leads to cycles within cycles. When one cycle is finished, it often leads to
another cycle where the most recent decision forms the framework for
the next decision. This process continues towards targets that are set by
the milestones for each product design.
U

The Design Decision Cycle is illustrated in Figure 2-2. The individual

steps of the Design Decision Cycle are to (1) Determine the Decision,
(2) Diverge in the Decision Space, (3) Develop Potential Decisions, (4)
BY

Deliberate on Decisions, (5) Decide on Decisions, and (6) Document the

Decisions. The following sections elaborate on these steps.
 Design Decision Cycle 13

Determine the Decision

21
Without an adequate understanding of the decision to be made, none of
the other activities can be conducted. In software, the next line written
is a decision, or it may be the organization of different software modules,
or it may be the specifications for the user interface. For a mechanical

20
design, it may be the thickness of a bar holding a joist, or the selection
of the appropriate material for the bar from among different plastics. An
electrical design might need selection of the operational amplifier that
meets the specifications. These are decisions that advance the design.

0-
Determining that a decision is necessary to advance the design is critical
so that resources to make that decision can be allocated. A good question
to ask oneself when stuck is, what is the next critical decision that needs to
be made in order to advance the design towards completion and deploy-

02
ment?
e2
ton
ps

Figure 2-2. The Design Decision Cycle.

Diverge in the Decision space

Ca

Divergent thinking in the decision space is the creative process where

information is gathered and solutions are proposed to enable the designer
to make an informed decision. Divergent thinking is creative and explores
the decision space. Artificial intelligence and process selection tools can
be helpful for divergence within the decision space.
U

In software, diverging consists of considering alternative implementation

and architectures that might be possible to solve the problem at hand.
There are often many different ways to solve the problem. Considering
BY

alternatives is important. In mechanical designs, this may require calling

up different vendors to determine what options might be offered as possi-
ble solutions. Divergence can be a step that takes a long time as an entire
 14 Chapter 2

team comes up with different solutions to solve the problem or it may

21
take a matter of seconds for an engineer to rapidly consider alternatives.
Divergence is the process to come up with alternatives. While brain-
storming is often associated with divergence, brainstorming needs to
be informed by the decision to be made as well as the constraints and

20
decision space available to the designer. Refraining from early judgment
allows more solutions to be suggested. A large quantity of high-quality
options is more likely to result in a final decision that best addresses the
challenges at hand.

0-
Develop Potential Decisions
Potential decisions must be developed to explore decision consequences.

02
The detail at which this must be done and the time allotted are design
process decisions. Prototyping can play a key role. For example, soft-
ware engineers may develop potential decisions by executing them on a
computing platform. 3D printing allows potential mechanical solutions
e2
to be explored within minutes. These tools are important to inform the
decision-making process.
Other examples of potential decision development include:
ƽ Back-of-the-envelope calculations outlining order-of-magnitude
ton

parameter spaces
ƽ Executing lines of code to establish the viability of an algorithm
ƽ Cardboard system mockups to explore functional characteristics
ƽ 3D printing of key elements to explore form, fit, and function
within an enclosure
ƽ Finite-element stress analysis to estimate load-bearing capacities
ps

ƽ Injection-molded parts produced to measure process variations

ƽ Estimation of supply chain risks by examining multiple sourcing
agreements
Ca

Without sufficient development of particular solutions, you cannot

adequately predict the consequences of decisions to know whether to
reject or accept the particular solution. You must schedule and allocate
resources to decision development so there is sufficient time to explore
the design space. However, one must avoid the temptation to spend so
much time developing within a decision space that the time to make
U

critical decisions is lost. Often, this happens when prototyping becomes

more important than decision-making. Skilled engineers do not use
more resources than necessary to make decisions.
BY

Deliberate Decisions
Before making a decision, deliberation (thoughtful consideration and
 Design Decision Cycle 15

discussion) is an important step to evaluate the developed potential deci-

21
sions. There are many ways to deliberate. If it is done as a group activity,
team members may vote for particular decisions or give numerical scores.
Ranking and scoring matrices can be used to evaluate potential solutions.
Elaborate tables may be constructed. For software and numerical simula-
tion decisions, the decision deliberation may involve evaluating whether

20
code functions correctly. This evaluation may be automated. In all cases,
an evaluation of some type must be made about the quality of the deci-
sion options being evaluated.

0-
Even if a particular tool or method is used to deliberate about the deci-
sions and produces recommendations, it is important to holistically eval-
uate the decision. Tools are merely instruments to supplement thinking,
but they do not replace judgement. Some factors that are part of the de-

02
liberations cannot be measured. For example, the design decision to lose
money on a product may be deliberately made in order to gain market
share or create a platform for future lucrative activities. While engineers
often rely heavily on numbers, sometimes numbers can blind designers
e2
to other factors that may not be captured fully in numerical measures.
Deliberation should include your subconscious evaluations of the choices
presented. Counseling and deliberating openly as a team enables more
people to participate in the decision process. Nevertheless, as with other
steps, it is often a good idea to limit the personal time and resources allo-
ton

cated to deliberation in order to make decisions in a timely manner.

Decide
Finally, a designer must commit to a particular decision. Whether this
comes from a vote by the team, or a team leader makes a decision, or a
ps

programmer commits his code to the repository, the decision to decide

and move on must be made.
All the previous steps lead up to this crucial step in the process. Some
Ca

designers are driven by fear of committing to a decision because that de-

cision may limit further exploration. Indeed, some decisions may need to
be reversed in the future, even if they are made after careful deliberation.
But, postponing decision-making can often be a major reason that teams
get stuck. Deadlines, set either internally or externally, can help motivate
the designer to make a decision.
U

Document the Decision

Reflecting on ten years of development of TeX, the typesetting engine of
BY

the document preparation system, LaTeX, Donald Knuth said:

“TeX would have been much less successful if I had not put considerable
 16 Chapter 2

effort into writing a user manual for it myself. The process of explaining

21
the language gave me views of the system that I never would have per-
ceived if I had merely designed it, implemented it, and used it.”
-Donald E. Knuth, TUGboat, Volume 10 (1989), No. 4- 1989
Conference Proceedings, page 530

20
It is critical to note that without capturing the decision and steps lead-
ing to a decision, the value of the decision is diminished. You need to
communicate your decision to other stakeholders. Decision-making
artifacts are supporting evidence. Documenting steps you took and why

0-
you made certain choices helps solidify the decision by consolidating the
thinking processes you went through in making the decision.

02
Additional information may also come to light later in development. For
example, a new manufacturing method may be proposed or a competitor
may release a product with a similar feature set. If your decision docu-
mentation is well done, this new information can be incorporated into
your decision-making process without having to start over from scratch.
e2
Documentation truly captures the design decisions that constitute a
product. Without it, the design only exists in the mind of the designer
and it cannot be followed by someone else. Because technology and
business considerations change, revision to documentation is necessary
to inform future design decisions.
ton

As previously noted, documentation helps the designer clarify their

thinking. Documentation of decisions also serves as instruction for
future designers.
ps
Ca
U
BY
 Design Decision Cycle 17

21
End-of-Chapter Questions
1. How does the Design Decision Cycle capture needed ele-

20
ments to make informed design decisions?
2. For a design project you are considering, how can you use the
steps of the Design Decision Cycle to address a decision that
you are facing?

0-
3. How do time and resources affect the speed through which
you move through the Design Decision Cycle?
4. How does the ease to make revisions to decisions affect
how you employ the Design Decision Cycle in your design

02
process?
5. For a design project you are considering, what documen-
tation is necessary to adequately capture decisions and to
lay appropriate groundwork if those decisions need to be
e2
revisited?

Additional Readings
ton

1. The Design Decision Cycle is similar to the Basic Design Pro-

cess outlined on pages 168-169 of Mattson and Sorensen.
2. The design skill of Deciding is explored on pages 42-44 of
Mattson and Sorensen.
ps

3. Some examples of tools that may help in divergent thinking

include Brainstorming (176), Method 635 (236), and SCAMPER
(284) of Mattson and Sorensen.
Ca
U
BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 3
ps

Decision Stage: Design Drivers

Ca
U
BY
 20 Chapter 3

Chapter 3. Decision Stage: Design Drivers

21
While the Design Decision Cycle is an individual process executed
multiple times as you work through development of a single product,
many organizations have established additional processes and stages for
releasing a product to the market and coordinating the efforts of many

20
people. Most product development projects require teams of people
working together. People working together require management to
achieve development objectives. In the modern era this is often compli-
cated because product development is a global process and often requires

0-
groups of individuals to work together all over the world in a 24-hour-
a-day business day. Without skilled product management, chaos ensues
and product development progress is hindered.

02
Even when people are talking about products, it is important to remem-
ber that products are the embodiment of decisions. As part of a team,
you are delegated a set of decisions individually and collectively. Your
documented decisions are contained in design artifacts that are commu-
e2
nicated across your organization and become incorporated with other
decisions to deploy your product (Figure 3-1). A product design is com-
plete only when all of the decisions have been made that are necessary to
deploy the product.
ton
ps
Ca

Figure 3-1. Product design is amalgamation of documented decisions

into a product.
U
BY

Four Design Decision Stages are used to describe the evolution of

product design from start to finish. These stages are described in broad
strokes, emphasizing principles, as there are as many design decision pro-
cesses as there are organizations. These stages are shown in Figure 3-2.
Progression through the stages implies increasing amounts of resources
 Decision Stage: Design Drivers 21

invested, as well as the increase in quantity and quality design decisions

21
and their associated design artifacts created as teams move through the
stages.

20
0-
02
Figure 3-2. Design Decision Stages capture the in-
crease in quantity and quality of design decisions.

Foundation for Product Development Success

e2
The first Design Decision Stage consists of identifying the Design Drivers
setting the trajectory for the entire process. These drivers include the
system “requirements” or “specifications” as determined by the project
Scope as well as the project Schedule and available Resources. Many
times, the Design Drivers can be revised as the design decision process
evolves, but it is important to set a good foundation on which to build the
ton

rest of the activities. Without consciously going through this stage, it is

often common for inexperienced designers to assume that they know the
specifications for a project, only to have to revise the specifications later as
new information comes to light. While some revision is inevitable, reduc-
ing revisions increases the efficiency of the entire process. Late revision of
ps

the initial specifications can cause great difficulties in the design decision
process.

Scope, Schedule, and Resources

Ca

Three important factors determine the way that projects are programmed
within organizations: scope, schedule, and resources. Scope defines the
measurable, technical objectives of the project. Schedule is the organiza-
tion of dates defining when certain performance objectives must be met.
Resources are the human capital, physical materials, money, facilities
U

and supply chains available to be allocated to the project.

Different industries have different business models and those models in-
BY

fluence the types of decisions processes that are employed by the organi-
zation. Flexibility in one category or another allows for alternative design
processes. If a contract has specific deliverables on certain dates with pen-
alties incurred if these dates are not met, then these drive a schedule-driv-
en design process. If the scope is well-defined, adequate resources are
 22 Chapter 3

allocated and the team is set, but flexibility in schedule is available, then

21
a more iterative or spiraling development process can be used. Software
projects often fall in this category. Open source programming projects
may have high variability in all three categories.
As a project evolves, scope, schedule, and resources may need to be

20
negotiated with management and external organizations. In general, if
the scope expands, it must be met with a longer delivery schedule and/
or additional resources. If resources decrease, then either the schedule
must be pushed back or the scope reduced. These relationships often can

0-
become a source of tension, especially when time is running out to meet
certain project objectives.

Determine Product Requirements

02
An initial design artifact for a product is the generated set of require-
ments, which are definitions of the needs and wants for a product. A
skilled designer realizes that generating and specifying requirements is
e2
essential to allocate the resources available for product development.
The first step in developing requirements is to gather information nec-
essary about the product and its intended functions. As shown in Figure
3-3, this often means doing a lot of work to understand the context of
the product. Interviews, use cases, and focus groups may be used. Often,
ton

studying competitive products and even taking those products apart to

understand how they are constructed are activities that may inform the
design team about what is feasible and what features may be necessary to
be competitive in the market.
ps
Ca
U

Figure 3-3. Developing requirements involves collection of market data

BY

and observations from and about end-users and decision-makers, deliber-

ating about the collected information, and finally distilling down to a few
requirements that define a project.
 Decision Stage: Design Drivers 23

Once sufficient information is obtained through market studies and

21
deliberation, this information is winnowed down to key statements that
describe the product. These statements are then distilled into a set of
statements that define the requirements hierarchy. It is important that the
requirements address consideration for public health, safety, and welfare,
as well as global, cultural, social, environmental, and economic factors.

20
Reiterating, the requirements generation process has three steps:
(1) collection of data from individuals, observations, focus groups,
and the Internet that describe the need for the product

0-
(2) creation of objective statements summarizing desired product
performance, and
(3) creation of quantitative performance measures that can be
assessed through testing.

02
It is important to identify the decision-makers that will be evaluating your
design. These decision makers may include other design and develop-
ment teams, or other key decision-makers in your market. Mass-mar-
e2
keting a consumer device to millions of people is very different than
decisions made in a business-to-business environment. Having repre-
sentatives of these decision-makers provide feedback during the Design
Drivers stage is important to make sure that the project has a strong
foundation.
ton

Some considerations are more important than others and should be given
more weight. These weights can be recorded as numerical scores in a
requirements table included in a Requirements Artifact that describes
the requirements and constraints for the project. Constraints are re-
quirements that must be met regardless of any other product performance
ps

measures. Ultimately, design is an iterative, decision-making process

to create a system, component, or process to meet desired needs and
specifications within constraints.
An example of a section of an initial Requirements Artifact is found in
Ca

Figure 3-4. When forming requirements, it is important to be comprehen-

sive. In this example, some statements are vague, such as screen shapes,
while some statements are very specific, such as the power plug types. You
should try to make the statements as specific and measurable as possi-
ble, but being complete is more important when making the first pass at
establishing requirements.
U
BY
 24 Chapter 3

21
A. User interface
1. Deployed on multiple screen shapes including mo-
bile devices and desktops
2. Language support offered for English, Spanish,

20
French
3. Meets 2010 ADA Standards for Accessible Design
B. Certification Standards

0-
1. Meets MIL-STD-498 Software Development and
Documentation
2. Meets ASTM F963 Toy Safety Standard

02
3. Meets IEEE 2413-2019 - Standard for an Architec-
tural Framework for the Internet of Things (IoT)

C. Power requirements
e2
1. Input: 120-240 VAC ~0.3 A, 50/60 Hz
2. Interchangeable plug types include Type A, Type B,
Type C, and Type G
3. Peak power: <30 W
4. Nominal operating power: ~10 W
ton

5. Sleep power: <0.1 W

Figure 3-4. Small section of a requirements hierarchy for a product.

ps

The set of requirements as given in the Requirements Artifact should be

approved by all the relevant stakeholders involved in the product design.
This is important because the requirements form the framework for all
the development stages. Change procedures may be in place to modify re-
Ca

quirements based on new information, but the initial set of requirements

specifies the entire direction of the project. The requirements form the
basis of the testing that takes place in later stages of the project.
Often, there are a few metrics that are more important than other met-
rics. For automobiles, these may be top speed or gas mileage. For mobile
U

devices, it may be estimated battery life or total weight. For software, it

may be execution time or the number of entries required to perform a
certain operation. These measures define overall product performance
BY

and are often used to compare one product against another. We refer to
these overarching, important performance requirements as Key Success
Measures. At the end of the day, while all the product requirements need
to be met, the product team should focus on ensuring the design achieves
excellent performance as given by these measures.
 Decision Stage: Design Drivers 25

Beginning the Product Development Journey

21
Understanding product Design Drivers is fundamental to successful
progress through the Design Decision Stages. It takes significant effort to
produce the requirements for a product and to establish design con-
straints. A few measures that define product performance, Key Success

20
Measures, may be chosen that highlight the performance of a successful
design. When the scope, schedule, and resources are then balanced and
appropriately allocated, the team is in a position to begin a successful
product development journey.

0-
Two important questions represent the outcomes from the Design Driv-
ers stage:

02
1. What are the complete product requirements?
2. How have you validated that the requirements and Key Success
Measures represent the market for your product?
e2
ton
ps
Ca
U
BY
 26 Chapter 3

21
End-of-Chapter Questions
1. For a design project you are considering, who are the key

20
market representatives that you can access to determine
the market requirements for your product?
2. How do scope, schedule, and resources balance against
each other in terms of meeting the design objectives of a

0-
project?
3. For a design project you are considering, which of your re-
quirements are constraints and which could be considered

02
Key Success Measures?
4. Explain how appropriately setting scope, schedule, and
resources in conjunction with requirements sets the trajec-
tory for the product design process.
e2
Additional Readings
1. The Design Drivers stage has much in common with the
ton

Opportunity Development Stage described in Chapter 4 of

Mattson and Sorensen.
2. Further thoughts about adjusting the scope, schedule, and
resources for a project are found in Customizing the Product
Development Process, Chapter 8, of Mattson and Soresnen
ps

3. Some examples of tools that may help in the Design Drivers

stage include Benchmarking (170), Catalog Search (180), Codes
and Standards (182), Cost Targets (190), Delphi Method (196),
Focus Groups (228), Goal Pyramid (230), Internet Research
Ca

(232), Interviews (234), Objective Tree (244), Observational

Studies (246), Patent Searches (252), Performance Measures
(254), Personas and Locales (256), Planning Canvas (260),
Product-Focused Requirement Statements (262), Project
Objective Statement (264), Requirements Hierarchy (274),
Requirements Matrix (276), and Surveys (298) of Mattson and
U

Sorensen.
BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 4
ps

Decision Stage: Design Divergence

Ca
U
BY
 30 Chapter 4

Chapter 4. Decision Stage: Design Divergence

21
The requirements laid in the first stage (Design Drivers) form the founda-
tion for the direction that product development takes place. The Design
Divergence stage is an exploratory decision phase carried out by a team to
select and develop a product concept.

20
At the beginning of the Design Divergence stage, the design team has
access to the Requirements Artifact and a decision space, which is the cre-
ative space in which the design team can make decisions. When a project

0-
begins, the decision space is large because almost anything and every-
thing can be done, theoretically. Beginning with a large decision space is
a good idea because the design team can explore new ideas, which often
lead to novel solutions and approaches. One advantage of having inex-

02
perienced designers on a team is that they can question existing norms
or incorporate recently developed technologies that may not have been
available to past design teams. Adding seasoned designers to the team
provides inexperienced designers with access to experience and technical
e2
expertise.
Both individual and group creative activities are essential in this stage.
Individuals can often explore different and alternative points of view
with more freedom when they are alone. Groups of individual working
together can build on the ideas of others. Managers should plan for both
ton

individual and group exploration in the design divergence phase. The

result of the initial creativity burst in this phase should be a set of possible
design decisions that have (1) high variety and (2) high quality. Variety
reflects the breadth of the ideas while quality represents sufficient explo-
ration to understand advantages and limitations of decisions.
ps

In this creative period, it can be helpful to have individual members of the

team come from diverse backgrounds to explore a wider design space and
give different perspectives and weighting when evaluating ideas. This is
Ca

particularly important when considering factors from the Design Drivers

stage such as public health, safety, and welfare, as well as global, cultural,
social, environmental, and economic factors. As part of the divergence
process, solutions targeting specific stakeholders from these contexts may
help to broaden the decision space and the search for optimal solutions.
As the process evolves and due consideration to requirements and
U

constraints is given, the decision space narrows and the range of possible
designs decreases. Learning to think broadly and then narrow the deci-
sion space to meet requirements is a valuable skill for a designer during
BY

this phase.
Just thinking about possible solutions is often not sufficient in order to
 Decision Stage: Design Divergence 31

make a decision about which solutions can actually meet the require-

21
ments and perform best. Multiple solutions need to be further developed
in order to make a single decision about which concept to pursue. All
of these decisions should be captured in design artifacts from the stage.
These decisions eventually lead to a single set of decisions. A complete
product concept is a visual and written description of the single final

20
feasible design decision set which is demonstrated by testing to meet the
product requirements. In the Design Divergence stage, demonstration
of potential design feasibility and performance is often accomplished
through simple prototypes and models.

0-
Prototyping
A prototype is a physical or digital exploration of a design aspect used to

02
make decisions.
It is critical to establish the purpose of a prototype before construction of
a prototype begins. Specifically, the design decisions on which the proto-
e2
type depends should be explicitly identified and referenced to the require-
ments. This helps the designer choose the level of fidelity of the prototype,
which should be appropriate for the design decision since prototypes
require time and other resources. Without dependence on specific design
decisions, designers may spend an inordinate amount of time prototyping
because, for many, the process of constructing prototypes is fun.
ton

Prototyping consumes time, financial, and material resources and thus

the fidelity should be chosen deliberately. A cardboard and duct tape
preliminary model may be sufficient to explore fit, form, and function of a
new hand tool. A basic circuit that uses key integrated circuit components
ps

may explore the noise floor for a new combination of devices. A basic
graphical user interface may be used to test how users interact with an
application interface. An algorithm flow chart or block diagrams may be
adequate for a software project. Prototypes may be small or large. Some
Ca

prototypes, such as concept cars, may be extremely expensive to fabricate

and may even be viewed by the public. Some prototypes are essential
design artifacts used to communicate design decisions to stakeholders.
As shown in Figure 4-1, prototypes come in all shapes, sizes, and varieties.
A part may be 3D printed in one material to explore certain questions
even if the final material for the design may be different. The key is that
U

the decisions that constitute the design are not the prototype itself.
Some prototypes, such as digital models that are used with finite-element
BY

analysis computational codes, can explore design spaces that would be

too costly to evaluate with physical objects. Loading parameters and safe-
ty factors can be derived by these models. Heat transfer can be visualized
 32 Chapter 4

and new solutions can be explored. However, even though digital models

21
can explore the design space with high fidelity and in novel combina-
tions, it is important to verify performance using physical representations
as digital models always suspend some aspects of reality.

20
0-
02
e2
ton

Figure 4-1. Prototypes can be physical or digital and are used to

explore the design space to make design decisions.

For software, prototypes may or may not be part of the final design. For
example, sometimes a short bit of code, storyboard, or graphical interface
ps

is created to make decisions about user interactions or functionality. How

much time is invested in the software prototype should be appropriately
gauged to answer key decision questions appropriate to generating a
complete product description. In the Design Divergence stage, writ-
Ca

ten software is generally concept-exploration driven and so should be

written with that purpose and goal. It may not be complete, or even in the
same language as the final product! The completed product concept for
software project includes all of the flow charts, interface mockups, and
decisions necessary to execute the entire design in its final form.
U

It is possible that some prototype software can become part of the final
delivered code base and so great care should be taken to make sure that
rapidly written code is structured effectively and documentation gener-
BY

ated to support its integration into the larger code base, should that be
necessary. It many cases, it makes sense to quickly produce software in
this stage to evaluate a concept, with the explicit expectation of the need
to re-architect the software in a subsequent stage.
 Decision Stage: Design Divergence 33

Concept Selection

21
The key to a successful Design Divergence stage is to eventually narrow
the concept design decisions to a single selected concept. Thus, while
the stage starts in divergence, it ends in convergence. This convergence
process can be fraught with complex and difficult design decisions.

20
The exploration of multiple design decisions simultaneously is a good
way to compare trade-offs and advantages of particular decisions. This
is important because, generally, it is impossible to have excellent perfor-

0-
mance in all areas. For example, enhanced wireless connectivity generally
requires more power which weighs against battery life. Or, holding more
passengers in a vehicle generally adversely affects fuel consumption for
that vehicle. Writing code in an interpreted language may be easier to

02
debug but its execution performance is typically lower than that of a
compiled solution. Weighing these choices is a crucial part of the design
convergence and selection process.
e2
It is often easier to make team decisions if objective metrics can be used to
score different decisions. Designers become invested in their designs and
become emotionally attached to their work. Therefore, scoring matrices
are often used to rank and compare different choices. In addition to the
many decision tools available to a design team, feedback from stakehold-
ers external to the team is essential to inform selection of the best decision
ton

among many competing decisions. Approval of the complete product

concept by the stakeholders allow the design team to confidently move
forward in their design process.

Diverging and Converging

ps

The Design Divergence stage is a creative, exploratory phase of the design

process in which many decisions are explored. Prototypes are used to ex-
plore the design space and make design decisions. Eventually, the design
team narrows the decisions down to a particular set which forms the basis
Ca

of the complete product concept which is approved by stakeholders and

lays the foundation for future development. Design artifacts from this
stage are particularly valuable as they represent decisions and innovations
that may be used to solve problems not only for the current product but
also other future products.
U

It is important to note that if the proposed design cannot be completed

within the project constraints then the design team may need to work
with stakeholders to either revise the requirements or to discard the com-
BY

plete product concept and seek another. For this reason, it is important to
determine feasibility of concepts before additional resources are invested
in the next Design Decision Stage.
 34 Chapter 4

Two important questions represent the outcomes from the Design Diver-

21
gence stage:
1. What is the complete product concept?
2. How have you validated that your complete product concept
decisions are best and meets the product requirements?

20
0-
02
e2
ton
ps
Ca
U
BY
 Decision Stage: Design Divergence 35

21
End-of-Chapter Questions
1. In the Design Divergence stage, how does divergence enable

20
exploration of new ideas?
2. Explain how design decisions should motivate prototyping
activities.
3. How does a complete product description capture the de-

0-
sign decisions in the Design Divergence stage?
4. For a design project you are considering, how can you vali-
date your complete product concept decisions?

02
e2
Additional Readings
1. The Design Divergence stage has much in common with the
Concept Development Stage described in Chapter 5 of Mattson
and Sorensen.
ton

2. Some examples of tools that may help in the Design Diver-

gence stage include Bio-Inspired Design (174), Brainstorming
(176), Catalog Search (180), Concept Classification Tree (184),
Controlled Convergence (186), Experimentation (218), Goal
Pyramid (230), Mind Maps (238), Method 635 (236), Multi-
voting (240), One Pager (248), Plan Do Check Act (Shewhart
ps

Cycle) (258), Quality Function Deployment (268), Rapid Pro-

totyping (270), Recombination Table (272), Revision Control
(280), Scoring Matrix (286), SCAMPER (284), Screening Matrix
(288), Sensitivity Analysis (290), Sketching (294), Storyboards
Ca

(296), Theory of Inventive Problem Solving (TRIZ) (300), and

Uncertainty Analysis (304) of Mattson and Sorensen.
U
BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 5
ps

Decision Stage: Design DeTails

Ca
U
BY
 38 Chapter 5

Chapter 5. Decision Stage: Design Details

21
Consider the disassembly of a digital camera shown in Figure 5-1. The
concept of the original digital camera and its specifications were set when
the product was conceived. However, for the product to be manufac-
tured, each of the individual components needed to be specified so that

20
the production system could fabricate each component and assemble the
parts into a single product, and test the performance of the assemblage.
Decisions about design details, specific information to produce and test
components, were required.

0-
Many types of engineers worked together to integrate the mechanical,
electrochemical, electrical, optical, digital, software, and industrial
design aspects into a single, producible set of decisions. Those decisions

02
were communicated across the production operations. Testing at every
stage was conducted in order to ensure that the components functioned
correctly and the entire system functioned as it should. Truly, it is a mir-
acle that products such as digital cameras do not cost more than they do,
e2
given the complexity and level of effort required to produce a single de-
vice. Mass production and global supply chains are technological marvels
that enable dissemination of engineered devices to the entire world.
ton
ps
Ca
U

Figure 5-1. Disassembly of a 2010-era digital camera.

A single designer cannot single-handedly produce a device such as a

BY

digital camera. It is a team effort. Software may involve thousands of

engineers working together. As previously discussed, because design
decisions for products cannot be made by a single person, decisions must
be delegated to different individuals and recombined into a single set.
 Decision Stage: Design Details 39

Decomposition is to separate the design into parts and delegate deci-

21
sions for parts in order to advance the complete design decision set. It is
often used to divide the original scope, schedule, and resources allocated
to the total project to smaller subsets of designers. For these delegated
decisions to be made effectively, the subset teams need to be aware of how
their component or process fits into the greater whole, that is, how the

20
various parts interface together.
Interfaces define the decision connections between parts of the project,
as well as between teams. They must be carefully defined and controlled.

0-
A Type A plug does not fit in a Type G socket. To effectively coordinate
these interfaces, interface control artifacts are drawn up for the subsys-
tem components in order to ensure that the overall composition of de-
sign decisions will perform adequately. These interface control artifacts

02
become part of the requirements artifacts for each part.

Design Architecture
e2
A product design architecture is the set of decisions describing decom-
posed subsystems and interfaces which define all components necessary
to produce a complete product concept. The architecture becomes the
roadmap to successful deployment of the product if all components deci-
sions are successfully made.
ton

The architecture may also include decisions to delegate decisions such as

acquiring parts and technologies that are not within the design capa-
bilities of the design team. For example, computer engineers acquire IP
software blocks from other design firms. Mechanical engineers acquire
actuators and motors from suppliers. A communications device must
ps

operate on a network owned by another entity. Licensing technologies

from other companies is a way for a design team to delegate decisions in
exchange for sharing future rewards.
When establishing an architecture, it is important to clearly delineate
Ca

which decisions of the architecture are delegated and which decisions

are made within the team. These decisions must be made within the
available scope, schedule, and resources. Because these decisions define
how development in this stage progresses, the architecture must clearly
determine what the product can and cannot do.
U

After an architecture is defined, stakeholders should approve the archi-

tecture in order to ensure that the architecture considers external factors
which might influence decisions that the team makes. Architecture deci-
BY

sions generally involve commitments outside of the design organization

with suppliers and so need to take into account business constraints that
may affect decisions. The amount and value of resources deployed in the
Details stage is generally an order-of-magnitude greater than the resourc-
 40 Chapter 5

es in previous stages because the design team is now engaging the indus-

21
trial mechanisms necessary to prepare for production of the product.

Test Procedures
While trust in individuals and decisions is integral to any design proj-

20
ect, design accountability is the assurance that particular subsystem
decisions meet the necessary performance and interface requirements
to be incorporated within the complete design decision set. The most
common way to achieve accountability is through extensive testing and

0-
verification.
In modern product development, testing is part of the decision set con-
stituting a product. Testing of all components must be performed, both

02
individually and as a system. This is required for both digital and physical
design representations. The extent of the testing is usually determined by
the severity of failure. For a billion-dollar single space probe sent millions
of kilometers into space, extensive testing of every aspect of the system
e2
is essential, while a disposable, single-use straw may not require much
testing. If software fixes can be implemented almost instantaneously
and failures have low impact, the testing requirements may be reduced
because of the ease of revision. However, if revision disrupts the end
user experience, for example, like automobile recalls, you want to ensure
that you have thoroughly tested your product decisions well before your
ton

product is widely distributed.

A test plan is necessary as part of the Details stage to achieve accountabil-
ity within the design team. Adequate resources should be provisioned to
ensure that the testing has both breadth and depth.
ps

The breadth of testing covers all the requirements for the product. A
requirement without a test is not a requirement that can be met. Require-
ment traceability matrices are often produced that link tests to each prod-
uct requirement. Some tests may be easy to perform, like the numerical
Ca

sum of all of the components in an assembly, or verifying plug compat-

ibility. Other tests may be extensive and require specialized equipment,
for example, to verify electromagnetic interference compatibility.
Testing depth indicates that passing a relevant test is indicative of actually
fulfilling the requirement. If a design requires waterproofing to 1 m depth
U

and the test is to submerge the object to 0.1 m, the test depth is not ade-
quate to indicate whether the design fulfills the actual product require-
ment. Teams should be self-critical in evaluating their tests to ensure that
BY

design decisions do not pass tests under laboratory conditions but fail
under real-world conditions after the product is released. Test procedure
creation is a skill that can be developed by any designer.
 Decision Stage: Design Details 41

A good design decision test:

21
1. Provides a standard foundation to verify performance.
2. Enables individuals who did not create the test to execute it
consistently.
3. Provides a sequential framework that can be followed precisely

20
each time the test is executed.
4. Produces verifiable data that accurately measures intended
performance.
5. Establishes evaluation criteria before the test is executed, remov-

0-
ing subjectivity in indicating test success.
Creating good design decision tests creates the standard framework nec-
essary for design accountability. When the design decision set passes the

02
appropriate tests, proposed decisions can be trusted and incorporated
into the broader product design decision set. The design decision test set
is often developed in parallel with creation of deliverable design artifacts
that contain production details necessary to deploy a design.
e2
Design Detailing
As demonstrated by the digital camera example, design decomposition
breaks the product design decisions into smaller, delegated decision
spaces that are each individually addressed by team subsets. Each
ton

decision space subset must additionally be detailed such that the deci-
sions for each space are documented, communicated, and tested in a
production-ready form to build up the complete design decision set. The
process of carefully creating and communicating subset design decisions
is known as detailing.
ps

For mechanical and electronic product designs, detailing consists of

generating the drawings necessary to communicate how to fabricate indi-
vidual parts. Even in the age of 3D printing and CAD-based production
systems, information such as fill factors, finish, and materials are included
Ca

in drawings to communicate how parts should be produced. Tolerances

should be carefully considered because part acceptance and production
costs depend on them.
For software designs, detailing consists of writing the code to making the
decisions necessary to complete the full system architecture. Detailing
U

also consists of the documentation, the comments, and conventions nec-

essary to communicate the design decisions that are being made. Expec-
tation of revisions should be made and so sufficient information should
BY

be given to facilitate quick and clear understanding. It should never be

assumed that the same programmer who created code will be the one
revising it. With that perspective, design decisions made when detailing
emphasize readability and clarity.
 42 Chapter 5

For all detailed design decisions, testing should be integrated within this

21
design phase. When a mechanical part is produced, the necessary tests of
performance should be specified. For software, testing should be inte-
grated within the code structure itself. When testing is considered while
designers are detailing, the tests are generally more comprehensive and
design flaws are discovered much more easily than when multiple com-

20
ponents are combined into more complex assemblages and systems. This
process and mindset naturally then results in specification of component
tolerances or data input checking to avoid future potential problems.

0-
Because testing and reevaluation of decisions continually take place in
this phase, typically according to the Design Decision Cycle outlined in
an earlier chapter, the expectation for revision is high. Thus, all design
artifacts produced to communicate design decisions should be construct-

02
ed to allow for revision and to capture the evolution of those revisions.
While only a subset of the entire design process, many engineers spend
the majority of their time detailing designs. Examining design detail-
e2
ing within the context of the Design Details stage gives the engineer
perspective in how their design decisions are combined into the entire
architecture decision set associated with a product. The detailing design
decisions, as well as all other design decisions and artifacts, are combined
in a final Design Package.
ton

Design Package
The design package is the complete set of decisions needed to produce
a complete product. Every aspect of the device must be detailed. Deci-
sions, such as created test procedures, are also included to verify per-
ps

formance at the component and system level. A design package should

allow a handoff to a production system so that a complete product can be
produced.
At this stage, a Bill of Materials (BOM) is also created which includes
Ca

all of the components defined by the architecture that are necessary to

complete the product. Generally, as part of the BOM, the availability,
sourcing, and volume pricing details are also included. Software included
as part of the BOM should be the software structure of the design team as
well as hardware and software dependencies necessary to run the com-
plete software design decision set specified by the architecture. A project
U

evaluator should be able to examine the BOM and understand all of the
materials needed to deploy the design decision set.
BY

The Design Details stage creates a project hierarchy in which all of the
product decisions are delegated to subsets of the entire product devel-
opment team. The architecture delineates the decision assignments
and draws on the resources of the organization and suppliers to make
 Decision Stage: Design Details 43

decisions. Individual designers detail components and tests to ensure ac-

21
countability. The end of the stage results in a design package which is the
synthesis of the design decisions that were made by all involved entities
to result in a single, deployable design decision set.
Two important questions represent the outcomes from the Design De-

20
tails stage:
1. What is the design architecture, and how do decisions combine
and interface to meet the system requirements?
2. Is the design package complete and how well does it define

0-
production and testing of design decisions?

02
e2
ton
ps
Ca
U
BY
 44 Chapter 5

21
End-of-Chapter Questions
1. How is design decomposition used to produce the needed

20
decisions to deploy a product?
2. How do test procedures contribute to design accountabil-
ity?
3. For a design project you are considering, how do you in-

0-
corporate revision as design detailing is being performed?
4. How does the design package represent the set of decisions
necessary to produce and ensure performance of a design
decision set?

02
e2
Additional Readings
1. The Design Details stage has much in common with the Sub-
system Engineering Development Stage described in Chapter 6
of Mattson and Sorensen.
ton

2. Some examples of tools that may help in the Design Details

stage include Bill of Materials (172), CAD Modeling (178),
Codes and Standards (182), Cost Estimation (188), Decom-
position (194), Design for Assembly (198), Design for Manu-
facturing (200), Design of Experiments (202), Design Review
ps

(204), Design Structure Matrix (206), Drawing Checking (210),

Drawings (212), Engineering Change Order (ECO) (214),
Ergonomics (216), Experimentation (218), Failure Modes and
Effects Analysis (220), Fault Tree Analysis (222), Financial
Ca

Analysis (224), Finite Element Modeling (226), Optimization

(250), Prototyping (266), Quality Function Deployment (268),
Requirements Matrix (276), Revision Control (280), Robust
Design (282), Scoring Matrix (286), Screening Matrix (288),
Sensitivity Analysis (290), Six Sigma (292), Troubleshooting
(302), Uncertainty Analysis (304), and Value Engineering (306)
U

of Mattson and Sorensen.

BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
BY
U
Ca
ps
ton
e2
02
0-
20
21
 21
20
0-
02
e2
ton

Chapter 6
ps

Decision Stage: Design Deployment

Ca
U
BY
 48 Chapter 6

Chapter 6. Decision Stage: Design Deployment

21
The Boeing 737 MAX aircraft (Figure 6-1) is one of the most technologi-
cally advanced and efficient airplanes ever designed and produced. It flew
thousands of flights before two crashes grounded the entire fleet of air-
craft while governments investigated the causes of the crashes. Activated

20
flight control law software played a key role. The incidents demonstrated
that elements of a whole design, while tested extensively in isolation, can
come together in unforeseen ways and that users may interact with the
design in unintended configurations.

0-
02
e2
ton

Figure 6-1. The Boeing 737 MAX aircraft.

Despite the care and concern that may be exhibited throughout the pre-
vious design stages, deploying a design decision set as a product is always
fraught with risks and challenges. In the Design Details stage, all of the
decisions to produce a product were initially made and compiled into a
ps

design package. However, when all of the different components come to-
gether, inevitably there are issues that arise. Complexity always introduc-
es additional interactions which were not visible during earlier stages in
the development process. Software bugs always come up as modules are
Ca

combined. In general, the greater the complexity of the project, the more
negative interactions are possible when subsystems are combined.
The words of Hyman Rickover, who directed the development of the U.S.
Navy nuclear program, are relevant at this stage:
“It is a human inclination to hope things will work out, de-
U

spite evidence or doubt to the contrary. A successful manager

must resist this temptation. This is particularly hard if one has
BY

invested much time and energy on a project and thus has come
to feel possessive about it. Although it is not easy to admit what
a person once thought correct now appears to be wrong, one
must discipline himself to face the facts objectively and make the
necessary changes — regardless of the consequences to himself.”
 Decision Stage: Design Deployment 49

Often major changes occur as a product deployed. Sometimes the

21
interactions come about because the original design decisions have flaws.
Other times, problems occur because the design must be manufactured
in a different environment than was originally intended. During pro-
duction, some parts may become obsolete or otherwise unavailable.
Substitutes and cost-saving reductions are often introduced. Even com-

20
positions for components like batteries and other materials may change
during a production run. Sometimes genuine mistakes are made and
production equipment fails or drifts out of tolerances. Manufacturing is
fraught with difficulties in which small mistakes can quickly compound

0-
and overwhelm delicately balanced supply chains. Those very supply
chains may be disrupted by world events beyond the control of govern-
ments or companies. It is important for a designer to accept responsibil-

02
ity and change those things within the control of the design team and to
effectively accept and adapt to the changing external circumstances when
the design is produced.

Production Refinement
e2
As the design moves into production facilities, inevitably there are
changes to the design decisions that must be adapted to the workflows of
the different production facilities and operations. For example, decisions
captured in manufacturing process sheets are revised to be able to scale
ton

up to large facilities such as the one pictured in Figure 6-2. Process flows
that were initially envisioned at smaller scales are adapted as materials
are received in different orders and configurations. Certainly, produc-
tion scheduling is modified to account for unanticipated changes and
business considerations.
ps
Ca
U
BY

Figure 6-2. Production facility with workers following design

decisions to create a tangible product.
 50 Chapter 6

Software deployed into large cloud platforms often undergoes major

21
refinement to deal with the scale and backend problems associated with
deployment. It is helpful to have the original design team on hand as the
design is passed off to the production teams. This handoff may be me-
diated by computers in a continuous integration process, but should be
monitored in case new anomalies are detected through automated testing

20
or feedback received from users.
It is important to document changes that are made as revisions to the
design package. This (1) allows the currently released design documenta-

0-
tion to stay current with the product release, and (2) this enables process
improvements and customizations to refine the design package and to
teach the design team principles that are often useful to implement in the
next product release.

02
Production may also be influenced by the distribution network associ-
ated with product releases. Often maintenance documents also need to
be revised as changes are introduced as part of production refinement.
e2
These documentation steps should be carefully considered as necessary
decisions are made as part of the Deployment stage. Essentially, when the
design package moves to the production facility, the deliverability of the
design is evaluated.

Post-Release Refinement
ton

Even after a product is released, it undergoes further refinement. After-

market add-ons may need to be considered that affect the operation of
the original product. Feedback is received from production workers,
distributors, vendors, and end-users. All of this feedback is important to
ps

consider making changes to the design decisions even after the product is
in the hands of consumers.
In the case of software, post-release refinement may consist of starting
the entire product development cycle over again with a new set of Design
Ca

Drivers, or it may consist of releasing small changes and updates based

on feedback. Software can often be updated continuously through
steady refinement releases. However, this release process may introduce
new bugs and result in undesired consequences. Even with continuous
refinement releases, evaluation and testing phases should be conducted
before any new release. Design Decision Stages in software development
U

may be organized iteratively, resulting in sequential releases. This pattern

is illustrated in Figure 6-3. As with all design projects, design decision
principles are customized to the project characteristics.
BY

In the case of physical objects, such as automobiles, post-release re-

finement is almost always a costly decision (Figure 6-4) because recalls
influence the market value of released products and incur charges to
the production and distribution network. Safety interests should take
 Decision Stage: Design Deployment 51

21
Drivers Divergence

20
Initial Release

0-
Latest Release

02
Deployment Details

Figure 6-3. Pattern of Design Decision Stages for iterative

e2
software design.

precedence over other considerations with post-release refinements

conducted out of an abundance of caution. Coordination between the
design team, production facilities, distribution networks, and end-users
ton

is necessary to avoid confusion and to successfully correct a released

design.
ps
Ca
U
BY

Figure 6-4. Astronauts install corrective optics for

the Hubble Space Telescope in a costly post-release
refinement.
 52 Chapter 6

Market Response

21
Ultimately, it is important to understand that no matter how much a de-
signer loves certain design decisions and extol their virtues, the success of
those decisions embodied in a product is judged by the market. Feedback
may be direct, such as the number of sales that are generated by the prod-

20
uct, or indirect, such as the star ratings on a website or customer reviews.
And if production costs exceed revenues, the design may be culled. Histo-
ry is filled with failed products that are now in museums- or junkyards.

0-
For products that do achieve commercial success, that success always has
a lifetime. No company can sell the same design decisions indefinitely.
Inputs and supply chains change. Packaging changes to cater to different
tastes. Competitors arise. Regulations may force changes. Design deci-

02
sions continue to be updated as new technologies replace old ones. No
designer can rest on past laurels.
Failure or success, a designer who goes through the Design Decision
Stages is never the same. Experience teaches and the designer is more
e2
cognizant of his/her personal Design Decision Cycle as well as the inter-
actions between delegated decisions and the role of external players in
the process. Experience and wisdom gained will empower the designer to
make better decisions when faced with future challenges.
ton

Two important questions represent the outcomes from the Design De-
ployment stage:
1. What revisions are necessary to deploy the design package
through the production system?
2. How does the market response determine the success of the
ps

deployed set of design decisions?

Ca
U
BY
 Decision Stage: Design Deployment 53

21
End-of-Chapter Questions
1. How does production refinement change the design deci-

20
sions contained in the design package?
2. In production refinement and post-release refinement,
why is it important to still revise and communicate changes
made to the design package?

0-
3. What lessons have your learned from your own product
development experience that can be shared with other
designers?

02
e2
Additional Readings
1. The Design Deployment stage has much in common with the
System Refinement, Producibility Refinement, and Post-re-
lease Refinement Stages outlined in Chapter 7 of Mattson and
ton

Sorensen.
2. Some examples of tools that may help in the Design Deploy-
ment stage include Bill of Materials (172), Codes and Standards
(182), Cost Estimation (188), Design for Assembly (198),
Design for Manufacturing (200), Design of Experiments (202),
ps

Design Review (204), Drawing Checking (210), Drawings

(212), Engineering Change Order (ECO) (214), Ergonomics
(216), Failure Modes and Effects Analysis (220), Fault Tree
Analysis (222), Financial Analysis (224), Optimization (250),
Ca

Prototyping (266), Quality Function Deployment (268), Revi-

sion Control (280), Robust Design (282), Six Sigma (292), and
Troubleshooting (302) of Mattson and Sorensen.
U
BY
BY
U
Ca
ps
ton
e2
02
0-
20
21
 55

Credits

21
Cover: Bill Oxford, Unsplash; Michael Schiffer, Unsplash; Skeeze, Pixa-
bay; Harrison Broadbent, Unsplash; Tyler Lastovich, Unsplash; NASA,

20
public domain

Figure 1-1: NASA, public domain

0-
Figure 1-2: NASA, public domain
Figure 1-4: anndriessen, Pixabay

02
Figure 1-5: Draper Laboratory, public domain

Figure 2-1: moerschy, Pixabay

e2
Figure 3-1: Clker-Free-Vector_Images, Pixabay
Figure 3-3: fh_media, Pixabay; Jacques GAIMARD, Pixabay; Startup-
StockPhotos, Pixabay; RossMannYYC, Pixabay; malikubra, Pixabay;
ton

DokaRyan, Pixabay; Engin Akyurt, Pixabay

Figure 4-1: clausabraham, Pixabay; Bru-nO, Pixabay; juancb, Pixabay;

AnnaSvist, Pixabay; Mohamed Hassan, Pixabay; boskampi, Pixabay
ps

Figure 5-1: Free-Photos, Pixabay

Ca

Figure 6-1: Acefitt, WS_YYC_737_MAX_1.jpg, Wikimedia Commons,

CC BY-SA 4.0
Figure 6-2: axevaper, Pixabay
Figure 6-3: NASA, public domain
U
BY
 56

Index

21
A

20
Accountability 34-35, 37, 38
Architecture 7, 13, 33

0-
Bill of Materials (BOM) 36, 38, 44

02
Complete product concept 27, 29-30, 33
Constraints 13, 21, 23-24, 26, 29, 33
Convergence 29
e2
D
Decision-makers 20-21
Decision space 12
ton

Decomposition 33-34, 36, 38

Delegated decisions 3-4, 6, 12, 33, 43
Deliberation 14-15, 21
Deliverability 6, 9, 42
Design
ps

artifacts 7-8, 18, 27, 29, 35

cost 6, 32, 35, 41, 43
decision 3, 5, 9, 11, 19, 26, 32, 34-35, 40-43
decision cycle 11, 18, 36, 43
Ca

decision stages 18, 43

deployment 40
details 32, 40
drivers 17-19, 21, 23-24, 26, 42
package 36
U

Desirability 6-7
Detailing 35
Direct decisions 3-5, 9
BY

Divergence 13, 26, 29-30

Divergent thinking 13
 57

Documentation 8

21
I
Interface control artifacts 33
Interfaces 33

20
K
Key Success Measures 22-24

0-
M
Market evaluation 6

02
Market response 43

O
Objective metrics 29
e2
P
Post-release refinement 42
Potential decision 13
ton

quality 26
variety 26
Product development 6, 18, 20, 23, 26, 34, 36, 42, 44
Production refinement 41
Prototype 27-28
ps

R
Requirements
Ca

artifact 21, 22, 26

generation process 21
Resources 2, 5-6, 12, 14, 16, 18, 19-20, 23-24, 27, 29, 33-34, 37

S
U

Schedule 19
Scope 19
BY

T
Testing 21-22, 27, 34, 36-37, 42
BY
U
Ca
ps
ton
e2
02
0-
20
21