Essays on a Novel Framework for Product Development Theory
by
Sourobh Ghosh
B.S. Mechanical Engineering
B.A. Economics
University at Buffalo, The State University of New York, 2013
Submitted to the Department of Mechanical Engineering
in Partial Fulfillment of the Requirements for the Degree of
Master of Science in Mechanical Engineering
at the
ARCHIVES
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
OCT 012015
Massachusetts Institute of Technology
LIBRARIES
September 2015
C 2015 Massachusetts Institute of Technology. All rights reserved.
Signature redacted
Signature of A uthor.....................................
.......................................................
Sourobh Ghosh
Department of Mechanical Engineering
July 31, 2015
Signature redacted
....................................................
Warren P. Seering
Weber-Shaughness Professor of echanical Engineering and Engineering Systems
Thesis Supervisor
Certified by.......
Signature redacted
Accepted by.......................................
...
. ....
David E. Hardt
Ralph E. and Eloise F. Cross Professor of Mechanical Engineering
Graduate Officer, Department of Mechanical Engineering
2
Essays on a Novel Framework for Product Development Theory
by
Sourobh Ghosh
Submitted to the Department of Mechanical Engineering
on July 31, 2015 in Partial Fulfillment of the
Requirements for the Degree of
Master of Science in Mechanical Engineering
Abstract
After calls for a common terminology to unify the highly distributed literature on
engineering design, this thesis develops and presents an emergent framework for the novel
description and reconceptualization of the standard product development (PD) process. We begin
with a review of the literature on Set-Based Design (SBD), introducing a paradigm called SetBased Thinking which unifies the SBD and affiliated literatures around common themes and
influences. Motivated by a set-based perspective, we then establish the lexicon for a novel
framework for PD. Using this lexicon to drive descriptions of PD, we gain new insights on the
process, such as the relationship between function and form in early stage design and designers'
reliance on articulating form in order to explore the functional space. These insights and others
lead us to establish the Designer's Dilemma, which asserts that fixation is an inevitable
consequence of exploring ideas in early stage design that cannot be avoided with current ideation
techniques.
In sum, this thesis articulates a framework which presents a fundamental
reconceptualization of the front end of the PD process. We also identify future areas of work upon
which the framework can be expanded to address latent research issues in the PD literature.
Thesis Supervisor: Warren P. Seering
Title: Weber-Shaughness Professor of Mechanical Engineering and Engineering Systems
3
4
Acknowledgements
I shall begin by acknowledging sources of financial support for this thesis. This material
is based upon work supported by the National Science Foundation Graduate Research Fellowship
Program under Grant No. 1122374. This work was also made possible in part by the Center for
Clean Water and Clean Energy at MIT and the King Fahd University of Petroleum and Minerals
(KFUPM) under project number Ri 1-DMN-09.
There are countless individuals who have helped make this thesis a reality.
While I
unfortunately will not be able to recognize them all, I shall mention a few here.
First, I would like to thank my advisor, Prof. Warren Seering, for his invaluable guidance
and for embracing the unconventional path I took during the course of this thesis.
Our
conversations on product development, education, and an array of other topics have always been
a source of inspiration. I am truly fortunate to have had a mentor of such high character oversee
the most intellectually stimulating years of my life thus far.
I owe special thanks to Maria Yang, David Wallace, and Steven Eppinger for supporting
my endeavors and for their wonderful advice and feedback.
I would also like to acknowledge my colleagues and friends on the fourth floor of Building
3. Alison, Elisabeth, David, Endris, and the folks at Ideation and CADLAB have made this
experience so much more enjoyable and worthwhile.
Thank you to Kemper Lewis and the DOES lab for introducing me to and sharing your
passion for the world of product development research.
Finally, this work would not have been possible without the support of friends and family.
To my parents and brother, thank you instilling your love for learning upon me and for inspiring
me to always challenge myself. These values and your continued support are the reason why I am
here today.
5
6
Table of Contents
1. Introduction...............................................................................................................................
10
2. Set-Based Thinking in Product Developm ent.........................................................................
14
2.1 Introduction and M otivation ..........................................................................................
14
2.2 Review M ethodology......................................................................................................
16
2.3 Seven Characteristics of Set-Based Product Developm ent..............................................
18
2.4 The Two Principles of Set-Based Thinking ....................................................................
30
2.5 Case Exam ple: Set-Based Thinking in Function Structures ...........................................
37
2.6 D iscussion and Conclusion .............................................................................................
38
3. A New Fram ew ork for the Product Developm ent Process....................................................
41
3.1 M otivation and Background...........................................................................................
41
3.2 Definitions..........................................................................................................................
43
3.3 Role of Term s in Fram ework Thinking ..........................................................................
54
3.4 U se in the Literature...........................................................................................................
54
3.5 Conclusion .........................................................................................................................
60
4. D escribing the Process Using the Fram ework ......................................................................
61
4.1 Tem poral D escription of the Product D evelopm ent Process ..........................................
61
4.2 Other Visual Representations of the Fram ework ...........................................................
63
4.3 Observations from Using the Fram ew ork ......................................................................
65
4.4 Conclusion .........................................................................................................................
66
5. Surjective Relationship .............................................................................................................
67
5.1 The Surjective Theorem for Product D evelopm ent ........................................................
67
5.2 Understanding the Dom ains...........................................................................................
69
7
5.3 Additional Insights from the Surjective Relationship........................................................
71
5.4 Conclusion .........................................................................................................................
73
6. The Fram ework: Ideal vs. Practice .......................................................................................
74
6.1 An Idealized M odel for Product Developm ent ...............................................................
74
6.2 Product Development in Practice, Described by the Framework ...................................
75
6.3: Conclusion ........................................................................................................................
79
7. The Designer's D ilem m a........................................................................................................
80
7.1 The Designer's D ilem m a .................................................................................................
80
7.2 Contextualizing the Designer's Dilem ma in the Literature ............................................
82
7.3 An Exam ple from Football ................................................................................................
83
7.4 Observations from Reasoning with the Designer's Dilemma....................
85
7.5 Strategies to Counteract the Designer's Dilemm a ..........................................................
89
7.6 Conclusion .........................................................................................................................
91
8. Understanding Constraint Propagation.................................................................................
93
8.1 Identifying an Order for Constraint Propagation ............................................................
93
8.2 An Econometrics Inspired Framework for Ordering Constraint Propagation ............... 94
8.3 Conclusion .........................................................................................................................
96
9. Bringing it Together: How the Framework Influences the Way We Think about Design....... 98
.......... ............ ......... . .
9.1 W hat Does This Work Hope to Achieve ......................................
9.2 What N ew Ways of Thinking Are Proposed?..................................
9.3 What are
..............................................
98
....... ........... ........... . .
.......... .............. ..............
9.4 Concluding Thoughts .......................................................................................................
99
105
107
References...................................................................................................................................
109
Appendix.....................................................................................................................................
117
8
A l The Pareto Frontier as a Subset of the Surjection's Codomain .......................................
117
A2 Cardinality of the Two Domains......................................................................................
117
9
1. Introduction
"Everyone designs who devises courses of action aimed at changing existing situations into
preferredones." - H erbert A. Simon, The Sciences of the Artificial
In Herbert Simon's influential work The Sciences of the Artificial, Simon describes an
interesting trend in higher education over much of the 20th century, noting "...it is ironic that in
this century the natural sciences almost drove the sciences of the artificial from professional school
curricula..." (Simon 1996). Having established the study of design as a quintessential artificial
science, Simon was particularly disturbed by his observation, especially in light of his view of
design as "the core of all professional training." Simon argues that in order for engineering schools
to deliver on their mission to train professionals, the study of design should be researched and
taught as a science.
He states, "The professional schools can reassume their professional
responsibilities just to the degree that they discover and teach a science of design, a body of
intellectually tough, analytic, partly formalizable, partly empirical, teachable doctrine about the
design process."
Many in the engineering community took note of Simon's arguments, triggering a number
of activities that led to the creation of the Design Theory and Methodology (DTM) conferencea community of scholars passionately engaged in developing the science of design. At the 25th
anniversary of this conference in 2013, a series of essays commissioned by the DTM Conference
and Program Chairs explored past winners of the "Best Paper Award" in an effort to describe the
development of past, present, and future research themes explored by the DTM community (Braha
et al. 2013). This led a revisiting of Set-Based Design (SBD), a product development' (PD)
1 I use "product development" to describe the act of creating a product. This involves a host of tasks, including
traditional engineering analysis, project management, marketing, finance, legal, to name a few activities. While
Simon's definition of design (see above) reasonably allows "design" and "PD" to be used interchangeably, given
notions in the broader literature which distinguish "design" from some of the aforementioned holistic tasks in bringing
a product to market (such as considering marketing and legal concerns), I often elect in this work to use the broad
implications of "product development" to refer to the process of product realization.
10
methodology that was formally introduced to the DTM community via Ward and Seering's 1989
DTM paper (A. C. Ward and Seering 1989).
SBD is a fascinating example of a methodology which contributes to Simon's desire for
developing design science. As a process, SBD meets many of Simon's criteria for design science,
being "intellectually tough, analytic, partly formalizable, partly empirical." However, in the years
since Ward and Seering's 1989 DTM paper, many of the authors who studied and applied SBD
seemed to have differing views on how exactly to define the method. Thus, it clearly falls short
of Simon's criteria for being a "teachable doctrine," since in order to be teachable, there must be
clear consensus on how to define the method.
Interestingly, as we discuss between the conclusion of Chapter 2 and the introduction of
Chapter 3, there seems to be a lack of consensus on a variety of fundamental constructs within our
theories for design and PD. Thus, this transcends SBD and is indicative of an issue in the greater
design literature. Without a standardized teachable doctrine, we cannot realize Simon's vision for
developing design into a comprehensive science. To appreciate this issue, one may review a nonexhaustive sampling of texts on design and the PD process (Hubka, Andreasen, and Eder 1988;
Pahl et al. 2007; Pugh 1991; Suh 1995; Ulrich and Eppinger 2012). While the basic chronology
of events describing the process remains roughly the same across these texts, there are fundamental
incompatibilities among many of these works. For instance, while Pahl and Beitz describe an
intermediary "Embodiment" phase to the process, their contemporary Pugh cannot easily
accommodate this phase in his framework for Total Design, which goes straight from Concept
Development to Detail Design.
This thesis is my attempt to propose what could hopefully inform a teachable doctrine for
design science. I do this by introducing a novel framework for PD theory. I begin by introducing
base definitions which form the lexicon for the framework. This lexicon is designed with the intent
to be general enough to describe a variety of scenarios within the PD process while being detailed
and precise enough to guide deeper insights. With this carefully standardized terminology, I use
this emergent framework to describe the process and make deeper observations about the
underlying mechanics of reasoning throughout the PD process, particularly in the ill-defined,
enigmatic front end of the process.
11
Each of the following chapters can be thought of as short essays which contribute to the
development of this novel framework. An analogy can be drawn between the development of this
framework and common law.
In a common law system, the legal framework is decidedly
emergent, whereby the principle of stare decisis establishes precedent of past decisions ("Stare
Decisis" 2015). This indirectly implies that future decisions, often referencing past decisions, give
greater meaning to these past decisions. Consider the example of the Fourteenth Amendment to
the US Constitution. While originally proposed to grant citizenship to freed slaves after the Civil
War, the Fourteenth Amendment has been used as the legal basis by which to decide cases on
segregation in public schools, 2 abortion rights, and same-sex marriage, to name a few examples
("Fourteenth Amendent of the United States Constitution" 2015). Similarly, the framework for
PD that I propose can be thought of as an emergent framework, where each subsequent chapter in
this thesis expands upon and gives greater meaning to the existing framework formally established
in each chapter preceding it. This implies that by the end of this thesis, the framework will not be
complete in any conventional sense, inviting ample opportunity for future work.
The remainder of the thesis is organized as follows:
" Chapter 2 reviews the SBD and affiliated literature in order to establish Principles for SetBased Thinking and root our development of the framework in the chapters to follow.
-
Chapter 3 formally introduces the terminology of the framework and compares my use of
terminology to common established uses in the literature.
" Chapter 4 uses the framework to guide descriptions of the PD process, introducing critical
observations that form the basis of developments in Chapters 5-8.
" Chapter 5 formalizes the relationship between architectural and specification domains as
first presented in Chapter 3 via the Surjective Theorem. The implications of this Theorem
on the framework presented thus far and on other streams of work are also discussed.
2The
case of Brown v. BoardofEducation (1954) is interesting as it specifically overturns a previous Supreme Court
ruling, Plessy v. Ferguson (1896), thus refuting legal precedent.
I point it out here to complete my analogy of
developing an emergent framework for PD, since should any content within the framework be found to be incorrect
after the publication of this thesis, it should be pointed out and corrected in future work.
12
"
Chapter 6 presents an idealized model for PD based on the framework, which is then used
in contrast to illustrate the realities of PD in practice. These insights help contextualize the
articulation of the Designer's Dilemma.
m
Chapter 7 introduces the Designer's Dilemma and explores its implications for early stage
design and ideation in general. It also explores strategies to attempt to counteract the
effects of the Dilemma.
" Chapter 8 proposes the creation of a framework for ordering the propagation of constraints
by leveraging techniques from econometric analysis.
" Chapter 9 collects and summarizes major results from reasoning with the framework over
the previous chapters. In doing so, it articulates potential academic contributions while
identifying areas for future work.
13
2. Set-Based Thinking in Product Development
In the previous chapter, I establish the context of revisiting influential PD methodologies
in the years since the establishment of the DTM conference, including Set-Based Design (SBD).
After a series of academic case studies had revealed Toyota's unique product development
practices to the world, a flurry of research has been conducted into SBD. In this chapter, we review
work related to set-based design across academic communities in efforts to find common themes
and influences. After a review of this literature, we inductively arrive at two Principles of SetBased Thinking: considering sets of distinct alternatives concurrently and delaying convergent
decision making. These Principles allow us to articulate a working description of SBD, while
presenting vital context for us to develop the novel framework for PD that is the primary focus of
the remainder of this thesis.
2.1 Introduction and Motivation
Set-Based Design (SBD), also referred to as Set-Based Concurrent Engineering (SBCE),
has played an important role in the development of the DTM and the greater engineering design
community, as established in 2013's retrospective study of DTM best papers and underlying
research themes (Braha et al. 2013). The theoretical foundation for SBD was laid in Allen Ward's
PhD thesis (A. C. Ward 1989), the fundamental ideas of which he presented to the Design Theory
and Methodology (DTM) community in (A. C. Ward and Seering 1989).
Ward's work nominally describes a computer program that selects standard components
from catalogs in order to implement a variety of mechanical designs (A. C. Ward and Seering
1989). However, the fundamental idea behind this work was that products should be designed
with all viable options in mind, and that options should not be eliminated unless there is a logical
reason to do so.
This proposed approach of exploring concepts in parallel while gradually
narrowing the solution space until a single solution is found was in contrast to a traditional, pointbased design (PBD) approach which advocates generating alternatives at the onset and selecting
only one for further development (Sobek, Ward, and Liker 1999; Singer, Doerry, and Buckley
2009). Thus, to keep all feasible options in play for consideration for as long as reasonable-this
14
embodies the ethos of SBD. The way Ward achieved this was by reasoning with sets, leading to
the name Set-Based Design.
While these ideas provided a fresh take on PD practice when they were introduced, the idea
of considering design concepts in parallel was not new. Pahl and Beitz (Pahl and Beitz 1988) and
Hubka (Hubka, Andreasen, and Eder 1988) described design processes for which alternate design
concepts were considered simultaneously.
The influence of processes associated with the
consideration of sets of design alternatives was extended in the mid-1990's, when Ward and
colleagues studied new PD at Toyota (A. Ward et al. 1995). At the time, Toyota enjoyed a
reputation for developing reliable, superior vehicles under short timelines and at low cost. During
their study, Ward et al. found that Toyota's unique practices had embodied the principles of SBCE,
or SBD, reasoning that these practices were fundamental to Toyota's success.
The influence of Ward et al.'s study was widespread. This study, along with related work
(Womack, Jones, and Roos 2007), contributed to an environment which fostered the lean
manufacturing movement that continues to impact new PD today. Furthermore, the influence of
the Toyota case studies generated a flurry of research in the engineering design and management
science communities, from where the original ideas of SBD were formulated. However, beyond
these native academic communities, SBD began to influence areas such as civil and structural
engineering, ship-building, and software development, to name a few examples. Among these
diverse applications, SBD as a research area began to take a life of its own, potentially meaning
something slightly different to each of its varied practitioners.
This chapter reviews literature that addresses reasoning about sets of designs in an effort
to find common ideas and themes. As this work is still preliminary, the literature reviewed in this
work is not exhaustive; rather, an emphasis was placed on demonstrating a breadth of work across
domains. This includes reviewing 1) methods that are explicitly categorized by some to be SBD
and 2) methods that have not been explicitly categorized as SBD but that enable decision-making
or reasoning about sets of design alternatives, such as use of function structures and shape
grammars. In this chapter we will refer to the employment of both categories of methods as "setbased thinking."
15
With the diversity of work that has emerged over the last approximately two decades, we
have struggled in our search of the literature to find a consensus over what SBD or set-based
thinking represents today. Therefore, in this work we hope to identify emergent principles which
embody commonly espoused views regarding the core principles of set-based thinking from the
literature across communities.
This chapter is organized as follows. In Section 2.2, we discuss the research methodology
for our study, outlining our inductive approach. In Section 2.3 we explore 7 Characteristics of SetBased Product Development, and in Section 2.4 we use these 7 Characteristics to arrive at 2
Principles of Set-Based Thinking: considering sets of distinct alternatives concurrently, and
delaying convergent decision making. In Section 2.5 we perform a case example on function
structures, observing the ways in which the 2 Principles manifest themselves in this popular
theoretical construct, and in Section 2.6 we discuss the implications of this study and conclusions.
2.2 Review Methodology
In this section, we discuss the theoretical framework for our study. As stated in the
introduction, our goal in this work is to consolidate the diverse literature on SBD methods and
techniques around common themes which illustrate set-based thinking.
Due to the flurry of
research over the last two decades that has led to the evolution of SBD as a topic across various
domains, we have decided to take an inductive approach to our study.
Our approach shall be to review work which nominally exhibits characteristics or specific
instances of SBD or, more generally, set-based PD processes. Then, from a holistic analysis of
the work reviewed from these Characteristics, we shall arrive at Principles of Set-Based Thinking.
This is in contrast to a deductive approach, which would involve formulating the Principles first,
and then testing these Principles across each documented case of set-based affiliated research for
validity. Not only would such a study be practically infeasible, but it would suggest that the
premises (i.e. the derived Principles) be necessarily true in order for any proposed argument to be
sound (and thus to have any value). To avoid this intellectual trap, we use an inductive approach
to arrive at our probable conclusions: the Principles of Set-Based Thinking. We believe this
analysis to be appropriate for this initial study.
16
The first step in this process is to identify common characteristics of set-based product
development. Given the role of Ward et al. (1995)'s study of Toyota's PD processes in motivating
the push for SBD research (a fact which can be substantiated by the frequent citations of (A. Ward
et al. 1995) by the research reviewed in this work), we believe that the case studies presented in
the 1995 work are a good place to find and define these characteristics. After reviewing these case
studies and selecting the most noteworthy, unique attributes of Toyota's PD practices as reported
in (A. Ward et al. 1995), we arrive at 7 Characteristics of Set-Based Product Development
(SBPD) 3 , summarized below:
1. Emphasis on frequent, lo-fidelity prototyping
2. Tolerance for under defined system specifications
3. More efficient communication among subsystems
4. Emphasis on documenting lessons learned and new knowledge
5. Support for decentralized leadership structure and distributed, non-collocated teams
6. Supplier/subsystem exploration of optimality
7. Support for flow-up knowledge creation
The Characteristics, forming a notion of what research into set-based methods entails, act
as a filter by which we choose what work to review in this study. Using this filter, we review two
classes of literature since the Ward et al. (1995) study-work that is nominally classified as SBD,
and work that is not nominally classified as SBD but that utilizes set-based reasoning. Both classes
of literature are part of the narrative on the influence of set-based thinking in the design community
and beyond.
3The difference between Set-Based Design (SBD) and Set-Based Product Development (SBPD) as we refer to them
is nuanced. Where SBD refers specifically to methodology, SBPD refers to the practical situations and outcomes
where SBD is applied.
17
2.3 Seven Characteristics of Set-Based Product
Development
This section is dedicated to exploring the manifestation of the 7 Characteristics of SetBased Product Development across the literature. We detail the genesis of the Characteristics from
(A. Ward et al. 1995), in addition to how the literature since this work supports each individual
characteristic.
We begin with the first characteristic, an emphasis on frequent, lo-fidelity
prototyping.
2.3.1 Emphasis on Frequent, Lo-Fidelity Prototyping
At the time of Ward et al. (1995)'s case studies, Toyota was noted as a leader in lean
manufacturing and was the industry standard-bearer for the most efficient PD processes, both in
terms of time and cost. It was for this reason that one of the most counterintuitive revelations of
Ward et al.'s studies was Toyota's practice of frequent prototyping. Ward et al. characterized
Toyota's system as generating "excessive numbers of prototypes" when compared to other
Japanese and US automakers. For instance, while another Japanese or US automaker may develop
on average three 1/5 scale clay models of body designs, Toyota may develop anywhere from 5 to
even 20 of such models.
Frequent Prototyping
These results generated interest in the value of prototyping in the design process, spurring
further research. Yang recognizes prototypes as "early embodiment[s] of a design concept" (Yang
2005), although it should be noted that prototypes may be generated at later phases of the design,
and may embody several forms, from sketches (Yang 2008; Shah et al. 2001), to 3D CAD models
(Nahm and Ishikawa 2006), to full-scale models described in (A. Ward et al. 1995).
Notably, the proliferation of prototyping throughout the design process is a clear
manifestation of concurrent development, as multiple prototypes help designers explore multiple
concepts-which Toyota clearly understood and practiced. As Yang notes, prototyping can be
thought of as a "design language," or a "way to express design thinking" (Yang 2005)descriptions which support the understanding that prototypes enable the concurrent development
18
of concepts. This reasoning will be important later on when we formulate Principles of Set-Based
Thinking.
While Ward et al. (1995) document Toyota's correlation with frequent prototyping and
ostensibly superior design outcomes (i.e. cheaply manufactured, high-quality automobiles), recent
work from Haggman et al. seeks to explore this relationship in a series of controlled studies
(Haggman, Honda, and Yang 2013).
Their research demonstrates statistically significant
correlations between prototyping early in the design process and design outcomes. Furthermore,
they find no statistically significant correlations between the time that design teams spent
developing their prototypes and outcomes.
Therefore, their results advocate "prototyp[ing]
cheaply and early in a project."
While the discussion above has generally supported the value of frequent prototyping, the
other half of our argument is that prototypes developed should not intentionally exhibit very high
fidelity or levels of resolution or detail-encompassed by Haggman et al.'s suggestion to develop
them "cheaply." Here, it is instructive to consider examples from software design.
Prototyping with Sufficient Fidelity
Today, the agile software development movement continues to influence and inform much
of the software industry's practices. The relationship between the agile software development
movement and lean manufacturing has been well documented, suggesting that lean principles were
important to influencing agile PD philosophies (Poppendieck and Poppendieck 2003). A popular
method emerging from this movement was and continues to be Scrum. In general, Scrum and
other Agile methodologies emphasize the rapid development of software concepts for trial and
error without excessive commitment from developers. These "prototype" phase user interfaces
(Uls) need to be tested for basic functionality, bugs, and other issues prior to implementation of
the final details of the UI (Sutherland et al. 2007).
Similarly motivated practices are found at one of the world's leading design firms, IDEO.
The prototyping philosophy at IDEO follows the three R's: rough, rapid, and right.
This
philosophy promotes the development of prototypes that have sufficient detail-not too much, but
just enough to convey the concept. Aiming for "rough" and "right" ensures that time is not wasted
19
developing concepts which eventually become "straw men" concepts and do not inform the final
design (Thomke 2003).
In explaining their prototyping philosophy, IDEO founder David Kelley also notes that
following the three R's prevents designers from becoming too attached to the concepts that their
prototypes represent. This effect, known as design fixation, has been well-documented and studied
(Jansson and Smith 1991; Linsey et al. 2010). Recent studies by Viswanathan and Linsey argue
that design fixation can be mitigated by generating rapid prototypes (Viswanathan and Linsey
2013). By mitigating design fixation, designers hope to enable themselves to consider a wider
range of available options, encompassing much of Ward's original intent for SBD. 4
2.3.2 Tolerance for Under Defined System Specifications
Another aspect of Toyota's seemingly paradoxical efficiency from the Ward et al. (1995)
study was its designers' tolerance for under defined system specifications. Toyota managers were
intentionally reluctant to lock down system specifications prior to key decision making points
throughout the design process.
Examples included managers reporting only approximate
subsystem specifications to target to their suppliers, and delaying the release of final specifications
to these suppliers until late in the design process. A particularly poignant example was in body
design, where Toyota postponed fixing body hardpoints in the vehicle architecture. As one of
Toyota's general managers put it, "the manager's job is to prevent people from making decisions
too quickly." This was in stark contrast to the more traditional design approaches adopted by other
Japanese and US automakers, who would try to lock down specifications as soon as possible. In
their view, this was the only way to move the design forward in the process.
Characteristic 2 in Civil Engineering, Management, and Software Applications
Other applications in the literature have also documented an ability to advance the project
at hand without having defined all specifications up front, similar to Toyota. Let us consider a
4 As we will find later on in this thesis, the intention of mitigating fixation may not necessarily guarantee Ward's
desire for not ruling out options from consideration. We will touch upon this point at the end of this chapter and again
throughout the thesis prior to our dedicated discussion on fixation in Chapter 7.
20
case study from civil engineering, specifically in airport design. Gil et al. undertake a study of
upstream and downstream tasks in airport design, where upstream represents "base building" tasks
that provide the service space for occupancy, whereas downstream entails fit-out subsystems that
make the space functional (e.g. check-in baggage counters, baggage screening machines, etc) (Gil,
Beckman, and Tommelein 2008). Traditionally, it would seem counterintuitive to delay decisionmaking on upstream tasks while developing downstream tasks.
However, this approach is
employed effectively to gain total development time between the concurrent development of
upstream and downstream tasks. Managers on this project also pointed out the benefits of their
"progressive fixity" to decision making, where intentionally delaying certain decisions built
greater flexibility into their project. This mitigates their exposure to risk from events such as
shifting requirements or availability of materials.
Further exploring these concepts on a theoretical basis from the management science
literature are Thomke and Reinersten (Thomke and Reinertsen 1998). They note the need for
modem day corporations to incorporate agility in their PD processes by adopting "development
flexibility." In a series of hardware and software applications in the computer industry, their
results advocate "progressively locking down requirements," thus agreeing with the airport design
and Toyota examples offered above. Furthermore, they support making "piecewise commitments
vs. binary choices," where decisions are made on certain aspects of the project despite not having
100% of project specifications approved in advance. This increases flexibility, driving down the
cost of a.potential change down the line, and supporting the idea that Toyota's practices of decision
delay may have actually helped promote efficiency.
Thomke and Reinersten's study of software applications was apt, as we find significant
support for the second Characteristic of SBPD in agile software development.
As alluded to
earlier, the emphasis of rapid development in Scrum and other methodologies is done so that
software can accommodate a highly dynamic environment of rapid technological change, steep
competition, and quickly shifting customer requirements (Sutherland et al. 2007). Hence, agile
developers postpone decision-making on the final specifications of the UI, especially in an area
where customers need to see a final product in order to get a sense of their preferences (Thomke
and Reinertsen 1998).
21
Characteristic 2 in Engineering Design and other Domains
In the discussion above, we observe that the tolerance of under defined specifications can
be interpreted as a tool to manage uncertainty and to mitigate risk. Building upon this thinking,
an excellent way to introduce tolerance for under defined specifications and to mitigate risk is to
adopt a real options approach to PD (de Neufville 2003). Recognizing this connection, Ford and
Sobek use a real options approach to analytically investigate the point beyond which delaying
decision making no longer produces practical benefits (Ford and Sobek 2005).
Another method to manage uncertainty via this Characteristic, particularly for companies
that manage large portfolios of individual products, is to develop a common product platform.
Meyer and Lehnerd define a product platform as "a set of common components, modules, or parts
from which a stream of derivative products can be efficiently developed and launched" (Meyer
and Lehnerd 1997). Robertson and Ulrich put forth a similar definition, with emphasis on asset
sharing across a "set of products" (Robertson and Ulrich 1998). From these definitions, the link
to set-based thinking has been established, with companies successfully employing product
platforms to mitigate uncertainty, such as Black & Decker's universal electric motor (Simpson
2004). Furthermore, Simpson notes that one can "stretch" or "shrink" platforms in order to create
specific products capable of targeting market niches. Notably, to create a product from scratch to
tailor niches implicitly assumes high risk, where a better strategy would be to utilize the underspecified system that is a product platform.
Finally, several in the engineering design community have and continue to mathematically
characterize or model scenarios that deal with the uncertainty of specifications that is at the crux
of Characteristic 2. Representations that utilize traditional set theory include (Finch and Ward
1997; Malak, Aughenbaugh, and Paredis 2009; Malak and Paredis 2010; Panchal et al. 2007),
whereas those that explore employing fuzzy sets include (Antonsson and Otto 1995; Shan and
Wang 2004). Regardless of specific methodology, these works give credence to applying sets to
analytically model the tolerance for under-defined system specifications.
2.3.3 More Efficient Communication among Subsystems
A common practical argument for using set-based methods or techniques is that sets enable
fundamentally richer, more efficient communication. Ward et al. (1995) offer a simple thought
22
experiment to illustrate their point. They argue that when a team of individuals is trying to
schedule a meeting time, a set-based approach is most efficient.
That is, if each participant
simultaneously communicates their availability via sets of time, the meeting is scheduled much
quicker than if one participant were to check with another if he/she is available at a given time,
and so forth. Beyond this thought experiment, Ward et al. found support for their arguments in
Toyota's PD processes, where Toyota and its suppliers were found to establish communication
with each other less frequently for a shorter total duration of time than their US counterparts
employing traditional design methods. For those practicing traditional design methods, constant
communication among collocated engineering teams was a given.
The inherent richness of set-based communication has been noted by a few authors in the
engineering design community. Madhavan, Seepersad, and colleagues have developed a set-based
method for multidisciplinary, distributed design optimization problems. On test problems, they
find that their set-based method yielded solutions within 10% of the optimum with only 1 global
iteration, translating to 90% less computation expense (Carlos et al. 2006; Madhavan 2007;
Seepersad, Shahan, and Madhavan 2007). These results are indicative of the shortcomings of
traditional point-based approaches, which, void of the rich information of set-based methods, rely
heavily on costly iteration to deliver similar results. Other engineering design authors motivated
by set-based efficient communication include Malak and colleagues. Building upon previous work
(Malak and Paredis 2010), Parker and Malak develop mathematical models which represent the
capabilities of ill-characterized systems, which they call technology characterization models
(TCMs) (Parker and Malak 2011). These TCMs intend to facilitate communication of subsystem
level performance characteristics, allowing for the direct comparison of sets of heterogeneous
concepts within the same performance space, similar to traditional Pareto frontiers.
Also inspired by Toyota's example has been the construction academic community, with
Parrish et al. offering a SBD framework for the delivery of reinforcing bars in cast-in-place
concrete (Parrish et al. 2007). They note that the ruling paradigm in the construction industry is a
traditional, point-based design (PBD) approach featuring long delays in passing designs to
different agents in the design process. These delays arise from the high amount of rework at each
step when a new agent in the design process contributes to the overall design. Parrish et al.'s
23
approach instructs all agents in the rebar design process to contribute their input concurrently,
accommodating rich sets of information from each agent and producing a much more efficient
communication scheme, bypassing the inefficiencies of iteration. The efficiency of this proposed
approach has been recognized, leading other authors in the community to further develop Parrish
et al.'s framework (Lee, Bae, and Cho 2012; Sacks et al. 2010).
Of course, the efficient communication paradigm of SBD and set-based thinking in general
can be found in other theoretical constructs in design, such as shape grammars (Stiny 1980).
Orsborn et al. describe shape grammars as "production systems created by taking a sample of the
whole for which one is trying to write a language" (Orsborn et al. 2006).
Shape grammars,
complete with a vocabulary (i.e. a set) of shapes and shape rules can represent "the language" of a
given product's design. Orsborn et al. use shape grammars as a method to explore the development
of crossover SUV body architectures by enabling the designer to produce a multitude of designs
that fall with the constraints of the grammar. The intent is to enable the exploration of new and
unique designs that may not have been imagined by the designer. Thus, using sets of shapes,
designers can efficiently communicate their ideas on vehicle body architecture, while
corresponding shape rules help constrain the design space.
2.3.4 Emphasis on Documenting Lessons Learned/Knowledge
While discussing Toyota's practices, Ward et al. (1995) note that in general "designers are
notoriously resistant to documenting their work, partly because they sense documentation is
generally useless." Toyota, however, expects rigorous documentation of design knowledge via
"lesson-learned books." Ward et al. provide an example of a Toyota die-designer, who maintains
a book of sixty to seventy different ranges of specifications that would ensure the fender design's
manufacturability.
They report that similar books are maintained for every body part, which,
developed over fifteen years at that point, provide detailed knowledge of what potential designs
can (and cannot) be implemented.
These lessons learned books are noted to promote institutional learning and to ensure that
detailed technical knowledge of one's system is not lost over the years-rather, it is accrued.
Similar case examples across domains are noted by Thomke (Thomke 2003). For instance, he
highlights the example of pharmaceutical companies stockpiling small quantities of discrete
24
chemical compounds in "chemical libraries." These libraries are the result of years of prior drug
development projects, maintaining "several hundred thousand compounds and information on
their specific properties." In fact, an emphasis on documentation has gained traction in smaller
scale firms such as IDEO. Thomke describes IDEO's "Tech Box," which is a "giant 'shoebox'
for curiosities and interesting gadgets from prior IDEO projects." Of course, the intent of the
chemical libraries and the Tech Box are the same, which is to help foster new PD.
While the industry cases above demonstrate how sets of information can be documented to
help promote knowledge retention, a few academic case studies have established a direct
connection between following SBD or SBCE processes and learning.
In a series of case studies
by Raudberget in which he introduces companies to SBCE methodologies, he notes that for one
of the companies he studied, "the value of the SBCE project was to identify the knowledge gaps
in their core technology" (Raudberget 2010). Furthermore, he notes that by "knowing the limits
of their technology," the said company could "have an appropriate set of solutions ready for future
offers." Similar results were found in Madhavan et al.'s study of applying SBD principles to
Schlumberger, where "archiving design knowledge in the form of sets of solutions... can be used
in future design activities" (Madhavan et al. 2008).
In fact, this idea can be found in other work in design theory, such as function structures.
Pahl and Beitz describe the ability to define an overall function that expresses the relationship
between inputs and outputs of system independently of the design solution (Pahl and Beitz 1988).
They define a function structure as the combination of individual sub-functions that provides a
representation of the overall function being analyzed.
Pahl and Betiz point out potential
efficiencies of employing function structures, noting that "if existing assemblies can be assigned
directly as complex sub-functions, the subdivision of the function structure can be discontinued at
a fairly high level of complexity." Thus, documenting system knowledge via sub-functions from
prior experience in a set that is readily available for recall in the future may help save "a great deal
of time and money," similar to how Toyota used their lessons-learned books.
Another tool that can enable set-based knowledge representation is affordances. Maier and
Fadel view an affordance-based approach as an alternative to function analysis, where affordances
describe a potential behavior between two or more subsystems within a larger designer-artifact25
user complex system (Maier and Fadel 2008). The goal is to articulate relationships that are
unaccounted for in a function based approach to design, such as non-function based customer
requirements (Maier and Fadel 2008; Cormier, Olewnik, and Lewis 2013). Thus, an affordancebased approach, along with function structures, can enable set-based thinking.
2.3.5 Support for Decentralized Leadership Structure and
Distributed, Non-Collocated Teams
This section is the first of three which explore insights from Toyota's unique organizational
structure. Evidence for Characteristic 5 is apparent from examining Toyota's relationships with
its suppliers, as reported in Ward et al. (1995). These relationships often provide considerable
autonomy to the suppliers, with examples such as radiator and alternator manufacturer
Nippondenso (now Denso) offering sets of potential alternators for Toyota to consider and choose
from, rather than being tasked to develop an alternator that meets specifications initially
determined by Toyota.
Therefore, Nippondenso is accorded considerable weight in Toyota's
decision making process, as the set of options offered to Toyota has been determined by
Nippondenso's estimates of Toyota's needs-alluding to decentralized leadership (where
decisions do not necessarily originate from the top). Furthermore, Nippodenso and many of
Toyota's suppliers do not operate in-house, thus exhibiting support for distribution and noncollocation of subsystem designers.
Decentralized Leadership Structure
We begin by exploring support for a decentralized leadership structure in set-based
methods. As noted earlier, the Scrum methodology of software development provides excellent
examples of SBPD. The Scrum method is carried out by Scrum Teams. There are three core roles
on a Scrum Team: Product Owner, Development Team, and Scrum Master (Schwaber and
Sutherland 2013). While detailing the exact responsibilities of each role is beyond the discussion
of this work (details can be found in (Schwaber and Sutherland 2013)), what is notable about the
separation of labor in a Scrum Team is that there is no role which bears the responsibilities of a
traditional project manager. For instance, while the Scrum Master "is responsible for ensuring
Scrum is understood and enacted" (Schwaber and Sutherland 2013), he/she does not bear
personnel management responsibilities that are typical of a project manager in a company with a
26
traditional, centralized leadership structure ("Scrum Primer"). The reluctance to adopt a traditional
leadership structure stems from the belief that it would produce sub-optimal results.
Exploring the role of varying levels of cooperation in concurrent engineering processes are
Lewis and Mistree (Lewis and Mistree 1998). Using a decision-based design perspective, they
develop a game theoretic model to represent non-cooperative situations in concurrent engineering
processes.
They note that the resulting model "is similar in concept to the idea of set-based
concurrent engineering.. .explored in (Ward et al., 1995), except there is no communication among
the various designers who are generating sets of solutions." Nonetheless, the reason why they
observe similarities is due to their model's ability to represent decentralized leadership structures.
This game theoretic model would later be further developed by Lewis and colleagues to investigate
various distributed design problems (Chanron and Lewis 2005; Devendorf and Lewis 2011;
Ghosh, Devendorf, and Lewis 2014).
It is noted that this framework works well to model
nonhierarchical systems of designers (Devendorf and Lewis 2011)-which supports the
decentralized leadership observation.
Furthermore, the Nash equilibrium that represents the
converged solution in the model is the result of intersecting each designer's rational reaction set,
which is the set of solutions that optimizes that individual designer's objective relative to the
decisions of other designers. Hence, we observe support for the use of set-based modeling and
decentralized leadership, although we note that the models of Lewis and colleagues do not agree
with each of the observed characteristics of SBPD as outlined in this work (e.g. Characteristic 3).
As we will find in Section 2.4, not all observed processes can be classified strictly as SBD or PBD;
rather, they may fall somewhere on a spectrum between the two.
Arguments for Distribution, Non-Collocation
To test a set-based PD method's support for distributed, non-collocated teams, Sutherland
et al. study whether the aggressive development schedule and culture of Scrum can be sustained
across a multinational team of collaborators (Sutherland et al. 2007). Given certain features of
Scrum, such as frequent Scrum meetings, not many had ventured to explore whether Scrum would
be practical beyond the familiarity of small, collocated settings that entailed its predominant usage.
Thus, Sutherland et al. perform a case study tracking a distributed team of 56 developers across
three countries and witness the most productive Java development project to have been
27
documented at the time of their publication-a testament to set-based PD practices supporting
distributed, non-collocated teams.
Another application area for set-based PD practices has been the Navy, specifically in the
design of the Ship-to-Shore-Connector (SSC) (Mebane et al. 2011). Mebane et al. study the
Navy's desire to develop the SSC on an "extremely aggressive" time schedule, leading the Navy
to adopt an SBD approach to its design. While drawing conclusions from the study, they note "the
Navy's ability to develop a design with a distributed team with much of the design team personnel
remotely located in the field was certainly proven," demonstrating sources of support for this
Characteristic of SBPD beyond just the private sector.
2.3.6 Supplier/Subsystem Exploration of Optimality
An interesting feature of a decentralized leadership structure that often provides
subsystems with greater autonomy in the design process is that it encourages suppliers and
subsystems to take initiative in exploring optimality. Continuing with the aforementioned example
of Nippondenso, Ward et al. (1995) describe its approach to look for radical performance
breakthroughs-rather than incremental improvement-in their designs, helping ensure their
relevance in the market of automotive suppliers. Hence, Toyota benefits from having a supplier
that prioritizes being at the forefront of its technology, helping propel Toyota's search for globally
optimal designs.
Other examples in design practice which feature this Characteristic include Madhavan et
al.'s previously discussed study (Madhavan et al. 2008). The authors help substantiate this claim
by pointing out how their set-based method encouraged Schlumberger to conduct tradeoff analyses
at the subsystem level, such as the tradeoff between mass and stiffness in a given chassis design.
Studying design spaces across interfaces was not prioritized prior to applying set-based methods,
implying a less formal exploration of optimality when compared to applying SBD.
Examining the Navy's SSC project once again, Mebane et al. reported that Systems
Engineering Managers would communicate "ranges of solutions with associated derived
requirements for various systems.. .rather than develop a single point solution" (Mebane et al.
2011). The result was the consideration of a "far greater range of options.. .than would have been
28
considered in traditional point-based design evolutions...in a much shorter time period." Of
course, this extended exploration is a key feature towards the exploration of more optimal
solutions.
Finally, beyond case study examples, the aforementioned example of technology
characterization models (TCMs) illustrates this Characteristic well. As noted earlier, TCMs were
developed to address the problem of how to present and explore the technical capabilities of certain
types of ill-characterized complex systems (Parker and Malak 2011). Algorithms developed from
this work feature a bottom-up flow of information (Galvan and Malak 2012). The rationale for
this approach is that when subsystems explore optimality, this should scale up to the greater system
level in efforts to approach a global optimum. In essence, these efforts by Malak and colleagues
are to mathematically model an approach that resembles the flow of information that exists
between Toyota and its suppliers, such as Nippondenso.
2.3.7 Supports Flow-up Knowledge Creation
As alluded to in the discussion of the previous section, the supplier/subsystem exploration
of optimality lends itself to supporting flow-up knowledge creation. What is truly indicative of
this Characteristic is the timing of suppliers' presentations to Toyota. Delivered about 36 months
prior to the start of new model production, these presentations allow suppliers to describe their
latest developments to Toyota, which includes prototypes, large amounts of test data, and related
information. The critical difference between Toyota and competitors as reported in Ward et al.
(1995) is that while US companies would develop specifications in-house prior to these types of
presentations, Toyota would develop its specifications almost two years after its supplier
presentations. In other words, it would take information from these presentations to guide critical
decision making behind setting final specifications, indicating a bottom-up flow of information, as
opposed to the traditional top-down flow where specifications were handed down by US
manufacturers.
An excellent example of how SBD was applied for its flow-up qualities is provided by the
aforementioned study by Parrish et al. (Parrish et al. 2007). As noted earlier, the intent of Parrish's
work is to involve all agents across the construction supply chain (e.g. owners, architects, structural
engineers, concrete suppliers, etc.) in the design decision-making process. This is in contrast to a
29
traditional model where a structural engineer will make all decisions up front, leading to a single,
often suboptimal, design. This flow of decision making is decidedly top-down, as opposed to
Parrish's approach which empowers subsystems (i.e. agents such as concrete suppliers) in the
decision-making process, leading to a bottom-up flow of information.
Academic examples of this Characteristic include the work of Malak and colleagues as
noted in Section 2.3.6 regarding TCMs. By optimizing subsystems first, the flow of information
is certainly bottom-up. Other examples include work from Shan and Wang, who develop an
algorithm using rough sets to map "the performance space to the design space" that "could be
potentially used to explore and visualize the entire design space" (Shan and Wang 2004). The
performance space that these authors refer to is attributes at the subsystem level, whereas the
design space is the greater system level. Thus, similar to Malak and colleagues, these authors wish
to use sets to map performance capabilities at the subsystem level to a higher level system level
space to pursue globally optimal design-entailing a flow-up approach. Finally, more recent work
is presented by Canbaz et al., who in studying distributed design processes, expand the "bottomup design approach with exploring agent-based modeling techniques into the set-based design
concept" (Canbaz, Yannou, and Yvars 2013).
2.4 The Two Principles of Set-Based Thinking
Having reviewed evidence for the 7 Characteristics of SBPD, we now turn our attention to
the development of 2 Principles of Set-Based Thinking (the 'Principles'). This section is organized
as follows. In Section 2.4.1, we present the Principles, and in Section 2.4.2 we introduce the SetBased/Point-Based Process Spectrum, which enables us to analyze the degree to which certain
processes exhibit set-based or point-based characteristics. Finally, in Section 2.4.3, we detail how
the 7 Characteristics of SBPD lead us to obtaining 2 Principles of Set-Based Thinking.
2.4.1 The Two Principles of Set-Based Thinking
At this point in our study, we make the following observations:
-
SBD is not formally defined, yet numerous authors have studied its process inspired by the
example of Toyota
30
*
The 7 Characteristics of SBPD are a filter which allow us to review work that exhibits setbased practice
A major challenge in our task to define what SBD means is determining what work to
include and what not to include in our review-which is the function of the 7 Characteristics.
Having reviewed the literature of set-based practice in Section 2.3, our task now is to find the most
common themes and ideas in this reviewed work that capture SBD, which we term the Principles.
Our review supports the finding of two, independent Principles. These Principles are regularly
woven into the ideas discussed in the work reviewed, both explicitly and implicitly.
At this phase of our preliminary study, we cannot guarantee that these are the only two
Principles; however, our goal was to distill the network of complex ideas in Section 2.3 into the
most simple, fundamental representation possible, which led to the articulation of these two
Principles. As a preliminary validation of this approach, in Section 2.4.3 we explain how the 7
Characteristics of SBPD directly embody the Principles. But first, we present the Principles:
1. Considering sets of distinct alternatives concurrently
2. Delaying convergent decision making
Central to the ideas of SBD and related work is the concept of concurrent development,
which is captured by Principle 1.
Concurrent development describes the simultaneous
development of distinct concepts. This is in contrast to traditional, point-based processes, where
designers establish commitment early on to one concept which receives the singular focus of the
designers involved. It is important, however, to establish the distinction between the development
of sets of distinct concepts and the development of sets of variants of a single concept. The former
captures the true ethos of SBD as noted in the introduction, which is to consider as many unique
options as possible. The latter exhibits a limiting case of SBD and may regress to traditional, PBD
processes.
To demonstrate the difference between sets of distinct concepts and sets of variants of a
single concept, consider finding a solution to travel from the city of Rochester, NY, USA to
Toronto, ON, Canada. One may consider renting a car, taking a bus, or hiring a limousine service.
However, these options entail variants of a single concept: to travel by highway. Other potential
31
options include train, airplane, and even a ferry ("HSC Dolphin Jet" 2013). While this is a simple
example, it illustrates that comparing sets of variants of a concept limits the solution space explored
and does not provide the full intent of Principle 1. Nuances such as these will be important to keep
in mind when analyzing the spectrum of set-based and point-based processes, as presented in
Section 2.4.2.
Equally important to SBPD is the second Principle: delaying convergent decision making.
Note that this Principle does not advocate delaying decisions for the sake of delaying decisions;
rather, it supports delaying convergence to a single solution.
Some authors highlight this
distinction by pointing out that decisions should be delayed until the "last responsible moment"
(Gil, Beckman, and Tommelein 2008). The emphasis on "responsible" highlights how decision
delay as a strategy should not be exercised as an excuse to simply not make decisions. Instead, it
should facilitate the consideration of more options. Specific to SBD, following this Principle
results in a process where the solution space gradually narrows to a single solution, as opposed to
traditional, point-based representations, which promote rapid convergence and reiteration on a
single concept that may require rework calling for re-expanding the solution space down the road
(Sobek, Ward, and Liker 1999), which intuitively is a source of inefficiency.
2.4.2 The Set-Based/Point-Based Process Spectrum
In previous sections, we alluded to the idea that PD processes should be qualified on a
spectrum that encompasses SBD and traditional, PBD processes.
Such a spectrum can help
highlight how some processes may exhibit certain characteristics of set-based PD but still not
represent an ideal case of SBD. A question that has gone unaddressed in the body of SBD research
is finding heuristics for determining when it is appropriate to apply set-based vs. point-based
techniques. Thus, a spectrum that helps us classify to what degree a certain process represents a
complete implementation of SBD is a first step towards answering that question.
In order to develop a set-based/point-based process spectrum, we first need a definition for
PBD. This is a non-trivial task and is similar to attempting to define a primitive notion-in the
sense that point-based, traditional design processes encompass that with which we are already
familiar.
In his discussion of agile product development processes, Lansiti characterizes
traditional design processes as those where detailed design and implementation occurs only after
32
concept selection occurs (lansiti 1995). Along these lines, Ulrich and Eppinger, commenting on a
generic (i.e. traditional) product development process, posit the following about concept
development, "alternative product concepts are generated and evaluated, and one or more concepts
are selected for further development" (Ulrich and Eppinger 2012).
While these definitions capture some of the distinctions of point-based design relative to
SBD, they are generally incomplete and refer only to the interface between the concept
development and detailed design phases.
This is limiting since the Principles can manifest
themselves at all phases across the design process. Therefore, we propose a working definition
for point-based and traditional design processes that is defined relative to our definition of SBD.
Similar to how temperature is defined on a relative basis to a given reference point (absolute zero),
we wish to define point-based and traditional design relative to the 2 Principles of Set-Based
Thinking. Let A = Principle 1 ("considering sets of distinct alternatives concurrently") and B =
Principle 2 ("delaying convergent decision making). From these statements, we can define SBD
succinctly:
SBD EA A B
In other words, SBD (or more generally, SBPD) is defined by Principle 1 and Principle 2.
We define traditional design relative to SBD in the following way:
TraditionalDesign
-,SBD = -,(A A B) = -,A V -,B
In other words, traditional design is simply "not SBD." Thus, by DeMorgan's Law, it
encompasses a lack of Principle 1 or a lack of Principle 2, or a lack of both Principles 1 and 2,
since we use the inclusive definition of "or" in the notation above. In fact, where both a lack of
Principle 1 and a lack of Principle 2 are exhibited, we have a special case of traditional design,
which is pure PBD. The rationale for this working definition is that if a process exhibits one of
Principle 1 or Principle 2, then it inherently bears some set-based characteristics, and thus should
fall in a spectrum between the poles of SBD and PBD, where pure PBD represents cases that do
not bear any set-based characteristics. This spectrum is demonstrated visually in Figure 1.
33
SBD
PBD
BOTH:
Either/or
Neither:
- Principle 1
- Principle 2
- Principle 1
- Principle 2
- Principle 1
- Principle 2
Y11
SBPD
-"YJ
Traditional Product Development
Figure 1: The Set-Based/Point-Based Process Spectrum
An important question to ask is whether the Principles can be considered independently in
the proposed spectrum. That is, can Principle 1 act independently of Principle 2, and vice-versa?
For instance, does a process exist where we consider sets of alternatives concurrently without
delaying convergent decision making?
The answer is yes-consider the example of a
morphological matrix. This method hastens the consideration of a very large number of distinct
alternatives (Pahl and Beitz 1988). Still, Pahl and Beitz note the "weakness of this approach" by
noting "the very great, theoretically admissible but practically unattainable, number of solutions
must be reduced at the earliest possible moment." Thus, using a morphological matrix is not
conducive to promoting decision delay.
Now let us consider the opposite case: a process that delays convergent decision making
but that does not necessarily promote considering sets of distinct alternatives concurrently. A good
example here is the overuse of a product platform, such as Chrysler's K-car platform in the late
1980s (Simpson 2004). While product platforms clearly enable the delay of convergent decision
making (product can be tailored later to target niches, see Section 2.3.2), designers in a push for
leveraging commonality may feel inclined to use it more often than they should, thus limiting the
consideration of distinct alternatives.
Thus, we have demonstrated via example how the two Principles can act independently of
one another, and critically how they must both be present in order to facilitate true SBD.
34
2.4.3 Deriving the Two Principles from the Seven Characteristics of
Set-Based Product Development
In this section, we detail the process by which the 7 Characteristics of SBPD reveal the 2
Principles of Set-Based Thinking. Note that some of the 7 Characteristics support one Principle
more than the other. However, considering the 7 Characteristics holistically allows us to arrive at
developing the 2 Principles.
Thus, we go through each Characteristic demonstrating their
collective support for the Principles.
Emphasis on Frequent Lo-Fidelity Prototyping
Prototypes enable designers to compare several distinct alternatives as embodied by the
aforementioned design language argument in (Yang 2005), thus exhibiting support for Principle
1. Furthermore, the emphasis on prototyping early and with lo-fidelity (Haggman, Honda, and
Yang 2013) enables further concurrent development, thus postponing convergence to a single
concept and supporting Principle 2.
Tolerance for Under Defined System Specifications
Designers using set-based techniques are comfortable with incomplete information, and
thus can work with concepts without necessarily forcing convergence to continue development, as
demonstrated in (A. Ward et al. 1995; Gil, Beckman, and Tommelein 2008; lansiti 1995; Thomke
and Reinertsen 1998; Mebane et al. 2011)-thus supporting Principle 2. In fact, incomplete
information is often fostered by system managers (A. Ward et al. 1995; Sutherland et al. 2007; Gil,
Beckman, and Tommelein 2008; Schwaber and Sutherland 2013), inducing designers to further
explore the solution space and reinforcing concurrent development and support for Principle 1.
More Efficient Communication among Subsystems
Communicating via sets is inherently more efficient than passing information sequentially
and iterating on a point-based solution (A. C. Ward and Seering 1989; A. Ward et al. 1995; Parrish
et al. 2007; Madhavan et al. 2008; Mebane et al. 2011; Parker and Malak 2011), supporting
concurrent development and Principle 1.
35
Emphasis on Documenting Lessons Learned/Knowledge
Several examples described in Section 2.3.4, from Toyota's lessons learned books,
pharmaceutical companies' chemical libraries, and IDEO's Tech Box illustrate how documenting
knowledge can lead to the consideration of a wider set of options, supporting Principle 1 [15]. In
addition, by allowing designers to reason about why options should remain in play such as with
function structures (Pahl and Beitz 1988), Principle 2 is upheld.
Support for Decentralized Leadership Structure and Distributed, NonCollocated Teams
The concurrent development of distinct alternatives is easily performed in distributed, noncollocated settings (A. Ward et al. 1995; Sutherland et al. 2007; Mebane et al. 2011), unlike
traditional processes that rely on iteration and require centralization. Thus Principle 1 is sustained.
Supplier/Subsystem Exploration of Optimality
System managers of set-based processes will not provide predetermined specifications to
suppliers (A. Ward et al. 1995; Malak and Paredis 2010; Parker and Malak 2011), who in their
search for optimality will need to adopt the concurrent development of distinct alternatives (Parrish
et al. 2007; Madhavan et al. 2008), fostering Principle 1. By tasking subsystems to explore
optimality, the system manager also inherently delays convergence by fostering set-based
exploration as opposed to point-based exploration (A. Ward et al. 1995; Raudberget 2010;
Madhavan et al. 2008), supporting Principle 2.
Supports Flow-up Knowledge Creation
Following from the last Characteristic, supplier exploration of optimality, which is
achieved via concurrent development, fundamentally enables a flow-up knowledge creation, thus
promoting Principle 1. Similarly, from Nippondenso's example we saw how system managers
(i.e. Toyota) delay convergent decision making until subsystems perform their tasks of exploring
subsystem level optimality, enabling a bottom-up flow of knowledge that is conducive to
supporting Principle 2.
36
2.5 Case Example: Set-Based Thinking in Function
Structures
Having developed the Principles in the previous section, we now turn to a brief case
example to illustrate how these Principles manifest themselves in a common theoretical construct
in design: function structures. We intentionally choose to explore function structures as they are
an example of work that is not nominally related to SBD but that we review in this work as it
&
features set-based reasoning. An example of a real-world function structure for the Black
Decker@ VersaPakTM Cordless Screwdriver (Dahmus, Gonzalez-Zugasti, and Otto 2000) is
provided in Figure 2. Further reading on the background and theory of function structures is
referenced in Section 2.3.4.
In a function structure, each sub-function can embody a wide array of physical
configurations-the function structure does not discriminate in this regard. Refer to the example
in Figure 2. While the sub-function "input signal" has been implemented via a sliding switch in
the final product shown, the sub-function itself enables consideration of options such as a pushbutton switch or a rotary switch to name a few examples. Thus, function structures clearly enable
the consideration of sets of distinct alternatives, or Principle 1.
However, the real value of function structures in the context of set-based reasoning is
realized by plotting the flow of signals and other system interactions, nicely articulating constraints
on the solution space in which designers explore. This allows designers to reason about which
alternatives to explore and which to not explore-a line of reasoning that extends back to the
genesis of SBD (A. C. Ward 1989; A. C. Ward and Seering 1989). In this sense, it facilitates
Principle 2, the delay of convergent decision making, because all physical instantiations that meet
the requirements of the function structure are carried through the design process.
This is a
methodical way to practice decision delay, as opposed to morphological matrices (see Section
2.4.2), where coarse heuristics must be applied in order to rule out options that do not meet system
physical constraints. Such heuristics may eliminate more options than required, thus preventing
the delay of convergent decision making.
37
Hand force
-~------~
Register
Battery --~ Battery
Unregister ~-~ Battery
Battery
Transmit
Electricity
~--------+----------~-- Force into
opposite hand
Noise. Heat -
----j
Torque
Prevent
Back
Rotation
Screw
Turn
Screw
Permit
Bit
Positionin
Hand Force
Hot turning screw
_____ _..,.. Bit position
Reaction force
Bit
L~
Bit
--~~~~~secur
~e~---~~~~~~~--~~-- Fm:eruo ·
opposite hand
Figure 2: Function Structure for a VersaPak TM Cordless Screwdriver. From (Dahmus,
Gonzalez-Zugasti, and Otto 2000).
2.6 Discussion and Conclusion
In 1995, Ward and colleagues documented Toyota' s unique PD practices as examples of
SBCE, generating a flurry of research into SBD and set-based reasoning across academic
communities, such as engineering design, management science, civil and structural engineering,
software design, and ship building, to name a few examples. Over this time period, SBD has never
been formally defined, despite many authors having studied its process inspired by the example of
Toyota.
In this chapter, our objective is to inductively identify common themes and ideas from the
body of work that has emerged since Ward et al. (1995)'s original study. From their study, we
identify 7 Characteristics of Set-Based Product Development, which essentially are observed
attributes of set-based processes. We then employ these Characteristics as a filter by which to
choose what research to review in this work. We review work that is both nominally tied to SBD
and also that which actively features set-based reasoning. After studying the sample of literature
38
that we generate, we find two, independent principles that are both explicitly and implicitly
integrated into the ideas of the literature reviewed in this work. These are 2 Principles of SetBased Thinking, which are 1) considering sets of distinct alternatives concurrently, and 2) delaying
convergent decision making. We use these Principles as a basis by which to offer a working
definition for SBD.
We also introduce the Set-Based/Point-Based Process Spectrum, which
provides a preliminary way to represent the idea that some processes may exhibit certain
characteristics of Set-Based Thinking without being an ideal case of SBD, thus presenting a hybrid
of set-based and point-based reasoning.
Taking a step back, we may ask: what do the Principles of Set-Based Thinking mean in
practice? What does it mean for a process or a tool to be classified on the "SBD" end of the SetBased/Point-Based Process Spectrum?
Considering the simultaneous effects of concurrent
development and delaying convergent decision making, we can assert that the consequence of SetBased Thinking is the consideration of more options. This result should not be surprising, as we
note that the motivating ethos of SBD was to create a framework in which options would not be
eliminated from consideration unless there was a logical reason to do so.
In a sense, the intellectual foundation of SBD makes the normative assumption that
considering more options throughout the process is inherently a good practice in design and PD.
Considering more options as a heuristic is the goal of many creativity and innovation techniques
explored in the literature and is promoted in broad-based paradigms such as Design Thinking
(Dym et al. 2005). In making the case for SBD, many practitioners have touted the promise of
better, novel outcomes to result from having considered more options (Singer, Doerry, and
Buckley 2009; Mebane et al. 2011). However, in practice, many of these practitioners noted a lack
of truly novel concepts to result from following the process, reflecting that the end outcomes
obtained were not surprising and could have been anticipated ("Ship-to-Shore Connector
Implementation of Set-Based Design" 2009).
This observation raises a host of questions. First, is it valid to assume that considering
more options throughout the process will generate better outcomes? What makes considering more
options difficult? What are the ensuing implications for Set-Based Thinking and the way we think
about the process in general, especially in the front end when most divergent thinking occurs?
39
These questions and others shall form the underlying intellectual core to our development of a
novel framework for product development, which shall be the focus of the remainder of this work.
40
3. A New Framework for the Product
Development Process
Having grounded ourselves in the literature in the previous chapter, this chapter begins to
lay the groundwork for the development of a novel framework for PD, which shall be the focus of
the remainder of this work.
framework.
In Section 3.1, I identify the motivation for developing such a
Following this, I introduce the terms which shall define the language of this
framework in Section 3.2, with the roles each term plays explained in Section 3.3. In Section 3.4,
I reference prior use of these terms in the literature, and I conclude the chapter in Section 3.5 by
identifying some of the ideas which shall be explored in further detail in the chapters to follow.
3.1 Motivation and Background
In advancing the inquiry on SBD and related techniques that we began in Chapter 2, we
were troubled by an observation that became abundantly clear not only as the literature review
progressed, but also during the formal presentation of this work at the 2014 ASME International
Design Engineering Technical Conferences (Ghosh and Seering 2014). That is, despite the welldocumented interest in SBD as a topic of study, there existed a lack of agreement on the use of
basic terms and concepts discussed in this literature. Given some of the misunderstanding that
ensued during discussion of fundamental elements of the PD process that accompanied SBD, it
became clear that this issue transcended the SBD literature and was indicative of a larger issue in
the greater design and PD literature.
Of course, it would be naYve to assume that we were the first to notice this issue in the
design literature. In her reflections of the Human Behavior in Design Conference in 2003, Blessing
succinctly describes the problem we face (Blessing 2003). An excerpt of these reflections is
provided below:
"Although the participants formed a specialized part of the design research community as a whole,
the issue of differences in terminology became very clear. Terms borrowed from other disciplines
had been interpreted in different ways, the disciplines represented by the participants had their own
41
terminology unfamiliar to the others and the same terms coming from participants from different
cultures had a different meaning. This resulted in confusion, discussion and a clearly expressed
need to have a common terminology. A common terminology, was seen as essential for a research
area. Only in this way a common understanding and building on existing work can be realized."
Along these lines, Blessing also notes calls during the meeting for a "common model" for
design:
"The wish for a common model or a set of (partially shared) models came up frequently.
models exsit, most research results remain unconnected.
Few
Such a model would indicate a better
understanding of design and would provide a shared understanding, a basis on which to do
research."
At the time of this writing, it has been over a decade since Blessing's calls for a common
terminology and common model have been published.
However, during our experience of
articulating the SBD and affiliated literatures, it is clear that the issues underlying Blessing's
observations continue to trouble our academic community. As Blessing notes, existing work in
our community cannot build on itself without a common understanding of the terminologies and
models we use, as misinterpretations of each other's work will not foster an environment
conducive to generating the deeper insights about the PD process that we desire.
The remainder of this work is my humble attempt to address Blessing's concerns (and in a
broader context, Simon's call for the formalization of design science as established in Chapter 1)
by developing a novel framework for PD theory and methodology. The following sections will
introduce the terminology upon which we shall build this emergent framework, which shall result
in a fundamental reinterpretation of certain elements of the PD process.
This framework is
certainly not presented as the "common model" by which all other work in our community shall
be interpreted; rather, it is presented as another way to interpret the basic PD process with which
we are familiar. It is ultimately up to the community to determine the usefulness of this framework
in addressing the latent research challenges in the PD literature following the publication of this
work.
In developing this framework, we shall remain cognizant of the challenges we identified at
the conclusion of Chapter 2, such as: why is the consideration of more options difficult in practice?
42
And why does considering more options not necessarily guarantee better outcomes? However,
before we can address these questions more directly, we must define the lexicon upon which our
framework shall develop.
3.2 Definitions
In this section, I will outline definitions for the framework. Each subsection is titled with
a specific term, followed by the formal definition of that term listed in italics below the subheading.
Below the definitions are brief discussions on the respective terms, including examples of the terms
in use. For clarity, the first few references to each term (including those referenced prior to their
formal definition) are recognized in bold text.
Architecture
'An expression ofform of unspecifiedresolution."5
The term architecture is one of the most often used yet ill-defined terms in the design
theory literature, as we will note in the subsequent sections discussing the terms of the framework
in use. We break this definition into two parts and illustrate each with an example to understand
its implications.
In this definition, "unspecified resolution" plays an important role as it enables the broad
representation of ideas using the term architecture (please see definition below for resolution).
For instance, the concept of a V6 engine (before any parameters such as displacement have been
formally specified) qualifies as an architecture, as does the fully-specified historical example of
the 1950 Lancia Aurelia 1.8L "1800" V6 engine. 6
5 In Section 3.4, this definition of architecture shall be contrasted with prevailing norms for the term in the greater
engineering design literature. Before proceeding, to preemptively avoid any misconceptions, it is important for the
reader to note that my definition for architecture does not include notions of function (it is only defined in terms of
form). This will be discussed in further detail in the following sections.
6
The 1950 Lancia Aurelia was the first production car to feature a V6 engine, where the "1800" engine was the first
V6 configuration Lancia offered.
43
The first half of the definition, "an expression of form," can support a variety of
interpretations. Given the traditional context of studying problems pertaining to mechanical design
within the engineering design community, form is typically thought to imply or represent a
physical artifact. Accordingly, we are often conditioned to think of architectures as physical
artifacts. However, form may also represent itself in analogues in other domains. For instance, in
the context of software, consider a program to aid in the task of prototyping. Here, an architecture
may represent a CAD program. In service design, consider the example of designing a way to
administer health insurance. In this context, an architecture may represent a health maintenance
organization (HMO).
As the distinction among product, software, and service design continues to blur now and
in the years ahead, a more global definition of architecture is necessary for the future of design
and product development research. Many commentators today actively employ this holistic view
of PD, with one of the most popular editorials to be distributed within PD and innovation circles
the year this thesis was published arguing that companies should be more concerned with
controlling "customer interfaces" rather than the traditional supply chains that deliver goods and
services (Goodwin 2015). While it remains to be seen whether this argument will be valid in the
years ahead, it has captured the interest of those outside our academic and professional community
(Friedman 2015). As a research community, we must remain cognizant of popular views of PD
practice (in this case the increasing obscurity of the boundaries between physical and non-physical
PD) in order for our work to better serve and educate those outside our sometimes insular academic
circles.
Resolution
"The degree to which an architectureis embodied or detailed."
The resolution of an architecture is defined in relative terms. In the example provided
above with the definition of architecture, the unspecified concept of a V6 engine would be qualify
as a "low" or "coarse" resolution architecture relative to the fully-specified 1950 Lancia Aurelia
"1800" V6 engine. Another way of saying this would be to call the 1950 Lancia Aurelia "1800"
V6 engine a "high" or "fine" resolution architecture relative to the unembodied concept of a V6
engine.
44
As noted earlier, an architecture may simply represent a concept that has not necessarily
been expressed physically yet (e.g. via physical prototype, etc.). Demonstrating the relative nature
of resolution, when considering engine configurations, other architectures that may be considered
to be at the same level of resolution as the unembodied concept of a V6 engine would be those of
a V8, or an inline-four layout.
Design Parameter
'An attributedescribing a characteristicof form or architecture. Can be describedsuccinctly as
an axis of the architectural domain."
With this framework, we hope to be able to articulate the progression of ideas throughout
the design process. In order to do this, we must be precise about how we are measuring ideas.
Essentially, any attribute we use to describe form, either qualitative or quantitative, can be thought
of as a design parameter. Examples of design parameters include dimension, mass, material
used, and color, to name a few instances.
Specification
'An attributemeasuringperformance ofa design. "7
While design parameters describe attributes of architecture (thus helping us articulate
characteristics of form), we also need parameters which measure the performance of a concept,
idea, or design. This is the role of a specification. Consider the example of a #2 pencil. The #2
(or HB) grading represents an attribute of architecture and thus would be classified as a design
parameter. However, attributes such as 1) the bending moment exerted to snap the #2 pencil in
half (measured in Newton-meters), and 2) the time (in seconds) and 3) the exerted force required
(in Newtons) to erase a standardized sentence written by the pencil all represent specifications.
7 Given the prevalence of the Ulrich and Eppinger's paradigm to describe specifications (Ulrich and Eppinger 2012)
in the PD process (as we will address in Section 3.4), I should preemptively clarify that this definition for specification
does not include notions of performance targets. In this framework, a specification is essentially a performance
variable-it does not however imply target values for such performance.
45
Architectural Domain
"The M-space of design parameters which define a design's architecture, where Mis an arbitrary
positive integer."
The architectural domain is the first of two domains that are central to describing the
PD process using the framework. It is the space in which designers can articulate form, using
qualitative and quantitative design parameters as descriptive attributes.
While the architectural domain itself does not exist in any meaningful tangible form (it is
an abstract solution space), an interesting analogy to consider here is a detailed engineering
drawing. The information portrayed on such a drawing can be thought of as a subset of the design
parameters in the architectural domain, such as dimensions, material choice, and perhaps even
information on color choice.
Note, however, that not all pertinent attributes depicted on an
engineering drawing qualify as potential axes of the architectural domain. For instance, indication
of which manufacturing method to use would better qualify as a constraint that acts upon the
architectural domain. 8 See Figure 3 for an example.
Finally, regarding the nomenclature of this domain, the reader may be wondering why it is
not simply called the "design parameter" domain, given that this space is essentially embodied by
the design parameters of a particular design. The reason is to emphasize that architectures reside
natively in this domain (unlike the specification domain, upon which they must be projected).
This distinction is discussed in further detail in the sections and chapters to follow.
8 Since manufacturing method employed does not intrinsically describe form (rather, it acts upon form by for instance
influencing its shape, thus influencing the values that certain design parameters take), it is better described as a
constraint that acts upon the architectural domain.
46
S
.
..
.375
3X .37
0 1900
5
-03.00
2X .500 12
.T2MWT.132
SEE
4
NOTE
R .375
0 2,100
R 150
200
~TE 125
2.900
R .100
500
R.2
SECTIO0N 'A-A'
.150 -NDTE
1. LET TERING TO BE MACHINED WITH A 60 DEG,
ENRAVINO TO(L TO A DEPTH OF .007' DEEP.
Figure 3: An Engineering Drawing. The drawing displays detailed information on dimensioning of
form in addition to a note regarding a preferred manufacturing method. This is a constraint on the
architecture, since the desired geometry can be produced using methods other than machining with an
engraving tool, illustrating the point earlier that the manufacturing method does not intrinsically describe
form. Image from (Gossard 2009).
Specification Domain
"The N-space of product specifications, N is an arbitrarypositive integer. Articulates product
function andperformance."
Whereas the architectural domain exists to describe a product's form, the specification
domain exists to articulate its specifications. In the aggregate, it is the performance space in
which designers measure project success and whether or not they are meeting the objectives for
47
their design. Accordingly, it is helpful to think of the specification domain as that in which
optimization problems in the engineering design literature are solved. Comparisons to existing
work on multidisciplinary design optimization (MDO) will be drawn in later sections.
Instance
'A specific instantiationofa given architecture. A group ofinstancesmay be sampled to represent
the idea behindan architecture."
In order to truly embody the ethos of considering more options, one must have a process
to compare several distinct architectures which span large parts of the specification domain. To
do so, we must develop a sense of what are distinct architectures to compare and what are simply
variants 9 of one architecture. The term instance helps us articulate one particular occurrence of
an architecture. Furthermore, as implied from the definition, specific instances are often necessary
to understand an architecture and its characteristics and behavior.
To illustrate instance and groups of instances, consider the BMW 3 Series, produced from
2004 to 2012. At an arbitrary level of resolution, an instance of this particular 3 Series platform
is the E90 Sedan (or Saloon). Furthermore, a group of instances at the same level of resolution
include the E90 Sedan, the E91 Wagon (Estate), the E92 Coupe, and the E93 Coupe/Cabriolet. At
a finer level of resolution, an instance may include the "pre-facelift" 2004-2008 E90 3 Series,
shown in Figure 4. An instance of finer yet resolution would be the 2008 328i Sedan (produced
for the North American market).
9To understand the notion of a variant, please refer to the Rochester-Toronto travel example provided in Section 2.4.1.
48
Figure 4: A Comparison of the "Pre-facelift" 2004-2008 E90 3 Series Sedan to the
Facelifted Sedan Produced for Model Years 2009-2012. The "pre-facelift" sedan is shown on
the right for the front and rear views of the sedan.10
Point
'An instance of a given architecture(see instance). Can be used in contrastto "set" to illustrate
the final, production version of the design chosen from the initialsolution space (expressed in the
architectureor specification domain)."
10 Images from ("BMW 3 Series (E90) 2005-2008" 2015) and ("BMW 3 Series (E90) 2008-2011" 2015).
49
While a point nominally qualifies as an instance, it can be used in a more descriptive sense
to illustrate the final production version of a product. This distinction will become clear when
describing the process holistically using the framework in Chapter 4. Accordingly, to extend the
example provided for instance, a point would be the 2008 328i Sedan, embodied down to all
features that were installed at the factory (e.g. a "cold weather package" that includes optional allweather mats, etc.).
Set
"The collection ofall feasible instancesat a given level ofresolution of a design. Can be used to
describe the solution space under consideration."
Use of the term "point" bears more meaning in the framework when understood in contrast
to "set." This definition for set is consistent with Ward's original notion of "set" (discussed in
Section 3.4) which refered to the collective solution space being considered at any point in time,
gradually narrowing as the process progresses.
Suppose one is given the objective to produce visible light. The set would be to produce
electromagnetic radiation nominally between the wavelengths of 400 and 700 nanometers. All
wavelengths outside of this spectrum (e.g. gamma rays, far infrared rays, etc.) are not part of the
set as they are not feasible instances that meet the given objective.
Constraint
'A condition that an architecturemust satisfy. May be representedanalyticallyin the architectural
and/orspecificationdomain."
As implied from the definition, constraints act upon the solution space (whether
examining the architectural or specification domain) by influencing the boundaries of the set under
consideration.
Certain constraints reveal themselves as the process progresses through time,
leading us to classify constraints as either "active" or "dormant," according to the definitions
below:
Active constraint: A constraintthat is currentlyacting upon the set
Dormant constraint:A constraintthatis currentlynot acting upon the set
50
................
Examples of active constraints include laws of physics (which are active from the onset as
one cannot generate feasible options which violate these basic principles) and environmental
regulations (for instance, EPA emissions regulations that are in play during the consumer end-use
of a motorcycle). Conversely, dormant constraints may include supply chain conditions (prior to
the detail design phase of Ulrich and Eppinger's generic PD process (Ulrich and Eppinger 2012))
and anticipated government regulations (e.g. during concept development, where a PD team may
be producing a design to be compliant with regulations that are due to become enforced once the
product hits the market).
One important caveat to note is that in practice, constraints are not activated in a binary
sense. That is, one cannot simply classify a constraint as being simply "dormant" or "active;"
rather, most constraints undergo a process of being gradually activated as the design process moves
forward. This will be alluded to in the following chapters and discussed in further detail in Chapter
8.
Feasibility
'A state describing whether or not an architectureis attainable. Expressed analytically as the
solution space that is bounded by all active constraints."
Feasibility is the condition that explains whether or not to include certain instances within
the set. Note that this is a more restrictive definition than notions of technical feasibility, since an
active constraint unrelated to technical performance may limit the set that is to be considered, thus
making certain options unattainable.
Consider the example of desktop 3D printers for personal use.
While the additive
manufacturing techniques behind these machines have existed for years (e.g. Fused Deposition
Modeling, etc.), one of the biggest factors prohibiting the early development of personal 3D
printers was that they were cost-prohibitive due to patents on these techniques. Given the active
constraint of the cost that consumers were willing to personally pay, the open-source development
that one sees in the personal 3D printer sector today was rendered infeasible (Bilton 2015).
51
Table 1: Definitions Summary with Examples
Term
Definition
Example
Architecture
An expression of form of unspecified resolution.
V6 engine, CAD software, HMO
(health insurance provider)
Resolution
The degree to which an architecture is embodied or detailed.
Unembodied V6 concept vs. 1950
Lnci
0 ene
Design
Parameter
An attribute describing a characteristic of form or architecture. Can be
described succinctly as an axis of the architectural domain (see
definition below).
Dimension, mass, material, color
Specification
An attribute measuring performance of a design.
For a #2 (HB) pencil: bending moment
to break in half, time/force required to
erase a standardized sentence
Architectural
Domain
The M-space of design parameters which define a design's architecture,
where Mis an arbitrary positive integer.
A subset of the parameters included in
an engineering drawing
Specification
Domain
The N-space of product specifications, Nis an arbitrary positive integer.
Articulates product function and performance.
Domain for optimization
Instance
A specific instantiation of a given architecture. A group of instances
may be sampled to represent the idea behind an architecture.
2008 BMW 328i Sedan (instance of the
E90 3 Series)
An instance of a given architecture (see instance). Can be used in
Production version of 2008 BMW 328i
contrast to "set" to illustrate the final, production version of the design
chosen from the initial solution space (expressed in the architecture or
specification domain).
Sedan (e.g. with "cold weather
package")
Point
52
Lancia " 1800" engine
Term
Constraint
Feasibility
Definition
Example
The collection of all feasible instances at a given level of resolution of a
design. Can be used to describe the solution space under consideration.
Visible light: wavelengths of 400 to
700 nm
A condition that an architecture must satisfy. May be represented
analytically in the architectural and/or specification domain.
Active currently acting upon the set
Dormant currently not acting upon the set
Active laws of physics, environmental
regulations (during consumer end-use)
Dormant supply chain (prior to detail
design), anticipated government
regulations
A state describing whether or not an architecture is attainable.
Expressed analytically as the solution space that is bounded by all active
constraints.upon
Develpent ofprson
patent expiration
53
Summary
For a succinct summary of the previous section, complete with definitions and the
examples discussed, please refer to Table 1.
3.3 Role of Terms in Framework Thinking
The terms in the framework and their definitions were chosen in a way to provide a
different perspective on the standard PD process with which we are familiar. To help understand
the role of these terms in the context of articulating the process, please refer to Table 2. While
certain notions in this framework are fundamental (such as the role of design parameters and
specifications), others such as the relationship between the architectural and specification domain
and the role of constraints and feasibility in moving the process forward are non-trivial and will
be discussed in further detail in the sections to follow.
Table 2: Interpreting the Terms of the Framework
Terms
Role in Framework
Architecture and Resolution
Ways to think about ideas during the process
Design Parameter and
How we measure ideas (form and performance, respectively)
Specification
Architectural and
The two solution spaces in which we work
Specification Domain
Instance, Point, and Set
How we describe ideas in the aforementioned domains
Constraint and Feasibility
The mechanism by which the process moves forward (e.g. ideas
narrowed, architectures embodied/detailed, etc.)
3.4 Use in the Literature
This section reviews common uses in the engineering design literature of the terms outlined
in Section 3.2. Since many of the terms presented here have been used extensively prior to this
54
work, I wish to review a non-exhaustive sampling of these prior uses. I also take the opportunity
to point out if and how my definitions differ from established use, in addition to some of the
implications of making such choices for the framework.
Architecture
Architecture is a notion that is central to the study of product development, and yet it is
often informally defined in the engineering design literature. We shall begin this brief review by
turning to two of the most influential educational texts on design theory: the works of Pahl and
Beitz (Pahl et al. 2007) and Ulrich and Eppinger (Ulrich and Eppinger 2012), respectively. As
these texts serve as many students' introduction to the product development process (thus
impacting the perceptions they develop about the process early on), they seem to be an appropriate
place to establish this review.
By way of discussing the modularization of product designs, Pahl and Beitz define product
architecture as "a scheme showing the relationship between the function structure of a product and
its physical configuration."
They go on to note that, "A product architecture can be used to
describe the modularity of a product, which can be classified according [to] the functional and
physical independence of its components" (Pahl et al. 2007).
Ulrich and Eppinger take a similar view, albeit in different words, defining product
architecture as "the assignment of the functional elements of a product to the physical building
blocks of the product." They elaborate further, noting, "The purpose of the product architecture is
to define the basic physical building blocks of the product in terms of what they do and what their
interfaces are with the rest of the device" (Ulrich and Eppinger 2012). It should be noted that the
study of product architecture was of particular interest to Ulrich, whose theoretical foundations on
the topic helped him assert the importance of analyzing architecture in the context of understanding
manufacturer success (Ulrich 1994).
When comparing these two definitions, it is interesting to observe how both try to codify
the relationship between function and form while defining "architecture." This is hardly unusual,
where Jiao, Simpson, and Siddique provide a nice review of the literature on product architecture,
overwhelmingly citing definitions whose primary focus is to relate function to form (Jiao,
55
Simpson, and Siddique 2007).
Building upon my wish to present a more global sense of
"architecture" to the PD research community, my definition of architecture decouples notions of
function from the fundamental definition of architecture. Instead, the relationship with function is
expressed via the relationship between the architectural and specification domains. The reasons
for this choice will become clear in the chapters to follow.
Specification
Similar to how we reviewed use of the word "architecture," we look to prominent design
methodology texts to gauge references to "specification" in the literature. Ulrich and Eppinger
state, "We intend the term product specifications to mean the precise description of what the
product has to do.. .A specification (singular) consists of a metric and a value" (Ulrich and
Eppinger 2012).
Unlike architecture, however, other leading authors have slightly different
perspectives of "specification." Pahl and Beitz refer to a design specification as the collective list
of requirements developed for a product design (Pahl et al. 2007).
That is, while Ulrich and
Eppinger's "specification" is meant to convert the list of customer requirements into actionable
parameters for engineers, it is qualitatively different from Pahl and Beitz's "specification," which
refers to the list of requirements in an abstract, qualitative sense.
Among the aforementioned definitions, this work adopts a definition for specification that
is closer to the Ulrich and Eppinger notion of the term. By treating a specification as a way to
objectively measure a design's performance, we can liken reasoning on the specification domain
to an optimization problem. This comparison will emerge in the following chapters. However, as
first addressed in Footnote 7, Ulrich and Eppinger's sense of a specification also includes
understanding of a target value for that specification, which my definition does not. To clarify,
my definition reflects a variable which simply measures a performance parameter and does not
address what value that parameter should take.
Domains
Domains play an important role in the design literature as they help compartmentalize the
various streams of information that designers regularly work with during the PD process. Given
the diverse array of pertinent factors to consider within the complex socioeconomic technical
56
systems in which we create and use the products we design, defining domains helps us to keep our
thinking clear and organized.
We begin by reviewing Pahl and Beitz's function structures, which are visualizations of
sorts of the functional domain.
A function structure helps translate requirements into an
articulation of function, which by Pahl and Beitz's definition is solution-neutral (Pahl et al. 2007).
The function structure will map inputs and outputs of a system, thus visually articulating
constraints that a proposed form must satisfy in order to move forward in the process. In other
words, in this visualization of the functional domain, constraints are plotted using the rules of
generating a function structure, which then the designer can refer to when ideating concepts for
form. The end result is that function informs form. This is consistent with the motivating idea
behind Pahl and Beitz's framework, which is to distill the process of considering customer
requirements and to conduct an ideation process that, as alluded to earlier, is solution independent.
Suh arguably has different reasons to motivate his framework, better known as Axiomatic
Design (Suh 1995).
Suh's framework consists of four domains: the customer domain, the
functional domain, the physical domain, and the process domain. These are represented in Figure
5. Suh takes us through this figure describing, "The domain on the left relative to the domain on
the right represents 'what we want to achieve,' whereas the domain on the right represents the
design solution of 'how we propose to satisfy the requirements specified in the left domain.' To
go from 'what' to 'how' requires mapping."
While a key tenet of Axiomatic Design is the
"zigzagging" between domains to decompose a problem, it should be noted that Suh clearly
presents a mapping of the functional domain onto the physical domain, which enables the designer
to go from "'what' to 'how"' in his framework.
Suh's framework is driven by his axioms for
design, which on the surface differs slightly in perspective from Pahl and Beitz's focus on
maintaining solution independence."
It To clarify, following Axiomatic Design as it is intended should yield a process that remains solution independent.
Nominally, however, Suh's framework is set up to confirm his observations of what makes good design, which are
articulated via his design axioms.
57
mapping
(CAs)
Mapping
{FRs)
mapping
[DMs
(PVs)
Customer
Functional
Physical
Process
domain
domain
domain
domain
Figure 5: Suh's Four Domains. Reproduced from (Suh 1995).
Despite the minor differences between the approach of Pahl and Beitz and Suh,
respectively, they both maintain a view of the process in which function informs form. This is
certainly a valid perspective, but my contention is that this assumption does not adequately
describe how designers actually behave during the front end of the process. Given our desire to
generate a framework which honors the heuristic of considering more options, it is important to
accurately describe the relationship between function and form in early-stage design in order to
guide deeper insights into strategies that generate better, more novel outcomes. My perspective
on this relationship is discussed in detail in Chapter 5. For more on the relationship between the
functional and physical domains as it is discussed in the literature, please refer to (Schmidt 2015).
Point, Instance, Set
The terms point and set bear a legacy from Ward's original thesis describing his framework
for Set-Based Design (A. C. Ward 1989). Given the context of his development of a mechanical
design compiler that would automate a system's design from a catalogue of components, it was
necessary for his use of the set, range, and related words to bear strict mathematical definitions in
order for his design compiler to function. My purposes differ from Ward's original intentions in
that I currently wish to describe, and not necessarily quantitatively model, a design process. Thus,
58
the terms point, instance, and set are defined in a qualitative manner, in contrast to Ward's initial
approach.
Before moving on, the reader should recognize that the term "instance" is not officially
coined in Ward's writings.
Instance is a term which I formalize in order to easily describe
individual points that are generated for comparison throughout the process while maintaining the
semantical contrast between the narrowing the initial "set" to the "point," or the final production
version of a product.
Constraints and Feasibility
The concept of constraints is fundamental to the PD literature and transcends the relevant
disciplinary bounds, bearing meaning in the greater engineering, economics, and related
literatures. For such a versatile concept, it is important to trace its fundamental roots, and so we
turn to a definition from mathematics.
From Wikipedia: "In mathematics, a constraint is a
condition of an optimization problem that the solution must satisfy. There are several types of
constraints-primarily equality constraints, inequality constraints, and integer constraints. The set
of candidate solutions that satisfy all constraints is called the feasible set" ("Surjective Function"
2015).
As referenced earlier, conceptualizing the PD process as an optimization problem is a
natural analogy and is the basis of significant literature across academic communities. From an
optimization perspective, constraints define conditions that the solution space must satisfy, which
is consistent with the definition for constraints presented in this work. It is interesting to observe
how Wikipedia's definition for constraints ties in the concept of a "feasible set." Just like in the
framework presented in this work, the idea of feasibility is hardly mutually exclusive from that of
constraints-rather they are interdependent.
Similar to Ward's optimization-inspired perspective, the role of constraints (and its
interplay with feasibility) in the framework presented in this work is to gradually narrow the vast
set of options down to the selection of a single point.
The thoughtful propagation of these
constraints is a central underlying theme to this work, and a proposed structure for approaching
this problem is presented in Chapter 8.
59
3.5 Conclusion
In this chapter, we introduce the lexicon for a new emergent framework for PD. We also
review prior use of these terms in the literature, which enables us to draw distinctions from the
framework presented in this work with other models conceptualizing the design process. For
instance, our framework defines architecture in a way that is not directly tied with function, unlike
many leading definitions for architecture in the literature. Furthermore, the domains as presented
in our framework do not unconditionally accept the relationship between the functional and
physical as it is often presented currently in design theory frameworks. In order to explore these
differences further, we must first put the framework to use in describing the PD process, which is
the focus of the next chapter.
60
4. Describing the Process Using the Framework
In this chapter, I will use the terminology of the framework to guide descriptions of typical
PD processes. This exercise will reveal deeper insights regarding the underlying mechanics of the
process, leading to dedicated discussion on these points in the following sections. First, however,
we shall begin with a generic description of the design process according to the framework.
4.1 Temporal Description of the Product Development
Process
Here, a series of assertions is made regarding the design process. These are made in bullet
form in order to simplify the ensuing discussion and aid comprehension of the individual points.
Clarification of certain points is made via sub-bullets.
-
The designer begins with a solution space of countably infinite potential architectures.
o
This assumes unlimited access to resources. I.e. the only active constraints at this
point are laws of nature, preventing the sampling of certain concepts which violate
these laws (e.g. an architecture that teleports). These types of architectures cannot
be sampled, even with access to infinite resources.
o
The analogy for "countably infinite" comes from the probability of choosing a
rational number between 0 and 1 along the number line (Nykamp). At this level
of resolution, potential end outcomes are innumerable, though the space is still
bounded by laws of nature, etc.
" The process begins with the articulation of an architecture of arbitrary resolution. This
architecture can be instantiated as groups of architectures at subsequent, finer levels of
resolution.
-
The design process yields a series of instantiations in the specification domain from coarse
resolution to fine resolution.
" While architectures are natively described in the architectural domain, one can express an
architecture of any resolution in the specification domain.
61
-
According to this process, a specific instance at a coarse level may be understood as an
architecture that embodies several instances at a finer level of resolution.
" In the specification domain, the set of possibilities eventually narrows to the selection of a
single point. This is the production version of the product.
To help articulate the bulleted assertions above, please refer to Figure 6.
represents an instance, each circle an
Coarse Resolution
Each star
Fine Resolution
architecture, and the collection of stars and
circles within the parallel dotted lines
represents the set. The parallel dotted lines
themselves represent dormant constraints
that are made active and are applied to the
set, transforming it from coarser to finer
levels of resolution. The first circle at the
left of the diagram represents articulation
of an architecture of arbitrary resolution
(e.g. the concept of a V6 engine).
This
architecture
four
is
instantiated
by
++
+
instances as shown in the diagram (e.g.
four competing V6 engine concepts). Note
n
c
+e
that, consistent with its definition, an
architecture can be expressed via one or
more instances. As the process continues,
Instance
A rchitecture
some architectures are eliminated from
consideration while others are developed
further via the propagation of dormant
Set
Figure 6: VisL alizing the Framework
constraints that are gradually made active.
62
4.2 Other Visual Representations of the Framework
In this section, I present alternative ways to visualize the framework in use, starting with
one of the more prominent diagrams presented in American (and many international) engineering
design education courses, Ulrich and Eppinger's generic PD process. An adapted form of this
diagram (Ulrich and Eppinger 2012) is shown in Figure 7, upon which the terms of the framework
are accordingly overlaid. Note that Ulrich and Eppinger's process begins with a "Planning" stage
(the first converging funnel shown) followed by "Concept Development," which features
subsequent divergence and convergence of ideas. While Ulrich and Eppinger do not explicitly
label the pictorial portion of the diagram in their text, it is understood that the divergence and
convergence depicted by the funneling out and in, respectively, represents the variance of ideas
explored.' 2 Using the terms of the framework, this variance of ideas represents the set that is
explored, as depicted in Figure 7. Similar to Figure 6, we can also label the embodiment of ideas
from coarse to fine resolution. Finally, the set narrows down by the end of the process (the
"Production Ramp-Up" phase in Ulrich and Eppinger's process) to the selection of a point, which
is the production version of the product.
While Figure 6 depicts the development of concepts and ideas in an abstract sense, perhaps
it would also help to visualize this development in the specification domain, as is done in Figure
8. This visualization is carried out through three common intermediate phases of the PD process,
employing terms used by Ulrich and Eppinger and Pahl and Beitz (some of the foremost authorities
on presenting the PD process) (Ulrich and Eppinger 2012; Pahl and Beitz 1988).
12
This is implied from the chapters and discussion in the text on the phases of the process in question (i.e. Concept
Development).
63
Point
Coarse Resolution
Fine Resolution
Figure 7: Ulrich and Eppinger PD Process Interpreted Using the Framework. Adapted
from (Ulrich and Eppinger 2012)
As alluded to earlier, since the specification domain is where we measure project success,
it is helpful to think about it as the domain which hosts design optimization. In Figure 8, imagine
we are designing a product that only has two specifications of interest, thus yielding a twodimensional specification domain.
Suppose the objective is to maximize the specifications
represented on the horizontal and vertical axes, respectively.
During concept development,
architectures are proposed for consideration whose specification values span the blue amorphous
space shown. However, given that the concepts proposed are qualitative in nature and lack
deterministic definition of specification values, we cannot know the exact bounds of feasibility of
the space of architectures explored at this point in the process. For this reason, the space shown is
bounded by a black dotted line. During the system level/embodiment design phase, we sample
three architectures which entail a subset of the original set explored during concept development.
Since architectures are now going through embodiment, it is easier for us to quantify the range of
specification values they entail, which is why the three architectures are enclosed by solid black
lines. Finally, in the detail design phase, we select a group of instances entailed in the small red
region within one of the three architectures explored in the embodiment phase. Within this red
region, a single point, or the production version of the product, will be chosen. Note that the
selection of a point from the red region during the detail design will not represent the theoretical
optimum within the original set explored during the concept development phase (the optimum
64
would be the upper-right most corner of this original set, representing the maximum x and y values
attainable). In practice, the designs we produce by the end of the PD process are often satisficed
solutions (Simon 1996). Our inability as designers to understand the true bounds of feasibility
during early stage design is a major factor behind such satisficed outcomes-an idea which will
be explored in further detail in the sections and chapters to come.
Concept Development
Coarse Resolution
Detail Design
System Level/
Embodiment Design
)
Fine Resolution
Figure 8: Visualizing the Framework in the Specification Domain
4.3 Observations from Using the Framework
Given that we have ended up with a group of instances that will lead to a satisficed solution
in Figure 8, a natural question to ask is: what can we do to generate a more optimal solution?
Fundamental to answering this question is an understanding of how we move from one phase to
the next during the PD process. In other words, if we understood the mechanics underlying our
transition from, for example, the concept development phase to the system level/embodiment
phase, perhaps we could better understand why we end up proceeding with architectures that end
up to be suboptimal solutions.
Based off of the definitions of the framework and their use in our discussion and analysis
of generic PD processes, we assert that the PD process progresses in the specification domain via
the propagation of constraints.
Regarding exactly how constraints propagate, we make the
following observation using the descriptive lexicon of the framework:
65
"Most constraints in the specification domain are dormant pending the
exploration of specific instances of architecture."
In other words, in order for constraint propagation to begin, designers must begin to
articulate form of arbitrary resolution. This serves to activate constraints which will begin to
narrow the set of possibilities. Increasing resolution on these architectures will initiate further
activation and propagation of constraints, eventually leading to the selection of a point-the
production version of the product design.
4.4 Conclusion
To summarize some of the critical observations over the past few sections, we have
established that 1) the specification domain is where we measure product success, 2) the PD
process is temporally driven by the propagation of constraints in the specification domain, and that
3) most' 3 constraints are not activated until the articulation of form. Given that form exists in the
architectural domain and the propagation of constraints determining product success occurs in the
specification domain, perhaps it would help to formalize the relationship between the architectural
and specification domain. This is our task in the next chapter.
13
The most notable exception, as mentioned earlier, are laws of nature, which are active from the very beginning of
the process.
66
5. Surjective Relationship
In this chapter, I seek to explore the relationship between the two domains in this
framework for PD.
We begin with the articulation of the Surjective Theorem for Product
Development, followed by discussion on and analogies regarding ways to think about the two
domains. Finally, I conclude this chapter with additional insights from the surjective relationship
that we can apply to other areas of inquiry in the design theory and methodology literature.
5.1 The Surjective Theorem for Product Development
The Surjective Theorem for Product Development, hereafter referred to more simply as the
"Surjective Theorem," is presented as follows:
Theorem: "The relationship between the architectural domain and the feasible
"
specification domain is represented by a surective function.14
Here, it may help for the reader to have background on the definition of a surjective
function. From Wikipedia: "a function f from a set X to a set Y is surjective (or onto), or a
surjection, if every element y in Y has a corresponding element x in X such that f(x) = V'
("Surjective Function" 2015). A nice pictorial representation of a surjection is provided in Figure
9, where the sets A and B correspond to the sets X and Y from the Wikipedia definition,
respectively. The black and red dots represent individual elements of sets A and B, respectively,
and frepresents the surjective function.
14
It is important to note here that we are using the strict mathematical definition for function, and not one from the
design theory and methodology literature.
67
S(=-A
domain(A) f-+
eB
range(A)
Figure 9: A Surjection. From (Weisstein 2015).
The Surjective Theorem tells us that for every feasible instance in the specification
domain, there exists at least one corresponding architecture. Given the definition of feasibility, an
instance in the specification domain is feasible if and only if an architecture exists to attain that
instance. Therefore, the Surjective Theorem is a tautology, and so we take it to be true. To state
it succinctly using the language of mathematics, we take the relationship of the architectural
domain "onto" the specification domain to be true.
Reasoning with the Surjective Theorem bears a number of interesting implications for PD
and design theory, which we will discuss in the sections to follow. Here, I shall present perhaps
the most important result from interpreting the theorem within the broader context of the
framework presented thus far:
" The specification domain is an artificial construct created by designers in order
to organize their reasoning about product function, measuring product
performance via individual specifications. Given its artificial nature, we can
only explore the specification domain by mapping architectures directly onto
it."
This understanding can be obtained from a careful reading of the theorem within the greater
context of the framework. One way to interpret this result is that since feasibility of (and thus
existence of) instances in the specification domain are predicate on the existence of instances in
the architectural domain, one cannot explore the specification domain without the articulation of
architecture.
68
5.2 Understanding the Domains
The purpose of this section is to help the reader understand how various aspects of the PD
process can be categorized according to the two domains, helping to illustrate their interplay within
the context of the surjective relationship. Please refer to Figure 10 for the ensuing discussion.
Below the column headings of "Architectural Domain" and "Specification Domain," respectively,
are analogies which we can use to interpret the role of the two domains. For instance, the
architectural domain can often be thought of as the "design space" in which designers can directly
modify variables that are pertinent to form, i.e. design parameters. The choice of these values in
the design space, in turn, influence the outputs in the "performance space," i.e. the values of
specifications in the specification domain. Accordingly, these labels correspond with notions of
the architectural domain being the "physical domain" where form is clearly articulated, whereas
the specification domain is the "functional domain" where product function is expressed and
measured. It is important to note here that we are using the design theory and methodology sense
of the term "function" (not the mathematical sense, which is employed in the Surjective Theorem).
ArchitecturalDomain
Surjective Function
SpecificationDomain
Design Space
Physical
Intrinsic Properties
Projection
Mapping
Onto
Performance Space
Functional (DTM term)
Extrinsic Properties
e.g.
Product dimensions
Material choice
Laws of physics
e.g.
Product weight
Product cost
Consumer demand
Figure 10: Understanding the Two Domains
Additional analogies for the architectural and specification domains include spaces for
intrinsic and extrinsic properties, respectively. A simple example illustrating this distinction is
69
how a product's dimensions are inherently intrinsic properties of its form, classifying them as
design parameters.
Furthermore,
dimensions themselves
do not usually
characterize
performance. 15 A product's weight, however, is not necessarily intrinsic to the form itself, as it
depends on the gravitational forces acting upon its mass (which is a function of its density and
critically, its dimensions). While typical use cases for most consumer products do not necessitate
the effects of variable gravitational forces, for designs such as space vehicles, these are extremely
pertinent factors to consider.
Moreover, across scales, product weight is often intimately
connected to its performance, from handheld consumer devices to commercial aircraft. Another
pair of examples include that of material choice and product cost. While most would agree that a
design's material is an inherent property of its form, its cost is assigned from external markets for
the material in question. In addition, cost is a critical specification for products, influencing among
other things the consumer's decision to purchase the product.
Of course, the examples above allude to the relationship between the architectural and
specification domains, respectively, which is noted in Figure 10 by the arrow for "Surjective
Function." Phrases such as "the architectural domain projected onto the specification domain" or
"the architectural domain mapped onto the specification domain" all capture this relationship. To
extend this language to the examples cited above, one could point out how a given product's
dimensions can help map to its weight or how material choice can project onto a product's cost.
In practice, specifications such as a design's weight or cost are outputs of a plethora of design
parameters beyond dimensions and material, respectively. Thus, the role of the surjective function
is to convert the inputs of design parameters in the architectural domain via a multiobjective
function (e.g. factoring in influences such as gravitational forces and markets for the examples of
product weight and cost) into the outputs of specifications in the specification domain. Using the
15
An example where individual dimensions may contribute to performance is a specification describing a product's
footprint, with for instance the specific objective to minimize it. This is a fine distinction, as dimension intrinsically
does not characterize product performance until a functional requirement such as the need to specifically minimize
the size of the product is introduced. In this case, individual dimensions can act as specifications, as well.
70
aforementioned analogue terms, the surjective function makes the physical functional and the
intrinsic extrinsic.
While passive interpretation of the discussion above may suggest that design parameters
are mutually exclusive from specifications, this need not be true. In some cases, the surjective
function will take an input design parameter and directly output it as a specification without the
influence of any other design parameters or outside factors. An example here may include product
dimensions, which is discussed in Footnote 15.
Finally, the last pair of examples listed in Figure 10 alludes to pertinent elements of the PD
process that do not strictly qualify as variables in the respective domains. Rather, these elements
still exert influence on the domains in the form of constraints. As alluded to earlier, the first group
of active constraints to act upon the architectural domain are laws of physics. While these natural
laws do not inherently characterize form (which is the role of design parameters), they help
influence the values a given form takes, qualifying them as constraints. Furthermore, other factors
can directly influence a design's specifications, classifying them as constraints in the specification
domain.
A typical example here is consumer demand.
Preferences regarding desired cost,
thresholds for minimum acceptable performance, and a host of other factors inform target values
for specifications, limiting the set, or the space of solutions, to consider.
5.3 Additional Insights from the Surjective Relationship
As we note earlier, the Surjective Theorem implies that for any feasible instance in the
specification domain, there must exist at least one architecture that maps to it. Of course, this
includes the possibility of many architectures that map to the same specification point. In other
words, it is possible that distinct combinations of design parameter values (i.e. different instances
of architecture) may yield the same instance or point in the specification domain. For some readers
(particularlythose familiar with the optimization literature), this assertion may seem intuitively
clear-they may skip the following paragraph if they wish. For others (including those who may
not be convinced), a simple synthetic example illustrating this principle using the terms of the
framework is discussed below.
71
Consider designing a two material alloy, where the only specification of interest is the cost
of the alloy produced, and the design parameters of interest are the respective amounts of materials
A and B to use. Suppose one is given a budget constraint of $16, and that the cost of material A
is $4/lb. and the cost of material B is $1/lb. Without any other information, one could generate a
trade-off relationship to represent the linear combinations of the weights of material A and material
B, respectively, that would satisfy the budget constraint. Suppose the chosen weights of alloys A
+
and B are represented by the variables a and b, respectively. The relationship then, would be 4a
b
16. Given that cost is the only specification of interest in this problem, if the designer wanted
+
to generate all architectures that would yield an alloy that cost $10, the expression would be: 4a
b = 10, which represents all linear combinations of the weights of A and B, respectively, that
attain that given specification value. Thus, from this problem, it is clear how distinct combinations
of design parameters (i.e. different instances of architecture) may yield the same instance in the
specification domain. 16
Returning to our original discussion, should one accept the possibility of one instance in
the specification domain having more than one instance of architecture mapping to it, we can take
this a step further. That is, should one be able to find a best or optimal instance in the specification
domain, it implies the existence of at least one best architecture (defined by virtue of mapping to
the best instance in the specification domain). This is a nice result, as it demonstrates how the
Surjective Theorem supports conceptualizing the process as an optimization problem. Thus, while
the methods underlying this work would not be ostensibly classified as design optimization, this
16 If, however, another constraint were to be added this problem-for instance defining the desired final weight of the
alloy-the system of equations would yield one instance of architecture (which notably would still comply with the
Surjective Theorem). For example, given the budget constraint 4a + b = 10 and a desired final weight of 4 lb
(yielding the expression a + b = 4), then there would only be one architecture that satisfies this problem: an alloy of
2 lb. of material A and 2 lb. of material B. Should yet another constraint be added, we would illustrate the principle
of linear programming in which the number of constraints cannot exceed the number of variables (or design
parameters). This problem would be over-constrained and would not yield a solution or a feasible architecture.
72
result establishes how problems in the design optimization literature are compatible with and can
be interpreted using the lexicon and structure of the framework presented in this work.
Given our ability to contextualize design optimization problems, we can also use the
Surjective Theorem to look the concept of Pareto efficiency in design in a new way. Suppose one
had the ability to express the surjective function analytically (see Chapter 6). One could then
contend that the Pareto frontier is in fact a subset of the codomain of the analytic surjective
function. This assertion may be of particular interest to the engineering design community which
has displayed an affinity for studying the Pareto frontier, and is addressed in further detail in the
Appendix.
Finally, another mathematical property of surjective functions is that the domain has a
higher cardinality than the codomain. This has interesting implications for understanding the way
designers generate ideas. Since these ideas are still under development, discussion on this point
can be found in the Appendix.
5.4 Conclusion
In summary, I introduce the Surjective Theorem, which relates the architectural domain
and the functional domain via a surjective function.
Furthermore, recognizing that the
specification domain is an artificial construct, I assert that it can be explored only by mapping
architectures directly onto it. We then explore analogies by which to interpret the two domains,
their relationship, and the role that this domain mapping plays in the PD process. Finally, we close
with using the results of our reasoning on surjection in the framework to contextualize other
streams of work in the design literature, such as the study of design optimization and the Pareto
frontier.
73
6. The Framework: Ideal vs. Practice
Based on the framework presented thus far, in this chapter we shall present a vision for an
idealized model for PD that takes advantage of the features and strengths of the framework. This
idealized model is presented as a device by which to point out how the framework (and thus the
PD process) differs in practice. These contrasts between the idealized model and the model in
practice shall set us up for one of the central results in this work, discussed in Chapter 7.
6.1 An Idealized Model for Product Development
To represent our idealized model for PD, imagine a computer program that accepts a design
problem as an input and produces a production-version design (i.e. a point solution) as an output.
One may think of this program as being an omnipotent, omniscient descendent of Ward's original
mechanical design compiler (A. C. Ward 1989), which has been discussed earlier (see Chapter 2).
In this idealized model, information would be complete (not asymmetric), static (not subject to
change), and perfect (free from error). With the help of this program, we would be able to
simultaneously interpret the plethora of variables that are parts of the greater socioeconomic
technical systems in which our products reside.
In this model, variables that are outside of the designer's direct control, such as material
prices or consumer demand, are either fixed or have values that can be projected with 100%
confidence to the time when the product is ready to use. A somewhat weaker sense of such
certainty (though still effective and quite idealized) would be if the program were able to
deterministically assess the quality of information it was handling. In other words, it could assign
deterministic confidence bounds with full certainty of confidence level for the information being
used in the model. 17 Armed with a self-awareness of the quality of the information it is processing,
17 This would make the model compatible with notions of fuzzy sets, which propose that the feasible bounds of the
set cannot be assigned deterministically. Thus, while ranges of values which define the bounds of the fuzzy set cannot
be known with full certainty, an idealized model would be able to self-assess confidence bounds on these boundary
values with full certainty.
74
the program would always make the right design decisions at any given moment during the PD
process with the information available to it.
With variable uncertainty accounted for, the program would also benefit from knowing the
analytic surjective function (i.e. the formal mathematical expression of the function between the
domains).
This would allow the program to perfectly map the architectural domain onto the
specification domain, enabling optimization on the feasible set in the specification domain. Once
the optimal point in the specification domain is found, with knowledge of the analytic surjection,
this point could be easily mapped back to find the best candidate architecture(s).
6.2 Product Development in Practice, Described by the
Framework
There are many reasons why PD in practice differs from the idealized model presented in
the previous section. Here, we shall focus on 3 of the major underlying reasons for such deviations,
which are:
1) The analytic surjective function is unknown.
2) Uncertainty of variables and their effects on constraint propagation remain unknown.
3) A lack of understanding of the bounds of feasibility in the specification domain in early
stage design.
I shall discuss each of these reasons in detail in the subsections to follow.
Surjective Function is Unknown
In practice, it is very difficult to know the analytical function which maps architecture to
specification.
As noted earlier, the reason why this is useful or desirable is that if we can
characterize an explicit mapping between the architectural and specification domains, we can
optimize in the specification domain and backsolve (that is, find the architecture(s) that correspond
to the desired instance or instances of specification). In fact, problems in the optimization literature
operate on this assumption, as the objective functions of interest in such work can be thought to
map subsets of the architectural domain to the specification domain (Yi, Shin, and Park 2008).
75
However, the question is: when along the process can we formalize this mapping, and is the
assumed analytic function representing the mapping accurate anduseful?
We can also address this question from the perspective of finding the Pareto frontier. Given
that we have explored the potential for the Pareto frontier to be a subset of the range of the analytic
surjective function, if we do not have knowledge of this formal surjection, when then can we
describe the Pareto frontier? In practice, we can obtain a representation for the frontier via trial
and error. However, this method is limited in that bounds of feasibility often must be established
first (discussed in further detail below). Furthermore, given that trial and error is involved, there
will be a certain level of fuzziness or uncertainty when describing the Pareto frontier. Many
optimization algorithms use a heuristic to define convergence criteria which defines when to stop
searching for the frontier. Thus, the proposed frontier may not truly match with the true optimal
idealized frontier that is a subset of the range of the analytic surjective function. This may be
deemed acceptable for many applications, but it is not the true optimal subset of solutions that is
promised by the Pareto frontier.
Another way of interpreting the issue that the analytical surjective function is unknown is
via the lens that designers cannot directly engage the specification domain without first projecting
architecture (an assertion made in Chapter 5).
Once even low-resolution architectures (e.g.
concepts which may not have been embodied yet) are articulated and then mapped onto the
specification domain, then trade spaces can be explored and optimality of specifications can be
pursued (Kerga 2013). For instance, consider designing an I-beam for a structure. Given our
knowledge of mechanics, materials, and other areas, we can analytically optimize many
performance specifications of the beam without having to develop an I-beam in real life. However,
before we can exploit analytical relationships from the applied sciences to address our problem,
we must first decide that it is an I-beam that we want to design-and thus we must formally
articulate this concept of architecture and map it to the specification domain before exploring
optimal specification values.
The question then becomes: what is done at the earliest stages of the PD process, before
any concepts of architecture have been articulated? How can we explore the specification domain
at this point? The simple answer is that we cannot. In the absence of knowledge as to how the
76
two domains map to each other, in early-stage design, the prescribed solution in practice is to
prototype rapidly and cheaply. As noted earlier during the review of the characteristics of setbased thinking (see Chapter 2), authors have noted how this practice of early, rapid, cheap
prototyping is done to promote learning of the system and the design problem at hand. To put it
in the terms of the framework, prototyping is done to understand the behavior of the surjection in
the absence of any formal knowledge of its expression.
Uncertainty of Variables
In addition to a lack of knowledge of the surjective function (and its behavior until form is
expressed and mapped to specification), in practice we also lack perfect information on the
pertinent variables in our system. Changes in variables such as customer requirements or market
demand, regulations, the intellectual property environment (e.g. new patents), supply chains, and
other factors present a significant challenge for designers. Often, these changes can compound
across systems, where a seemingly small change in one parameter at the subsystem level may
propagate to other subsystems, causing notable consequences at the system level. Such change
propagation can occur regardless of the scale of the system, though the effects can be particularly
profound in large, complex systems. Results of these changes include rework, excessive iteration,
cost and schedule overruns, and other deleterious effects (Helms et al. 2014).
Other reasons for uncertainty in variable values include the low resolution of ideas early
on in the process and issues associated with information quality. As discussed earlier, ideas
progress from coarse to fine resolution throughout the process, and until many details across the
product one is designing are worked out (such as defining subsystems and their interfaces (Ulrich
and Eppinger 2012)), one cannot progress to detail design to lock down the ranges of design
parameters and corresponding ranges of specifications to mitigate such uncertainty. Regarding
information quality, designers in practice often process, unbeknownst to them, imperfect
information that is laden with error. Designer mistakes committed due to such faulty information
can lead to grave consequences, such as the Mars Climate Orbiter incident (Oberg 1999).
As discussed in Chapter 2, a key tenet of SBD is to leave options open as long as possible
in order to mitigate or avoid the aforementioned consequences of rework that can result from
variable changes that occur during the PD process. In a sense, it is a paradoxical strategy as it
77
suggests that variable uncertainty can be dealt with by embracing that very uncertainty and to delay
convergent decision making which would lock down certain parameters that would be sensitive to
unexpected changes.
While certain practitioners of SBD have claimed to have successfully
mitigated the effects of variable uncertainty with the method, the fact remains that SBD's
prescribed approach goes against conventional wisdom in the PD community, potentially
influencing its lack of broader adoption as a methodology in industry. That is, in spite of any
evidence that leaving options open for longer may be beneficial, most designers are not very good
at internalizing all this uncertainty and would much rather lock down aspects of a design as soon
as possible. In fact, when the cost of iteration is cheap (such as in software design), this is the
preferred strategy in practice (see Section 2.3.1 for further discussion). For further discussion on
suggested approaches to manage uncertainty of variables, see Chapter 8.
Unknown Bounds of Feasibility
Of course, a lack of understanding of the mapping between the architectural and
specification domains and the uncertainty of variables (in both domains and from external factors)
implies that we cannot predict the bounds of feasibility in early-stage design. The reason why this
information is pertinent, as addressed earlier, is that the pursuit of optimality often occurs at the
bounds of feasibility. While these limits may be predicted analytically, in practice such analysis
is difficult to rely on due to the compounded uncertainties of domain mapping and variable
uncertainty. Thus, the solution in practice to understanding the bounds of feasibility is simply to
try things out. Historically, the development of entire industries that traditionally operate at the
bounds of feasibility, such as aviation and pharmaceuticals, has progressed via relentless
experimentation to understand what works and what does not (Thomke 2003).
A Common Theme: Articulating Form
As we have noted thus far, these issues are interdependent, and one can be described as
being a consequence of the other and vice-versa. Thus, it should not be surprising to consider that
the proposed solution in practice to each of these quandaries is simply to articulate form. Whether
it is prototyping to understand the behavior of the surjective domain mapping, locking down design
parameters to mitigate the uncertainty of variables during the process, or experimenting in order
to understand the limits of feasibility, each of these strategies essentially amount to the designer
78
expressing form before engaging in any earnest exploration of the functional or performance space.
While this may seem to be an innocuous observation at first blush, the significant implications of
needing to first articulate form are discussed in detail in Chapter 7.
6.3: Conclusion
In this chapter, we present an idealized model for PD using the framework, which is then
used as a way to contrast how PD in practice differs. Discrepancies between this ideal vision and
how PD is actually practiced can largely be attributed to: 1) the analytical surjective function being
unknown, 2) the uncertainty of variables in the PD process, and 3) the bounds of feasibility being
unknown. In practice, designers manage these challenges through a variety of activities which
result in first articulating form-the consequences of which are the topic of the next chapter.
79
7. The Designer's Dilemma
The following chapter ties together observations from the previous chapters to deliver one
of the important observations of reasoning with the framework: The Designer's Dilemma.
I
present the formal articulation of The Designer's Dilemma in Section 7.1, followed by context for
the "Dilemma" in the design literature in Section 7.2. In Section 7.3, I illustrate examples of the
effects of the Dilemma in the widely popular sport of football. In Section 7.4 I delve into some
insights we may obtain from reasoning with this result, followed by strategies to address the
Dilemma and concluding thoughts in Sections 7.5 and 7.6, respectively.
7.1 The Designer's Dilemma
Up until this point, we have used the framework to guide a variety of insights on the
process, such as how product success is measured in the specification domain, yet it cannot be
explored prior to a basic articulation of architecture. Furthermore, in the previous chapter, we
summarize the numerous ways in which we as designers are unable to internalize inherent
uncertainties of design in practice (see Section 6.2) and how the solution is to articulate form.
Tying together the various prior reflections on the role of expressing form in the PD process, I am
now ready to present one of the paradoxes of Set-Based Thinking and innovation in early-stage
design in general, the Designer's Dilemma, which is expressed as the following:
"One cannot reason on the solution space of potential designs without some
articulation of form. However, by virtue of articulating form, due to bounded
rationality, one is inherently prone to some fixation."
The first sentence should follow from prior chapters, just that we have generalized the
language to "reasoning on the solution space of potential designs," noting that potential designs
are for practical purposes measured and compared in the specification domain.
The second
sentence alludes to a concept that was briefly mentioned during the review of the literature in
Chapter 2-fixation. Depending on one's domain, the term "fixation" can support a variety of
meanings and interpretations. The notion of fixation expressed in the Designer's Dilemma is
closest to the definition, "a preoccupation with one subject, issue, etc.; obsession" ("Fixation"
80
2015).
Within the context of design, we can interpret fixation as "being preoccupied or
influenced by the nature ofprior-articulatedconcepts or ideas." In Section 7.2 we shall review
definitions for fixation as they are cited in the design literature, which differ slightly from the
notion we described in the prior sentence.
Another concept in the Designer's Dilemma that has not yet been formally introduced in
this work is bounded rationality. In The Sciences of the Artificial, Simon suggests bounded
rationality as a way to understand how humans can only make decisions within the realm of their
cognitive limits (Simon 1996). Given the context of bounded rationality, Simon argues that in
practice, optimal solutions to design problems are hard (if not impossible) to realize, and that most
solutions are in fact "satisficed." In describing this phenomenon, he states:
"An earmark of all these situations where we satisfice for inability to optimize is that, although the
set of available alternatives is "given" in a certain abstract sense.. .it is not "given" in the only sense
that is practically relevant. We cannot within practicable computational limits generate all the
admissible alternatives and compare their respective merits. Nor can we recognize the best
alternative, even if we are fortunate enough to generate it early, until we have seen all of them. We
satisfice by looking for alternatives in such a way that we can generally find an acceptable one after
only moderate search."
This short passage insightfully reflects on a number of items that are relevant to our
framework. Translating this passage accordingly, Simon points out that while the set is given
abstractly (i.e. we know what types of constraints are relevant and bounding the space), we do not
know the practical limits of that set (see Section 6.2 for further detail). Furthermore, it is implied
that to have any "practically relevant" knowledge, alternatives must be generated and comparedwhich is another way to express the articulation of form. Finally, Simon argues that we cannot
"recognize the best alternative.. .until we have seen all of them." Thus, given the "practicable
computational limits" of our minds, we must simply try out options, finding "an acceptable one
after only moderate search."
Given that we established that we need to generate options for comparison (i.e. articulate
form) within the limits of our bounded rationality, my intent is to take this one step further,
suggesting that in practice our cognitive limits are also responsible for generating fixation (see my
81
definition above) among those options or ideas generated for comparison. The implications of this
assertion are broad-some of which shall be addressed in Section 7.4-but for now, it is important
to appreciate the conundrum this presents for innovating in early-stage design, especially within
the context of trying to consider more options.
7.2 Contextualizing the Designer's Dilemma in the
Literature
One of the earliest studies of fixation in the engineering design literature is from Jansson
and Smith, who define fixation as "blind adherence to a set of ideas or concepts limiting the output
of conceptual design" (Jansson and Smith 1991). Their studies are largely descriptive, studying
the performance of engineering design students and professional design engineers in generating as
many designs as possible in response to a given design problem. Priming the experimental or
fixation group with an example design solution to the problem, they consistently found poorer
output of ideas (in terms of quantity generated and uniqueness of ideas) from the fixation groups
relative to the control groups that were not primed with the example solution to consider.
In the years following Jansson and Smith's pioneering study, many authors in the design
community have studied fixation, notably including Linsey et al.'s multi-institution collaboration
on the topic (Linsey et al. 2010). In their study, Linsey and colleagues confirm the results of
Jansson and Smith's studies among a group of academics who teach design (and ostensibly are
aware of the phenomenon of fixation), in addition to suggesting defixation strategies (which shall
be addressed in Section 7.4) and measuring the study participants' perceptions of the degree to
which they fixated.
Notably, in the aforementioned studies and others (a nice review is provided in (Linsey et
al. 2010)), fixation was studied in a controlled experiment, where the experimental group is baited
or primed with a solution or concept to the problem they are asked to solve, whereas the control
group is simply given the problem without any bait for explicit fixation. The quantity and variance
of ideas between the two groups are compared, thereby allowing researchers to assert the effects
of fixation in the experimental group. Nevertheless, thus far in the literature, fixation is presented
and studied in a relative sense. That is, by virtue of comparing the poorer performing experimental
82
group to the control group, one can assert the presence of fixation. My contention, however, is
that the control group also suffers from fixation (albeit to a relatively lesser degree).
Given that we have established the need to articulate architecture in order to explore the
performance space and drive the process forward, and that bounded rationality limits our ability to
generate and compare a large number of options, we fixate on the architectures that we explicitly
generate for comparison. By virtue of articulating an architecture, we simultaneously 1) ground
the abstract problem at hand by giving our minds a practical solution to consider and 2) increase
the chance that our thinking on generating the next concept(s) will be influenced by the nature of
the architecture that was just articulated.
Thus, in lieu of Jansson and Smith's definition for
fixation as "a blind adherence to a set of ideas or concepts," my argument is that fixation occurs
without necessarily having a "blind adherence" involved.
Despite Linsey et al.'s interest in
studying the perceptions of fixation post-experiment, I assert that one can be fully aware of their
fixation, and it does not ultimately matter. Fixation is a direct consequence of the way we reason
about design within the limits of bounded rationality-and thus far in our cognitive development
as a species, it is inevitable. This is one way to appreciate the full extent of the conundrum that is
the Designer's Dilemma.
7.3 An Example from Football
The Designer's Dilemma can be interpreted in a variety of domains outside of traditional
PD. Perhaps one of the most compelling comprehensive examples by which to interpret the
Dilemma coupled with the desire to consider more options comes from American football. I
choose this example due to the depths of the analogies which can be drawn to the PD process,
especially in context to how it is presented in this work using the framework.
In football, between downs, the objective of the offense is to choose a play that will
maximize yards gained in hopes of scoring points. Once in play, the opposing team's defense
seeks to stop the advance of the offense in hopes of securing possession of the ball for their team.
Prior to the snap, the offense chooses a specific play from its playbook to run after the snap. In
other words, the selected play is a point from the feasible set-which is the team's playbook. Once
the offense begins its play, the defense must have the appropriate formation of react to that play.
83
Constraining the initial set of possibilities for the offense (i.e. its playbook) includes the individual
capabilities of members of the offense, which can be thought of as constraints on the form of plays
articulated, thus acting as constraints in the architectural domain.
Other factors include the
strengths and capabilities of the defense and weather conditions during time of play (e.g. strong
winds, slippery turf from rain, etc.). These factors influence the performance and success of the
offense's chosen play, and thus they can be thought of as constraints in the specification domain.
In hopes of maximizing success of the play, some teams take a Set-Based Thinking
approach to play calling-the no-huddle offense. In a no-huddle scheme, the quarterback or playcaller (if not the quarterback, the offensive coordinator or head coach) often reads the defense
based on its formation prior to and during the play and choose an appropriate play for maximum
effect (Kelly 2013). That is, instead of committing to a point or play prior to the snap, the playcaller will consider more options by allowing the defense to constrain the set of options or plays
available based on its formation in hopes of exploiting the defense's weaknesses during the play.
Thus, the defense will initiate the process of articulating the final architecture of the offense's play
by limiting the initial set of feasible plays from which play-caller may choose.
In practice, the no-huddle offense is very difficult to execute and requires many
Characteristics of Set-Based Thinking to enable. For instance, a no-huddle offense relies on a
tolerance for under defined specifications, as the quarterback often will not commit to a specific
point or end outcome to the play until well after the snap. That is, the quarterback will inform his
team of the low-resolution play which he intends to run, which can have a variety of end outcomes
depending on how events transpire. Reading the field while.the play is in progress, the quarterback
will exploit specific matchups he sees between, for instance, a receiver and a defender, and then
commit to a specific point or end outcome to that play. Other Characteristics required include
more efficient communication among subsystems, subsystem exploration of optimality, and a
support for flow-up knowledge creation.
In the absence of the huddle, players (i.e. subsystems
such as the receiving corps and offensive line) must efficiently communicate with one another at
the line of scrimmage with code words and signals. Subsystem exploration of optimality and
support for flow-up knowledge creation go hand-in-hand in this context, as the quarterback
84
(another subsystem in the context of the greater offense) has considerable autonomy in choosing
the final play and changing the original call at times before and after the ball is snapped.
Thus, we have established how the no-huddle offense, if executed properly, can take
advantage of a situation by allowing the defense to initially constrain the solution space of plays
in an effort to exploit the defense's weaknesses. However, part of the challenge here is that an
offense that only reacts to the signals of a defense can be exploited. In other words, an offense
that only chooses plays by reacting to the signals of the defense becomes fixated on a certain subset
of plays designed to react to those signals. A good defense will exploit this fixation by periodically
differentiating signals of the play to occur from the actual plays that are run.
For instance, if the defense realizes that the offense will run only in reaction to a passprotection formation, it may give the signals of conducting the same pass-protection play when in
fact it has plans to defend against the run. To overcome this, an offense must not become fixated
on run-only plays in reaction to such signals, and must be willing to explore larger portions of the
solution space beyond handing it off to the running back to rush (i.e. the typical "run" play).
7.4 Observations from Reasoning with the Designer's
Dilemma
We can use the Designer's Dilemma to make a number of interesting assertions about the
PD process, which shall be detailed in the respective subsections to follow.
Interpreting Concept Development as Indiscriminate Search
Since we cannot directly reason on the specification domain without expressing
architecture, and given the cognitive limits imposed by bounded rationality, concept development
,
(and any prior phase such as opportunity identification) essentially amounts to indiscriminate' 8
18 1
avoid using the word "random" due to its connotations from a probability perspective. A truly random search
method would generate instances whose aggregated specification values could be understood as being sampled from
a normal distribution, for instance. Fixation implies that prior articulated instances will influence the articulation of
future instances, which in probabilistic terms would decidedly represent a non-random process.
85
inefficient search. Without knowledge of the analytical surjection linking the two domains early
on in the process, much of the reason to articulate form is to test the viability of a concept in the
specification domain. This is why prototyping is often thought to promote learning early in the
process. The result is indiscriminate search of the specification domain where we are attempting
to find architectures or concepts that are qualitatively better than the ones we have come up with
so far. The search is clearly inefficient since we do not have any analytical tools at this point to
directly assess optimality in the specification domain. As we note earlier, once there is sufficient
resolution on the concepts expressed to create an approximation of the surjective function, we can
apply analytical tools from our knowledge of optimization techniques to find appropriate solutions.
However, once we reach this point in the process, the set we are exploring has already been
subjected to the biases of fixation from earlier. Of course, this point segues nicely to our next
observation.
Why Novel Outcomes in SBD (or any other method) are a Chance
Pursuit
Earlier in this work, we identified a latent issue to come out of the SBD literature, which
was the notion that in practice, SBD as a process does not necessarily guarantee novel outcomes.
Now, after our careful reasoning with the framework presented in this work, this result should not
be surprising. As a project management method, SBD's strength lies in requiring designers to
explicitly justify why certain solutions are better than others. This is most effective in the form of
trade studies, where the specifications of options have been quantified, generating "trade spaces"
which are often methodically plotted and analyzed to identify the best alternatives (Oosterwal
2010; Kerga 2013). However, trade studies do not offer any answer for the fuzzy, unquantifiable
front end of the process. A minimum level of resolution of architecture is required to conduct
these trade studies, which implies the inadvertent elimination of a number of options in order to
get to that point. Thus, it is a somewhat disingenuous notion for practitioners of SBD to quantify
the number of options available in the initial set and indicate their reasoned elimination of this
initial set to the eventual selection of a single point solution ("Ship-to-Shore Connector
Implementation of Set-Based Design" 2009). Not only is this practically infeasible due to bounded
rationality, but it does not describe what actually happens-that is, the theoretical number of
86
options in the initial set are never brought into the trade studies phase of the process when options
can be quantified and directly compared. As we note earlier, once we are ready to approximate
surjection (that is, we can quantify specification values on options), it is too late, since we are
conducting trade studies on a subset of the original theoretically countably infinite set that has been
subjected to our inadvertent fixations from earlier.
To provide a simple example inspired from a class project completed during the course of
this thesis, consider a company is designing a diesel generator in a particularly price-sensitive
market. Suppose this company's generator is cheaper than most competitors, but it has received
complaints from customers for being too noisy. The company, driven by its desire to retain its
high market share as one of the cheapest options on the market, decides to conduct a variety of
studies to determine how to minimize the noise of the generator. They experiment with different
shaped enclosures (to minimize transmission of sound from the components inside), different
sound absorbent materials to line the enclosures with, and different mounts upon which the engine
sits (to minimize vibration and its influence on noise emitted). Any solutions that the company's
engineers propose to management must be within the cost of the current generator. While the
engineers occupy themselves with a variety of trade studies, engineers and management lose sight
of the fact that instead of redesigning the components that they manufacture for the generator,
perhaps they could focus on acquiring better parts that they do not design, such as the engine. As
it turns out, the engine is responsible for producing the most noise in the assembly. It is also
relatively underpowered compared to competitors.
Thus, while being fixated on maintaining
current price point, management had missed the opportunity to explore the option in investing in
a better engine that was quieter and more powerful and passing on the cost to consumers.
Management has implicitly assumed that consumer demand is highly elastic (i.e. sensitive to price
hikes); however, with performance improvements such as noise reduction and increased
performance from the engine (e.g. power output), perhaps the consumer would be willing to
embrace the higher cost. Despite potentially losing the most price-sensitive consumers this way,
if enough consumers are retained in spite of the price hike, then the strategy will be profitable for
the company.
87
Taking a step back, however, perhaps the key to increasing profits for the company has
nothing to do with focusing on noise, power output, or attaining a low price for current generator
offerings. Perhaps the company is actually fighting poor brand perception among consumers in
the target market. Nevertheless, without first articulating this as an option, management cannot
dedicate resources to determine whether this is a viable option worth investing in (e.g. focusing on
rebranding the company in this segment). As SBD would prescribe, no potential trade studies can
be conducted without first deciding what strategies should be quantified and compared.
What this means is that if designers are simultaneously astute and serendipitous with the
articulation of the concepts they want to consider during concept development, then there is a
chance to obtain a novel outcome at the end of the process. More often than not, though, designers
will not strike this innovative gold. This is why despite following a methodical process such as
SBD (or any other known PD technique, for that matter), novel outcomes can never be guaranteed.
Furthermore, it is another way to understand why innovative products in practice are difficult to
come by and why most PD projects end in failure.
Why Artificial Intelligence Does Not (Yet) Pose a Threat to Human
Designers
A lack of understanding of the surjection between the architectural and functional domains
in early stage design poses a challenge for the development of artificial intelligence. While a
computer has the ability to trial-and-error and generate many more alternatives for comparison
than a human, it does not have the ability to analytically out-reason humans. In the terms of the
framework, like a human, a computer will not have the ability to surmise the surjection without
the articulation of form. Unlike a human, however, a computer cannot articulate form without a
problem that has been appropriately scoped for it.
To successfully decompose an ill-defined problem and its uncertainties and to propose
solutions to such a problem in the early stages of the PD process is a unique effect of human
ingenuity whose underlying cognitive mechanisms we do not yet fully understand. Our inability
to create an algorithm to emulate human reasoning in early-stage design has thus far limited the
potential for artificial intelligence. Ward's original PhD thesis describing SBD was motivated
88
from an artificial intelligence perspective-to create a "design compiler" that would automate
decision-making on assembling a system from a catalog of individual components (A. C. Ward
1989).
Ward's pursuit was quite relevant at the time, where the development of artificial
intelligence was seen as a key area for growth in the design theory and methodology community
(Finger and Dixon 1989). In the intervening years since Ward's foundational work, it is interesting
to note the community's decreased focus on developing artificial intelligence for the purpose of
removing the human designer from many contexts.
Algorithms developed today are largely
intended to complement human decision-making as opposed to replacing it altogether. Without
analytical tools to augment the level of artificial reasoning, despite being much quicker, computers
will only remain as intelligent as the humans that create them.19
7.5 Strategies to Counteract the Designer's Dilemma
Given the established inevitability of the Designer's Dilemma, what can be done to
mitigate its effects? In this section, we sample existing and proposed techniques to reduce the
effects of the Dilemma, which can be broadly grouped into two categories-those that amount to
"blind search" and those that embody "informed search."
Blind Search
As we have established the indiscriminate and inefficient nature of the concept
development phase, it should not be surprising that the vast majority of proposed ideation methods
(including many documented defixation strategies) amount to blind, uninformed search. That is,
the emphasis of these methods is to generate sheer volume of ideas, without particular attention to
whether diverse regions of the solution space are explored. Many divergent concept generation
techniques, such as the morphological matrix and the 6-3-5 technique essentially amount to
indiscriminate search where quantity of ideas generated is the heuristic for successful ideation
(rather than their ability to sample larger parts of the unexplored solution space). Some methods
19
For further discussion, there exists significant work on the potential for artificial intelligence to equal ("Artificial
General Intelligence" 2015) or surpass ("Superintelligence" 2015) human intelligence, including criticisms of these
viewpoints ("Chinese Room" 2015).
89
such as the 6-3-5 technique may in fact promote fixation by encouraging certain members of a
team to modify another's idea, without any sense of whether that idea is superior to more diverse
concepts that have yet to be proposed or explored (Pahl et al. 2007).
A number of methods have also been proposed with the explicit goal to promote defixation.
Linsey et al. review several of these techniques, which can be characterized as promoting "design
by analogy" (Linsey et al. 2010). These include, for instance, considering analogies from the
natural world and biomimetics, and database-driven tools which suggest analogies for a design
based on designs from other domains that utilize similar functions or address similar customer
needs. As Linsey and colleagues note, these methods may help designers frame their problem in
a new way, potentially enabling more novel proposed concepts and solutions.
While refraining a design problem has been shown to potentially lead to better proposed
solutions, it does not fundamentally alter (and thus it does not improve) the mechanism by which
form is articulated.
The non-random process by which form is articulated is only marginally
improved when presented with framing techniques that may encourage designers to sample new,
unexplored subsets of the initial set of possibilities in the specification domain. Despite this, these
reframing defixation techniques cannot guarantee that 1) further fixation will not occur on the new
subspace/region, and 2) that new subspace is far enough from the subspace of the prior articulated
idea to be worth sampling (otherwise the specification values or performance of concepts from
both subsets will be very similar, defeating the purpose of the defixation exercise).
Informed Search
Given the aforementioned drawbacks of blind search, the question becomes: can we more
deterministically ensure more diverse sampling of the specification domain to truly embody the
ethos of considering more options? This is the goal of what I term to be "informed search."
With the understanding that optimality often occurs at the bounds of feasibility, one method
may be to intentionally articulate form in order to sample the limits of feasibility. A theoretical
basis for such methods has been provided by Malak and colleagues in the context of finding the
parameterized Pareto frontier (Malak and Paredis 2010). Motivated from a set-based perspective
where subsystems may explore optimality, this work seeks to articulate knowledge of Pareto
90
frontiers in the absence of a well-defined higher system level objective function. From the search
algorithms explored in this line of work, we could potentially create ideation techniques which act
in a similar way by intelligently searching for the bounds of feasibility as opposed to blindly
articulating new instances with the hope that enough have been articulated and compared to be
confident in having found a subset of superior solutions to carry forward through the process.
An additional property of a surjection is that the domain has the same or higher cardinality
than the codomain (see Appendix for further discussion). Thus, another strategy for informed
search may be to understand the sensitivity of variable mapping between the architectural and
specification domains. That is, for a given design, changes in which design parameters lead to the
most significant changes in specification values? In this sense, we can directly manipulate how
we articulate form in order to attain broader sapling of the specification domain, as opposed to
refraining techniques, where we are generally unaware as to whether the technique actually aided
us in sampling new subsets of the specification domain until we try it out and measure it (such as
via prototyping). Understanding inter-domain variable sensitivities remains' an area for potential
future work.
Of course, the critical reader may notice a critical caveat to these strategies for informed
search. In order to create search algorithms inspired by the search for a parametrized Pareto
frontier or exploiting inter-domain variable sensitives, one must have some initial working
knowledge of the behavior of the surjection between the architectural and specification domains.
Thus, at the earliest stages of the process, one is still compelled to begin the exploration of the
specification domain via the blind articulation of form, just as the Designer's Dilemma tells us.
While the "blind" and "informed" techniques addressed in this section certainly have the potential
to promote some defixation, they cannot guarantee such success in early-stage design.
7.6 Conclusion
In this chapter, we tie together the cumulative observations of previous chapters from
reasoning with the framework to articulate one of the paradoxes of early stage design: the
Designer's Dilemma. Contextualized from our understanding of the bounded rationality of human
cognitive processes, it recognizes the inevitability of fixation as a result of being forced to
91
articulate form in order to begin exploration of the specification domain. A few results from
reasoning from the Dilemma include interpreting concept development as indiscriminate, blind,
inefficient search, and recognizing why Set-Based Thinking cannot guarantee novel outcomes.
Finally, we explore a few strategies meant to counteract the effects of fixation while observing the
limitations of these techniques.
92
8. Understanding Constraint Propagation
In this chapter, I propose a different way to conceptualize and manage uncertainty in the
PD process and minimize rework. In Section 8.1, I establish the argument for understanding an
order for constraint propagation, and in Section 8.2, I present a framework for doing this that
applies reasoning from the study of econometrics. It should be noted that this chapter is largely
experimental and it is intended to propose groundwork for future study on this topic rather than
providing answers on the topic of constraint propagation.
8.1 Identifying an Order for Constraint Propagation
As we note earlier in this work, the propagation of constraints drives the process forward.
Recall from Section 4.3, "Most constraints in the specification domain are dormant pending the
exploration of specific instances of architecture."
Via the "exploration of specific instances," dormant constraints are slowly made active.
While we have defined "dormant" and "active" constraints earlier in this work (see Section 3.2),
it is important to note that these are not binary conditions.
Similar to how an architecture is
developed from coarse to fine resolution, constraints undergo a similar process whereby they
transition on a spectrum from "dormant" to "active."
For example, constraints due to
manufacturing process employed on a part may gradually activate by first identifying suppliers to
use and their capabilities (which limits the set of potential processes that could be used), followed
by choosing a particular manufacturing process for the part and setting the parameters for that
process. Thus, the initially dormant constraints affiliated with manufacturing process employed
will continue to emerge until they are fully active during the actual production of that particular
part, helping increase resolution on the part's design from low (e.g. before suppliers are identified)
to high (e.g. after the part has been manufactured).
Interpreting constraint propagation as the mechanism which moves the process forward,
perhaps there is a preferred order in which constraints should be gradually activated.
Understanding this order may help avoid rework, change propagation, and other deleterious effects
associated with the uncertainty of various parameters in PD in practice as discussed in Section 6.2.
93
A rudimentary example for a framework to order constraint propagation is provided by Day in his
Real-Win-Worth It (RWW) framework (Day 2007).
Surmising a preferred order for constraint propagation implies that there are certain
parameters or variables that if modified would cause larger systemic effects than others.
For
instance, from an RWW point of view, constraints pertaining to "is the market real?" such as the
size of the potential market and consumer demand at a certain price range take precedence over
downstream manufacturing constraints such as whether existing supply chains can produce the
proposed product. In other words, while both types of constraints (i.e. market and manufacturing)
clearly influence the feasibility of whether a product can be produced, most would agree that for a
profit-maximizing firm, it does not make sense to produce a product that is technically feasible to
manufacture but for which there is not sufficient consumer demand. Thus, for most20 profitmaximizing producers, market constraints should be applied to the set before manufacturing
constraints to avoid the outcome of producing a product for which there is no significant market
and which will cause the firm to lose money.
8.2 An Econometrics Inspired Framework for Ordering
Constraint Propagation
Given the innumerable interdependencies within the socioeconomic technical systems in
which the products we create reside, it may help to analyze this problem from a social science
perspective. Thus, I propose the creation of a model for the product development process that is
similar to an econometric model, with explanatory and response variables. Isolating explanatory
variables in such a framework would help isolate which variables may contribute to larger
propagated change throughout a given design.
20
This assumes the proposed product is not part of a larger strategy for the firm to for instance gain market share or
build upon its reputation, in which case losing money on a per-unit basis for a particular product may be a profitable
strategy in the long run for the firm.
94
In this framework, response variables would be those whose values depend on those of
explanatory variables. Explanatory variables are those that "explain" the values of the response
variables. For instance, an explanatory variable may be material choice for a part, whereas a
corresponding response variable may be the cost of that part. However, these causal relationships
cannot be established until the cumulative effect of all pertinent variables are accounted for. As
prescribed by standard econometric theory, one may ascertain causality among variables by
studying a variety of regressions among pertinent variables in the model. Given the plethora of
variables involved (both in a traditional economic model and in a hypothetical model for PD), the
simultaneous influences of many variables presents a non-trivial challenge for determining which
relationships can be interpreted as causal as opposed to those which are simply correlated.
At this point, the reader may be asking: how can such an analysis be carried out? One
approach is to collect historical data on a portfolio of past PD projects that are all similar in nature
(e.g. similar products/applications). For each project in the portfolio, quantitative data on pertinent
variables are collected (e.g. material cost, product sale price, etc.) and then inserted into a model
upon which multiple regressions may be conducted. From these regressions, explanatory variables
among the historical data on the projects could be identified and compared across different cases
within the portfolio of past projects. The comparison would yield insight into which variables are
most often explanatory across these projects. The hypothesis is that these variables, if subjected
to change in PD projects that are similar to those that were studied for the regressions, would cause
the greatest perturbations or largest effects across a system by virtue of their explanatory nature.
By observing which variables are most often explanatory, we can begin to map this knowledge
back to a temporal understanding of which constraints should be activated before others in order
to avoid change propagation, rework, and other issues that may be mitigated should constraints
have been propagated in the proper order.
There are still a number of issues to keep in mind prior to applying an econometric
modeling-inspired approach to studying PD projects. For instance, certain variables can be shown
to be explanatory, knowledge of which may not be of ultimate use to the designer. Considering
the example of an engineering drawing (discussed in Section 3.2 in the context of the architectural
domain), dimensions and material choice can explain mass (given that dimensions imply volume
95
and material choice implies density). However, these causal relationships may not be relevant to
the designer's efforts to mitigate the risk of volatile variables and variable change propagation
across the system. Furthermore, explanatory variables cannot be assumed to be independent
variables in the engineering sense in which designers can directly control their values. An example
of such a variable may include oil prices-which exist in the specification domain and are outside
the direct control of the designer.
Perhaps the biggest challenge in advancing this econometrics-inspired framework is
selecting which cases of past PD projects to compare in a portfolio, given that variables that are
explanatory for certain products may not be so for others. For instance, in the RWW example
explained in Section 8.1, we argue that for the typical profit-maximizing firm, market-oriented
constraints take precedence over manufacturing-oriented constraints. However, in footnote 20, we
explain how some profit-maximizing firms may not be concerned with the product produced
necessarily turning a profit if it is within the context of a larger corporate strategy. Consider the
Bugatti Veyron, the Volkswagen (VW) Group's claim to producing the world's fastest production
car. Despite leading to billions in financial losses while producing the vehicle for over a decade,
the Veyron earned the VW Group prestige within the auto industry as a technological achievement
("Zoom, Sputter, Aagghhh!!" 2013). Thus, it is clear that many of the variables pertaining to
market demand were not explanatory, and accordingly constraints pertaining to manufacturing
attained much higher emphasis than those pertaining to market.
It is important to note that the case-dependence of whether certain variables are explanatory
limits the generalizability of knowledge somewhat from this exercise. In the short run, the critical
caveat to this approach is that variables found to be explanatory among a portfolio of similar
products is expected to be explanatory for other similar products and applications, only. However,
as I point out in the conclusion, this caveat may become less relevant as more cases are studied.
8.3 Conclusion
Noting that constraints undergo a gradual process of activation on the specification domain,
the previous sections identify the potential usefulness of defining a preferred order for constraint
propagation in the PD process. We propose an econometrics-inspired framework for addressing
96
this question in which explanatory and response variables from past PD projects can potentially
be isolated to infer causal relationships. With this knowledge, designers may begin to identify an
order in which certain constraints should be activated over others for projects that are similar to
the ones studied. Despite the initial caveat of case-dependence, as more portfolios of previous
projects are studied, it is conceivable that trends may be identified, and thus categories that are
broader than a particular class of products can be identified for which heuristics regarding ordered
constraint propagation can be made. In other words, as more cases are studied, the likelihood that
knowledge may be generalized and that preferred orders for constraint propagation may be
identified for broad applications beyond simply similar products increases.
97
9. Bringing it Together: How the Framework
Influences the Way We Think about Design
Given the cumulative nature in which the framework is presented and discussed in this
work, the purpose of this chapter, acting in lieu of a traditional concluding chapter for a thesis, is
to collect and summarize some of the big picture ideas to emerge from reasoning with framework
starting from Chapter 3. Thus, this chapter is intended to review potential contributions of this
work in light of our pursuit of a deeper understanding of the PD process. In Section 9.1, I discuss
what the framework as presented in this thesis hopes to achieve. Following this, in Section 9.2, I
summarize some of the new ways of thinking about the PD process to emerge from developing
this framework. In Section 9.3, I identify some areas for future work that can expand upon and
give greater meaning to the framework as presented in this thesis. Finally, I offer some concluding
thoughts in Section 9.4.
9.1 What Does This Work Hope to Achieve?
In Section 3.1, I summarized the difficulties in advancing our work on Set-Based Thinking
due to a lack of standardized terminology and a subsequent breakdown in communication and
understanding when discussing certain elements of the PD process.
Contextualizing this
observation in a broader call for common terminology and a common model for the design process
from Blessing, we defined the terms for a novel framework for product development. First-order,
this framework provides a new qualitative description of the PD process. However, in doing so,
it also:
1. Re-conceptualizes how we describe the front end of the PD process
2. Challenges implied or assumed causal structures or relationships in the PD process
21
21
This statement should not be misconstrued as a claim to have an understanding of how things actually work in the
PD process; rather, I present a different take on certain elements of the process that questions things that are often
assumed to be true in the literature or in general discussion about the design process.
98
3. Presents groundwork for investigating latent research challenges in our community
Exactly how we achieve these three points shall be made clear in the following section.
Each of the points above, 1-3, shall be mapped specifically to the new ways of thinking that are
described in Section 9.2 in Table 3.
9.2 What New Ways of Thinking Are Proposed?
Articulating a novel framework for PD that is the focus of this work since Chapter 3 has
yielded a variety of fascinating insights about the fundamentals of the process and the way we
design. I collect major insights as they are established, roughly chronologically, throughout the
thesis and summarize them in each of the subsections below. At the end of this section, I map
these insights and subsections to the three points in Section 9.1 thus classifying the underlying
goals of this work.
Set-Based Thinking as a Way to Enable the Consideration of More
Options
In Chapter 2, across a broad sampling of PD-affiliated literature, I identify characteristics
of processes that have been discussed and studied as good PD practices since the aforementioned
Ward et al. 1995 case studies on Toyota. I then use these characteristics to identify the Principles
of Set-Based Thinking, a new way of categorizing a set of similarly-motivated techniques and
methodologies which transcend our original starting point of studying the SBD literature.
Careful consideration of these Principles allows us to assert that the perceived strength of
a Set-Based Thinking approach is that it enables the consideration of more options. Recognizing
that the consideration of more options is a well-respected heuristic in the design literature, we take
a step back to raise questions about its practical effectiveness as a strategy in light of the lack of
novel outcomes attained by some practitioners of SBD. Trying to understand what it actually
means to consider more options while proposing standardized terminology that was inspired by
elements of the Set-Based Thinking literature was an excellent frame of reference by which to
begin the development of the novel framework for PD, which began in earnest in Chapter 3. After
carefully constructing the framework over Chapters 3-7, we later find in Section 7.4 that novel
99
outcomes, in fact, cannot be guaranteed, even if a large raw number of options are considered. The
inescapable limits of bounded rationality, as we summarize below, inherently limit the quality and
quantity of options that we can simultaneously consider, which is why attaining novel outcomes
become a chance pursuit.
A Temporal Description of the Process via the Activation of
Constraints
Shortly after describing the process using the terms I introduced in Chapter 3, I establish a
fundamental tenet upon which the rest of the framework builds-that the PD process is temporally
driven by the propagation or activation of dormant constraints. Given that we have approached
describing the process from a set-based perspective as discussed in Chapter 2, it should naturally
follow that in order to move the process forward, constraints must be applied to the initial set of
possibilities, eventually narrowing it to the selection of a single point (i.e. the production version
of a design). Thus, rather than proposing a divergent-convergent process that is typical of most of
the PD literature, the framework describes an idealized process of gradual convergence in order to
select the final product design.
While convergence over a broad initial set of possibilities is not a new notion to the SBD
and related literature, the framework's contribution is to formalize this description via its carefully
defined terms so as to promote common understanding and to guide deeper insight into the
mechanics of the process. Using the richer language of the framework, instead of generalizing this
process as "gradual convergence," we can be more precise in our description, for instance stating
that "as constraints are slowly made active over the initial feasible set in the specification domain,
resolution on architectures explored increases while the set narrows." Of course, from this richer
description of the process, we may ask: how is the first subset of constraints gradually activated?
Our answer, as we shall address in the next subsection, is the articulation of form.
Re-Conceptualizing the Relationship between Function and Form in
Early-Stage Design
Most current theories for PD imply that function maps to form-however, I disagree with
this assertion when describing the front end of the process. While function motivates form, I assert
100
that "function mapping to form" is not the appropriate causal relationship to explain the mechanics
of early stage design. The view espoused by the framework is most succinctly stated by the
Surjective Theorem (introduced in Section 5.1) which implies that the architectural domain maps
to the specification domain-or that form maps to function. This assertion can be approached
from a variety of perspectives from smaller, cumulative insights as they are made throughout the
thesis. A few of these insights are summarized below:
" The framework's definition for architecture: As established in Section 3.4, unlike
most existing design theories, our definition of architecture does not try to formalize the
relationship between function and form. This is established from our understanding of the
relationship between the two domains in which we work.
-
The specification domain is an artificial construct: The specification domain is where
we measure the success of our design in carrying out its intended functions. It is also an
artificial construct that is created by designers to organize our thinking about something
that, unlike form, is not innately intuitive (i.e. product function). Thus, the only way to
explore this domain is to map architectures onto it.
" How PD in practice differs from the idealized model presented by the framework:
As addressed in Chapter 6, deviations from our ideal take on the PD process, such as a lack
of knowledge of the surjective function, the uncertainty of variables, and the unknown
bounds of feasibility are managed via the expression of form.
The result of these observations is that the articulation of form precedes (and in fact,
enables) the exploration of function. While "zig-zagging" (Suh 1995) between function and form
is common in practice (i.e. one form is tested and measured for its function, which then informs
the selection of the next form to try out, etc.), it is somewhat misleading to imply that function
maps to form when the first step to exploring function is to propose some form of arbitrary
resolution.
This perspective bears great significance in discussing the Designer's Dilemma,
addressed below.
The Designer's Dilemma and its Relation to Fixation
The relationship of form onto function implies that we cannot directly sample the
specification domain in early stage design (by analytical means or otherwise). This fact, coupled
101
with our innate human cognitive limitations as expressed by bounded rationality, implies that as
we continue to generate ideas, we are inherently influenced by the nature of past ideas explored.
Furthermore, analyzing the mechanisms underlying ideation in early stage design, we take a strong
view on fixation-concluding that defixation strategies that are based on "indiscriminate search"
do not prevent the Designer's Dilemma as they do not fundamentally alter the flawed 22 way in
which we currently propose ideas.
Of course, describing concept development and ideation particularly in early-stage design
as "indiscriminate" or "blind" search is a result from our analysis using the Designer's Dilemma
in Chapter 7. It is important to note, as we do earlier, that this search is not truly "random," as a
random search would not be affected by fixation and may in fact produce a higher variance of
ideas (and thus greater diversity of options considered) in practice. In light of this, we propose a
distinction between the "blind" search that is typical of the vast majority of current ideation
techniques and methods for "informed search," which is identified as an area for future work.
However, without fundamental improvements to our current methods of "indiscriminate" or
"blind" search, novel outcomes are largely up to chance and cannot be guaranteed.
Proposing a Preferred Order for Constraint Propagation
Given the central role of constraints in moving the process forward, we assert the existence
of a preferred order by which constraints should be propagated in order to avoid the deleterious
consequences of rework, change propagation, and similar problems that are often encountered
during the development of our increasingly complex product development systems.
In other
words, our hypothesis is that improper constraint propagation whereby certain volatile parameters
are prematurely locked down can expose our systems to the unanticipated consequences of changes
that inevitably occur due to the high levels of uncertainty during the PD process.
While we do not have the luxury in this work to build and test such a framework, we
propose the foundation for determining a preferred order for constraint propagation using
22
The process is inherently flawed since we are forced to articulate form within the limits of our bounded rationality
and inability to simultaneously compare many alternatives at once.
102
econometric-modeling inspired approach (see Chapter 8).
With an understanding of the
explanatory variables for a given design problem, we can begin the process of inferring which
constraints should be activated prior to others based on our appreciation of pertinent causal
relationships and ensuing variable sensitives. As we discuss in Chapter 8, a caveat to this approach
is that the results can only generalize to similar problems explored; however, as more examples
are studied, the potential for finding and establishing more universal heuristics certainly increases.
Reinterpretations of Existing Work on Design Theory
During our development of the framework, we have also come across a few opportunities
to reinterpret various facets of established design theory, in many cases giving new meaning to
these streams of work. A few these reinterpretations are summarized below, along with references
to where detailed discussion on these points can be found in the text:
-
Why Set-Based Thinking cannot guarantee novel outcomes: As we establish during
our discussion of the Designer's Dilemma, unanticipated outcomes cannot be expected
from following an SBD approach. This is discussed in further detail in Section 7.4.
-
MDO, Pareto efficiency, and their limitations in the front end of the PD process:
The framework presents an idealization of PD whereby the entire process can be thought
of optimizing in the specification domain, detailed in Chapter 5.
However, these
idealizations do not apply to the front end with which we are particularly interested in this
thesis, as addressed in Chapter 6.2.
-
The Pareto frontier as a subset of the surjection between the architectural and
specification domains: This observation is first addressed in Section 5.3, and is also
elaborated upon further in the Appendix.
-
Why artificial intelligence was and remains a difficult pursuit for our research
community: Without an understanding of how to analogize human cognitive processes
during early stage design into a reliable algorithm, the framework instructs us that the
abstract threat of artificial intelligence replacing or subsuming high-level human decisionmaking remains hypothetical and not actionable (further discussion is found in Section
7.4).
This observation also explains the more realistic outlook the design theory
community has adopted for this line of work over the years.
103
Interpreting the Contributions of this Work
In Section 9.1, we describe how the framework hopes to provide a new qualitative
description of this process, in addition to three additional underlying goals. These goals are
mapped to the new ways of thinking that have been summarized in Table 3. Consider the example
of a temporal description of the process via the activation of constraints. While the description of
constraints transitioning from "dormant" to "active" states is a re-conceptualization of the front
end, it does not challenge any implied causal relationships that are assumed to be true in the
engineering design literature. However, regarding re-conceptualizing the relationship between
function for form, not only does this repaint a picture of activity in the front end, but it also
challenges the assumption of function onto form.
Table 3: Interpreting the Contributions of this Work
What Does This Work Hope to Achieve?
What New Ways of
Thinking are Proposed?
Re-Conceptualizes
Front End
Challenges
Assumed Causal
Relationships
Presents Groundwork
for Investigating
Latent Research
Challenges
Set-Based Thinking and
Considering More Options
Temporal Description of
the Process via Constraint
Activation
X
Re-Conceptualizing
Relationship between
Function and Form
X
X
The Designer's Dilemma
X
Preferred Order for
Constraint Propagation
Reinterpreting Existing
Design Theory
104
X
9.3 What are Areas for Future Work?
In our discussion over the previous section, we have alluded to a number of areas for future
work. These topics, in addition to a few which thus far have not been formally addressed in the
text, are discussed in the subsections to follow.
A Call for a Deeper Cognitive Understanding of the Front End of the
Process
Central to building up to the Designer's Dilemma and analyzing the ensuing issues is the
need to pursue of a deeper understanding of the mechanics underlying cognition during the creative
pursuit of early stage design. Building such knowledge may reveal the key to preventing the
inherent fixation that results from the Dilemma. Pursuant to studying this are a few potential areas
of inquiry:
" Developing techniques to sample the limits of feasibility and enable "informed
search": Given that the pursuit of optimality often occurs at the bounds of feasibility,
techniques to enable the search of these bounds in early-stage design may bear promise for
more robust concept generation methods.
" Exploring cross-domain variable sensitivity: Understanding how changes in design
parameters in the architectural domain map to changes in specifications in the specification
domain may help enable more efficient ideation to sample larger portions of the solution
space as desired.
-
What cognitive mechanisms are at play during common concept development
and opportunity identification exercises?:
Answering this question can help us
objectively analyze how effective certain ideation techniques are (e.g. gallery method,
morphological matrix, etc.).
With this knowledge, can these ideation techniques be
redesigned to more effectively sample the feasible set of options?
Developing an Econometrics Approach to PD Modeling
As referenced in Chapter 8 and again in Section 9.2, the use of regression analysis
techniques from econometrics can potentially yield useful insights into proposing a preferred order
105
for constraint propagation for certain PD projects. However, these modeling techniques bear great
potential to address questions beyond the issue of constraint propagation. Given the simultaneous
pressures of 1) the increasing complexity of the products we design (Lewis 2012), and 2) the
intricate broader social, political, and economic contexts in which consumers can no longer be
regarded passive end users of the products we create (von Hippel 2005), it is largely inadequate to
apply engineering domain knowledge that is not at least informed by. expertise from other areas to
our problems. Due to the current difficulties we encounter in accounting for external, traditionally
non-technical factors within our engineering-driven models and methodologies for PD, it may be
of significant benefit to the design literature to incorporate more rigorous research methods from
the social sciences to our models, such as econometric methods, particularly for early stage design.
The potential implications are broad and fascinating.
For instance, understanding causal
relationships within our PD systems (among factors that are not strictly technical) may help
designers transcend the design of products in the short-term, enabling them to predict and
proactively design for nascent market needs.
Expanding the Framework
In Chapter 1, we describe an analogy to the development of our framework to that of
common law. In this sense, the framework is continually emergent, expanding it to address more
questions about the PD process will only bear greater meaning to prior established elements and
principles. Thus, there are many opportunities to expand the framework established thus far, a
non-exhaustive list of which is presented below:
-
Expanding Set-Based Thinking: In (Ghosh and Seering 2014), we identify a number
of potential inquiries to expand the Set-Based Thinking paradigm described in Chapter 2.
While the remainder of the thesis does not necessarily address these project managementoriented issues, addressing questions such as "which types of organizations are more suited
for SBD?" and "what is the cost of pursuing SBD and is it always worth the cost?" are
particularly pertinent to practitioners who wish to apply SBD and affiliated methods.
" Addressing system design concerns: Designing multi-level PD systems pose a unique
set of challenges for designers, who must consider a host of issues such as those associated
with the integration of individual subsystems into the greater system (Blanchard and
106
Fabrycky 1990).
While the examples discussed thus far in the framework have not
necessarily been described from a multi-level system perspective, there is no reason to
believe that subsystem and integration design tasks cannot be represented within this
framework. Developing examples and exploring how, for example, integration tasks can
be accounted for (perhaps via added dormant constraints) is a topic of future study.
Formally incorporating objectives: Thus far, we have accounted for the exploration of
product function via the articulation and measurement of specifications. Given the analogy
of the PD process to conducting an optimization problem in the specification domain, it
would be appropriate to formally incorporate notions of an objective function into the
framework.23
Currently this information is handled indirectly via the propagation of
constraints (for example, those pertaining to consumer demand), which can theoretically
be expressed analytically in the specification domain.
9.4 Concluding Thoughts
-
"A science of artificialphenomena is always in imminent danger of dissolving and vanishing."
Hebert A. Simon, The Sciences of the Artificial
In this thesis, I develop and study a novel framework for PD. While the framework as
described in this work is still quite nascent, it is my sincere hope that our discussion thus far will
have caused the reader to think about the seemingly familiar PD process in new ways. If I am
extremely fortunate, this framework will have inspired the reader to pursue questions that, due to
my fixation with the task of articulating this thesis, I would not have anticipated myself. Even if
23
I do not anticipate elements of the global objective function to be mutually exclusive to the expression of the
surjection which maps architecture to specification. However, whereas the surjection is the analytic function which
accepts design parameters as inputs and provides specifications as outputs, the objective function takes inputs of
specifications (and design parameters indirectly) and outputs aggregated objective values (values which weigh the
influence of individual specifications in a design, for instance).
Thus, these concepts are distinct, where the
specification domain could potentially be thought to map to another space which describes design objective value.
107
I am not that fortunate, I would hope that this thesis will have convinced the reader that the
fundamentals of the PD process are still worth studying.
I opened this work with the context of Simon's plea for a "teachable doctrine" for design.
To teach is to inspire, and even if this framework does not embody the full intent of Simon's vision
for a teachable doctrine, if the reader leaves with an appreciation for studying the enigmatic yet
worthwhile challenge that is the product development process, then I have succeeded at my task.
108
References
Antonsson, E. K., and K. N. Otto. 1995. "Imprecision in Engineering Design." Journal of
MechanicalDesign117 (B): 25-32.
"Artificial
General
Intelligence."
Artificialgeneralintelligence.
2015.
Wikipedia.
https://en.wikipedia.org/wiki/
Bilton, Nick. 2015. "Disruptions: On the Fast Track to Routine 3-D Printing." New York Times.
http://bits.blogs.nytimes.com/2013/02/17/disruptions-3-d-printing-is-on-the-fasttrack/?nl=todaysheadlines&emc=editth_20130218&_r=0.
Blanchard, B. S., and W.J. Fabrycky. 1990. Systems EngineeringandAnalysis. Englewood Cliffs,
N.J.: Prentice Hall.
Blessing, Lucienne. 2003. "Future Issues in Design Research." In Human Behaviour in Design,
edited by Udo Lindemann, 298-303. Berlin: Springer-Verlag Berlin Heidleberg.
"BMW 3 Series (E90) 2005-2008." 2015. Autoevolution. http://www.autoevolution.com/
cars/bmw-3-series-e90-2005.html#aengbmw-3-series-sedan-2005-318i.
"BMW 3 Series (E90) 2008-2011." 2015. Autoevolution. http://www.autoevolution.com/
cars/bmw-3-series-e90-2008.html#.
Braha, Dan, David C Brown, Amaresh Chakrabarti, Andy Dong, Georges Fadel, Jonathan R A
Maier, Warren Seering, David G Ullman, and Kristin Wood. 2013. "DTM at 25: Essays on
Themes and Future Directions." In ASME International Design Engineering Technical
Conferences. Portland, OR.
Canbaz, Baris, Bernard Yannou, and Pierre-Alain Yvars. 2013. "Expanding the Bottom-Up
Approach Through Intergrating Design Attitudes into Set-Based Design." In ASME
InternationalDesign EngineeringTechnical Conferences. Portland, OR.
"Cardinality
of
Surjection."
CardinalityofSurjection.
2015.
Proof
Wiki.
https://proofwiki.org/wiki/
Carlos, S., Kaarthic Madhavan, G. Gupta, A. Keese, U. Maheshwaraa, and Carolyn C Seepersad.
2006. "A Flexibility-Based Approach to Collaboration in Multiscale Design." In 11th
AIAA/ISSMO MultidisciplinaryAnalysis and Optimization Conference. Portsmouth, VA.
Chanron, Vincent, and Kemper Lewis. 2005. "A Study of Convergence in Decentralized Design
Processes." Research in EngineeringDesign 16 (3): 133-145.
109
"Chinese Room." 2015. Wikigedia. https://en.wikipedia.org/wiki/Chineseroom.
Cormier, Phillip, Andrew Olewnik, and Kemper Lewis. 2013. "Towards a Formalization of
Affordance Modeling in the Early Stages of Design." In ASME International Design
Engineering TechnicalConferences. Portland, OR.
Dahmus, Jeffrey B, Javier P Gonzalez-Zugasti, and Kevin N Otto. 2000. "Modular Product
Architecture." In ASME International Design Engineering Technical Conferences.
Baltimore, MD.
Day, George S. 2007. "Is It Real? Can We Win? Is It Worth Doing?" HarvardBusiness Review
85 (12): 110-120.
De Neufville, Richard. 2003. "Real Options: Dealing with Uncertainty in Systems Planning and
Design." IntegratedAssessment 4 (1): 26-34.
Devendorf, Erich, and Kemper Lewis. 2011. "The Impact of Process Architecture on Equilibrium
Stability in Distributed Design." JournalofMechanicalDesign133 (10): 1-12.
Dym, Clive L., Alice M. Agogino, Ozgur Eris, Daniel D. Frey, and Larry L. Leifer. 2005.
"Engineering Design Thinking, Teaching, and Learning." Journal ofEngineeringEducation
94 (1): 103-120.
Finch, William W, and Allen C Ward. 1997. "A Set-Based System for Eliminating Infeasible
Designs in Engineering Problems Dominated by Uncertainty." In ASMEInternationalDesign
EngineeringTechnical Conferences. Sacremento, CA.
Finger, Susan, and John R. Dixon. 1989. "A Review of Research in Mechanical Engineering
Design. Part I: Descriptive, Prescriptive, and Computer-Based Models of Design Processes."
Research in EngineeringDesign (1): 51-67.
"Fixation." 2015. Dictionary.com Unabridged Accessed July 5. http://dictionary.reference.com/
browse/fixation.
Ford, D.N., and D.K. Sobek. 2005. "Adapting Real Options to New Product Development by
Modeling the Second Toyota Paradox." IEEE Transactionson EngineeringManagement52
(2): 175-185.
"Fourteenth
Amendent
of the United States Constitution."
2015.
Wikipedia.
https://en.wikipedia.org/wiki/FourteenthAmendmenttotheUnitedStatesConstitution.
Friedman, Thomas L. 2015. "Hillary, Jeb, Facebook and Disorder." New York Times.
http://www.nytimes.com/2015/05/20/opinion/thomas-friedman-hillary-jeb-facebook-anddisorder.html?_r-0.
110
Galvan, Edgar, and Richard Malak. 2012. "A Genetic Algorithm Approach for Technology
Characterization." In ASME International Design Engineering Technical Conferences.
Chicago, IL.
Ghosh, Sourobh, Erich Devendorf, and Kemper Lewis. 2014. "Testing the Parallel Character
Hypothesis for Distributed Design Procceses Subjected to Stochastic Disruptions." Artificial
Intelligence for EngineeringDesign, Analysis & Manufacturing28 (4): 399-412.
Ghosh, Sourobh, and Warren Seering. 2014. "Set-Based Thinking in the Engineering Design
Community and Beyond." In ASME International Design Engineering Technical
Conferences. Buffalo, NY.
Gil, Nuno, Sara Beckman, and Iris D Tommelein. 2008. "Upstream Problem Solving Under
Uncertainty and Ambiguity: Evidence From Airport Expansion Projects." IEEE Transactions
on EngineeringManagement55 (3): 508-522.
Goodwin, Tom. 2015. "The Battle Is for the Customer Interface." TechCrunch.
http://techcrunch.com/2015/03/03/in-the-age-of-disintermediation-the-battle-is-all-for-thecustomer-interface/#.derbth:9SFc.
Gossard,
David.
2009.
"Sketching
and
Drawing."
MIT
OpenCourseWare.
http://ocw.mit.edu/courses/mechanical-engineering/2-007-design-and-manufacturing-ispring-2009/lecture-notes/MIT2_007s09_lecO4.pdf.
Haggman, Anders, Tomonori Honda, and Maria C Yang. 2013. "The Influence of Timing in
Exploratory Prototyping and Other Activities in Design Projects." In ASME International
DesignEngineeringTechnical Conferences. Portland, OR.
Helms, S, F G H Behncke, L Lindl6f, M C Wickel, and U Lindemann. 2014. "Classification of
Methods for the Indication of Change Propagation - A Literature Review." In International
Design Conference - DESIGN2014, 211-220.
"HSC Dolphin Jet." 2013. http://en.wikipedia.org/wiki/HSCDolphinJet.
Hubka, Vladimir, M. Myrup Andreasen, and W. Ernst Eder. 1988. PracticalStudies in Systematic
Design. London: Butterworths.
Iansiti, Marco. 1995. "Shooting the Rapids: Managing Product Development in Turbulent
Environments." CaliforniaManagementReview 38 (I): 37-58.
Jansson, DG, and SM Smith. 1991. "Design Fixation." Design Studies 12 (1): 3-11.
111
Jiao, Jianxin, Timothy W. Simpson, and Zahed Siddique. 2007. "Product Family Design and
Platform-Based Product Development: A State-of-the-Art Review." Journal of Intelligent
Manufacturing18 (1): 5-29.
Kelly, Danny. 2013. "The Advantages and Disadvantages of the No-Huddle, Hurry-up Offense in
the NFL." SB Nation. http://www.sbnation.com/2013/9/13/4722170/no-huddle-hurry-upoffense-nfl-peyton-manning-chip-kelly.
Kerga, Endris. 2013. "Set-Based Concurrent Engineering: A Learning Method to Increase
Awamess Level in Industry & A Methodolgy to Identify and Prioritize Areas at a Product
Leve." Ph.D. thesis, Politecnico di Milano.
Lee, Seung-Il, Jun-Seo Bae, and Young Sang Cho. 2012. "Efficiency Analysis of Set-Based
Design with Structural Building Information Modeling (S-BIM) on High-Rise Building
Structures." Automation in Construction23 (May): 20-32.
Lewis, Kemper. 2012. "Making Sense of Elegant Complexity in Design." JournalofMechanical
Design 134 (12): 120801.
Lewis, Kemper, and Farrokh Mistree. 1998. "Collaborative, Sequential, and Isolated Decisions in
Design." JournalofMechanicalDesign120 (12): 643-652.
Linsey, J. S., I. Tseng, K. Fu, J. Cagan, K. L. Wood, and C. Schunn. 2010. "A Study of Design
Fixation, Its Mitigation and Perception in Engineering Design Faculty." Journal of
MechanicalDesign 132 (4): 1-12.
Madhavan, Kaarthic. 2007. "A Framework for a Flexibility- Based Approach to Multiscale and
Multidisciplinary Design." M.S thesis, University of Texas at Austin.
Madhavan, Kaarthic, David Shahan, Carolyn C Seepersad, Danny A Hlavinka, and Walt Benson.
2008. "An Industrial Trial of a Set-Based Approach to Collaborative Design." In ASME
InternationalDesign Engineering Technical Conferences. New York, NY.
Maier, Jonathan R. a., and Georges M. Fadel. 2008. "Affordance Based Design: A Relational
Theory for Design." Research in EngineeringDesign 20 (1) (December 12): 13-27.
Malak, Richard J., Jason Matthew Aughenbaugh, and Christiaan J.J. Paredis. 2009. "MultiAttribute Utility Analysis in Set-Based Conceptual Design." Computer-AidedDesign 41 (3)
(March): 214-227.
Malak, Richard J., and Christiaan J. J. Paredis. 2010. "Using Parameterized Pareto Sets to Model
Design Concepts." JournalofMechanicalDesign132 (4): 1-11.
112
Mebane, Walter L., Craig M. Carlson, Chris Dowd, David J. Singer, and Michael E. Buckley.
2011. "Set-Based Design and the Ship to Shore Connector." NavalEngineersJournal123 (3):
79-92.
Meyer, Marc H., and Alvin P. Lehnerd. 1997. The Power ofProductPlatforms. New York: Free
Press.
Nahm, Y.-E., and H. Ishikawa. 2006. "A New 3D-CAD System for Set-Based Parametric Design."
The InternationalJournalofAdvanced ManufacturingTechnology 29 (1-2) (April 5): 137150.
Nykamp, D.Q. "Countably Infinite
definition/countablyinfinite.
Defintion."
Math
Insight.
http://mathinsight.org/
Oberg, J. 1999. "Why the Mars Probe Went off Course." IEEE Spectrum Magazine.
Oosterwal, Dantar. 2010. The Lean Machine:HowfHarley-DavidsonDrove Top-Line Growth and
Profitabilitywith RevolutionaryLean ProductDevelopment. New York: AMACOM.
Orsborn, Seth, Jonathan Cagan, Richard Pawlicki, and Randall C. Smith. 2006. "Creating Crossover Vehicles: Defining and Combining Vehicle Classes Using Shape Grammars." Artificial
Intelligence for EngineeringDesign, Analysis and Manufacturing20 (03) (June 27): 217246.
Pahl, Gerhard, and Wolfgang Beitz. 1988. EngineeringDesign:A Systematic Approach. London:
The Design Council.
Pahl, Gerhard, Wolfgang Beitz, Jorg Feldhusen, and Karl-Heinrich Grote. 2007. Engineering
Design:A Systematic Approach. 3rd ed. London: Springer.
Panchal, Jitesh H., Marco Gero Fernandez, Christiaan J.J. Paredis, Janet K. Allen, and Farrokh
Mistree. 2007. "An Interval-Based Constraint Satisfaction (IBCS) Method for Decentralized,
Collaborative Multifunctional Design." ConcurrentEngineering15 (3): 309-323.
"Pareto
Efficiency."
2015.
Paretoefficiency#Paretofrontier.
Wikipedia.
https://en.wikipedia.org/wiki/
Parker, Robert, and Richard J. Malak. 2011. "Technology Characterization Models and Their Use
in Designing Complex Systems." In ASME InternationalDesign Engineering Technical
Conferences. Washington, DC.
Parrish, Kristen, John-michael Wong, Iris D Tommelein, and Bozidar Stojadinovic. 2007.
"Exploration of Set-Based Design for Reinforced Concrete Structures." In Proc. of15th Conf
of the Int. Group for Lean Construction, 213-222. Michigan, USA.
113
Poppendieck, Mary, and Tom Poppendieck. 2003. Lean Software Development:An Agile Toolkit.
Boston, MA: Addison-Wesley Professional.
Pugh, Stuart. 1991. Total Design: IntegratedMethods for Successful Product Engineering. New
York: Addison-Wesley.
Raudberget, Dag. 2010. "Practical Applications of Set-Based Concurrent Engineering in
Industry." JournalofMechanical Engineering56 (11): 685-695.
Robertson, David, and Karl Ulrich. 1998. "Planning for Product Platforms." Sloan Management
Review 39 (4): 19-3 1.
Sacks, Rafael, Lauri Koskela, Bhargav A Dave, and Robert Owen. 2010. "Interaction of Lean and
Building Information Modeling in Construction." Journalof Construction Engineeringand
Management 136 (9): 968-980.
Schmidt, Elisabeth. 2015. "An Approach for Structuring Methods in Product Development
Processes and the Role of Uncertainties." M.S. thesis, Technische Universitat M-inchen.
Schwaber, Ken, and Jeff Sutherland. 2013. "The Scrum Guide
TMi"
"Scrum Primer." http://www.infoq.com/minibooks/ScrumPrimer.
Seepersad, Carolyn C, David Shahan, and Kaarthic Madhavan. 2007. "Multiscale Design for Solid
Freeform Fabrication." In Solid Freeform FabricationSymposium. Austin, TX.
Shah, Jami J., Noe Vargas-Hernandez, Joshua D. Summers, and Santosh Kulkarni. 2001.
"Collaborative Sketching (C-Sketch) - An Idea Generation Technique for Engineering
Design." Journalof CreativeBehavior35 (3): 168-198.
Shan, S., and G.G. Wang. 2004. "Space Exploration and Global Optimization for Computationally
Intensive Design Problems: A Rough Set Based Approach." StructuralandMultidisciplinary
Optimization28 (6) (August 24): 427-441.
"Ship-to-Shore Connector Implementation of Set-Based Design." 2009. Internal Report.
NAVSEA, Washington, D.C.
Simon, Herbert A. 1996. The Sciences ofthe Artificial. 3rd ed. Cambridge, MA: MIT Press.
Simpson, Timothy W. 2004. "Product Platform Design and Customization: Status and Promise."
AI EDAM: Artificial Intelligence for EngineeringDesign, Analysis and Manufacturing 18
(01): 3-20.
114
Singer, David J., Norbert Doerry, and Michael E. Buckley. 2009. "What Is Set-Based Design?"
Naval EngineersJourna121 (4) (October 11): 31-43.
Sobek, Durward K., Allen C Ward, and Jeffrey K Liker. 1999. "Toyota's Principles of Set-Based
Concurrent Engineering." Sloan ManagementReview 40 (2): 67-83.
"Stare
Decisis."
2015.
Legal Information
https://www.law.cornell.edu/wex/staredecisis.
Institute.
Accessed
July
14.
Stiny, G. 1980. "Introduction to Shape and Shape Grammars." Environment and Planning 7
(November): 343-351.
Suh, Nam P. 1995. "Axiomatic Design of Mechancial Systems." Journal ofMechanicalDesign
117 (6): 2-10.
"Superintelligence." 2015. Wikipedia. https://en.wikipedia.org/wiki/Superintelligence.
"Surjective Function." 2015. Wikipedia. https://en.wikipedia.org/wiki/Surjectivefunction.
Sutherland, Jeff, Anton Viktorov, Jack Blount, and Nikolai Puntikov. 2007. "Distributed Scrum:
Agile Project Management with Outsourced Development Teams." In Proc. of the 40th
Hawail InternationalConference on System Sciences, 1-10.
Thomke, Stefan. 2003. Experimentation Matters. 1st ed. Boston, MA: Harvard Business School
Publishing Corporation.
Thomke, Stefan, and Donald Reinertsen. 1998. "Agile Product Development: Managing
Development Flexibility in Uncertain Environments." CaliforniaManagementReview41 (I):
8-30.
Ulrich, Karl T. 1994. "The Role of Product Architecture in the Manufactruing Firm." Research
Policy24 (3): 419-440.
Ulrich, Karl T., and Steven D. Eppinger. 2012. ProductDesign and Development. 5th ed. New
York: McGraw-Hill, Inc.
Viswanathan, Vimal K., and Julie S. Linsey. 2013. "Role of Sunk Cost in Engineering Idea
Generation: An Experimental Investigation." JournalofMechanicalDesign135 (12): 1-12.
Von Hippel, Eric. 2005. DemocratizingInnovation. Cambridge, MA: MIT Press.
Ward, Allen C. 1989. "A Theory of Quantitative Inference for Artifact Sets, Applied to a
Mechanical Design Compiler." Massachusetts Institute of Technology.
115
Ward, Allen C, and Warren Seering. 1989. "Quantitative Inference in a Mechanical Design
'Compiler."' In ASME InternationalDesign EngineeringTechnical Conferences.
Ward, Allen, Jeffrey K Liker, John J Cristiano, and Durward K. Sobek. 1995. "The Second Toyota
Paradox: How Delaying Decisions Can Make Better Cars Faster." Sloan Management
Review 36 (3): 43-61.
Weisstein, Eric W. 2015. "Surjection." Wolphram Math World http://mathworld.wolfram.com/
Surjection.html.
Womack, James P., Daniel T. Jones, and Daniel Roos. 2007. The Machine That Changed the
World New York.
Yang, Maria C. 2005. "A Study of Prototypes, Design Activity, and Design Outcome." Design
doi:10.1016/j.destud.2005.04.005.
649-669.
(November):
26
(6)
Studies
http://linkinghub.elsevier.com/retrieve/pii/S0142694X050003OX.
Yang, Maria C. 2008. "Observations on Concept Generation and Sketching in Engineering
Design." Research in EngineeringDesign20 (1): 1-11.
Yi, S., J. Shin, and G. Park. 2008. "Comparison of MDO Methods with Mathematical Examples."
StructuralandMultidisciplinaryOptimization3 5 (3): 391-402.
"Zoom, Sputter, Aagghhh!!" 2013. The Economist. http://www.economist.com/blogs/
graphicdetail/2013/09/daily-chart-i 8?fsrc=scn/fb/wl/tr/zoomsputteraagghhh.
116
Appendix
Herein we review a handful of topics for further edification for the reader. They represent
ideas which I could not formally validate during the duration of the thesis, and thus are referenced
here in order to be studied and formalized in future work.
Al The Pareto Frontier as a Subset of the Surjection's
Codomain
In Section 5.3, we assert the possibility that the Pareto frontier is a subset of the codomain
of the analytic surjective function as expressed in this work.
Let us begin with a mathematical description of the Pareto frontier, P(Y), provided from
Wikipedia ("Pareto Efficiency" 2015). We have a system with function
f: R'
-> R', where X is
a compact set of feasible decisions in the metric space R', and Y is the feasible set of criterion
vectors in R' such that Y = fy E Rm: y = f(x), x E X}. Assuming the preferred directions of
criteria values are known, a point y" E Rm is preferred to another point y' E R:. Thus, the Pareto
frontier is written as: P(Y) = fy' E Y: fy" E Y
y" > y', y" # y'} = 01.
Our focus in this definition is on the function fwhich maps points in the set X to the set Y.
This function
f in the definition above
maintains that for every y in Y, there must be an element
x in X such that f (x) = y. Fundamentally, this is a re-articulation of the definition for a surjection
(see Section 5.1). Thus, we claim that
f
is in fact a surjection, and that P(Y) is a subset of the
codomain of f (i.e. the set Y).
A2 Cardinality of the Two Domains
Another property of a surjective function is the cardinality of its domain is greater than or
equal to the cardinality of its codomain.
A proof can be found in the following reference
("Cardinality of Surjection" 2015).
117
With the Surjective Theorem, at a fixed level of resolution, we can assert that the number
of instances in the architectural domain is equal to or greater than or equal to the number of
instances in the specification domain. Intuitively, this should follow from our understanding that
each instance in the specification domain must have at least one instance from the architectural
domain mapping to it (and that as a mathematical function, one instance in the architectural domain
cannot map to more than one instance in the specification domain).
Suppose we knew of all the instances in the architectural and specification domains,
respectively, and that we could count them. Now suppose we are given the task to randomly
choose two instances from the specification domain, which we shall call pair A. For simplicity,
let us assume that there is only one specification of interest in the specification domain. After
selecting pair A, we measure their difference in specificity values. Now, putting pair A back into
the specification domain, we are asked to choose two instances at random from the architectural
domain. We then map these two instances from the architectural domain to their corresponding
instances in the specification domain. Let us call these corresponding instances in the specification
domain pair B. As before, we measure the difference in specification values between pair B. Now
we are asked: is the difference between the specification values in pair B as likely to be as great as
it is in pair A?
Given the cardinality of the two domains, I assert that pair B (the pair of instances we
mapped from those that we selected in the architectural domain) are not as likely to be as different
as pair A (the pair that we directly selected from the specification domain). This property bears
interesting implications for how designers ideate. For instance, if we chose two instances at
random from the architectural domain, even if these instances have diverse design parameter
values, will these differences map to proportional differences in the specification values in the
specification domain? That is, even if we make the effort to articulate two architectures that are
seemingly different from one another, is the performance of these architectures likely to be as
different? My argument is that this is not guaranteed, and it fundamentally poses a challenge for
designers.
Exploring how variable sensitivities map across domains (i.e. do given design
parameter variations map to corresponding variations in specification values?) is a topic for future
work (see Section 7.5 for further discussion).
118