ProQuest Dissertations

A UNIFIED INNOVATION PROCESS MODEL FOR ENGINEERING DESIGNERS AND MANAGERS

A DISSERTATION SUBMITTED TO THE DEPARTMENT OF MECHANICAL ENGINEERING AND THE COMMITTEE ON GRADUATE STUDIES OF STANFORD UNIVERSITY IN PARTIAL FULFILLMENT OF THE REQUIREMENTS ÔR THE DEGREE OF DOCTOR OF PHILOSOPHY

Philipp Leo Stefan Skogstad June 2009

UMI Number: 3364513

Copyright 2009 by Skogstad, Philipp Leo Stefan

INFORMATION TO USERS

The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion.

®

UMI

UMI Microform 3364513 Copyright 2009 by ProQuest LLC All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code.

ProQuest LLC 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346

© Copyright by Philipp Leo Stefan Skogstad 2009 All Rights Reserved

I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy.

I certify that I have read this dissertation and that, iff my opM)n, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy.

I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy.

(J. Christian Gerdes) I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy.

(Martin Steinert) I certify that I have read this dissertation and that, in my opinion, it is fully adequate in scope and quality as a dissertation for the degree of Doctor of Philosophy.

/

(Geora (George Toye)

Approved for the Stanford University Committee on Graduate Studies

t

^k./. rt~r ~'

in

A Unified Innovation Process Model for Engineering Designers and Managers

IV


Abstract Leaders in business, engineering and politics consistently preach the need for innovative solutions to solve today's problems and to strengthen the global economy. At the same time, there is relatively little understanding of how people create new concepts during the front-end of innovation. Innovation management research has traditionally been centered around the design process from an economic point of view, whereas engineering research has focused on modeling the path of solution evolution. The research presented in this dissertation combines these two distinct perspectives into a unified model. This model describes how designers gain the insights needed to create novel solutions and how reviewers can have both positive and negative effects on the design process.

The

supporting research focuses on the largely unacknowledged negative effects.

The research is based on evidence collected over five years in a globally distributed, graduate level design curriculum that challenges students with real-world problems. Based on a study of the top-performing teams, it has been found that these teams gained their key insights while building and testing prototypes, rather than while deliberating the possible merits of ideas. It is therefore hypothesized that designers who move promptly and frequently from planning to execution will develop more innovative solutions to design problems. Furthermore, interviews with members and reviewers of these design teams, and an analysis of their design

v


processes, reveal that these teams regularly moved towards executing an idea despite advice to the contrary from reviewers or experts.

This

suggests that reviewers or experts who censor ideas, whether knowingly or unknowingly, before they can be tested have a marked detrimental effect on the ability of designers to gain insights. A model of the design process that fuses the designer's and the reviewer's point of view has been developed. This model represents a kernel that is expected to apply universally to all phases and levels of the design process. It includes three activities (Plan, Execute, Synthesize) and the feedback pathways that are initiated by the designers themselves, as well as those activated by outside reviewers. The model, which provides a logical explanation for the discoveries above, is supplemented and clarified by an ontology.

This ontology specifies the model's actors,

functions, and rules in addition to demonstrating its internal consistency. The model is proposed as a possible explanation for the consistent innovative success of companies such as 3M, Google or Genentech. It is also expected to serve as a training tool for managers and designers alike and as an instrumentation map for future research in the fields of both management and design. The hypotheses have also been tested quantitatively by examining the relationships between design performance, documented design activities, and communication with reviewers and coaches. The analysis shows that


transitions from planning to execution and breadth of search for solutions correlate positively and significantly with design performance.

It also

shows that communication by coaches correlates positively and significantly with design activity, especially prototyping, and that communication by a particular reviewer, who is a self-proclaimed 'anticensor', correlates positively and significantly with design performance.

VII


Acknowledgments The cover page of this dissertation shows only my name but it is the brainchild of many. I am deeply indebted to mentors, colleagues, and friends who helped me in many ways. The list of people is long and I will never be able to list them all but I would like to mention those who contributed most significantly. First, I want to thank Larry Leifer, my advisor. He has been an inspirer, mentor, role model, and supportive friend for many years. His neverending drive to question best practices ("best dogma") and to maintain ambiguity has led me to look into so many factors over the years. Mark Cutkosky and Larry Leifer also deserve special recognition for their trust and confidence in me. Their support of my research work and their willingness to never censor my ideas will influence me forever. I also want to thank George Toye for his help with the data collection and ontology and Martin Steinert for his help with the data analysis and for teaching me SPSS. Karl Gumerlock, Matthias Uflacker, and Rebecca Currano have also contributed immensely through discussions and help with the model formulation, data collection, coding and analysis. This dissertation could not have been completed without all of your help and support. Finally, I want to thank my family: my parents and grandparents for having raised me to be ambitious and open to the world, and my fiancee, Nicole Willmering, for her patience with my finally ending tenure in school.

VIII


Table of Contents 1.

Introduction 1.1. 1.2. 1.3.

2.

Motivation Engineering Design Process Management Model Outline of Thesis

Literature Overview 2.1. Design Thinking to Achieve Innovation 2.2. Gap between Designers and Managers 2.2.1. Engineering Design Point-of-View 2.2.2. Innovation Management Point-of-View 2.3. Research nearthe Gap

3.

Research Methodology 3.1. Engineering Curriculum as a Living Laboratory 3.2. Multi-Perspective Study 3.2.1. Study 1 & 2: Designer Perspective 3.2.2. Study 3: Project Manager Perspective 3.2.3. Study 4 & 5: Manager/Partner Perspective 3.2.4. Study 6 & 7: Executive Perspective 3.3. Data Streams in Mixed-Methods Study 3.3.1. Observations and Experiences by Embedded Researcher 3.3.2. Semi-Structured Interviews 3.3.3. Design Documents 3.3.4. Electronic Activity Logs 3.3.5. Questionnaires 3.3.6. Performance Measurement 3.4. Process of Analysis 3.4.1. Hypotheses Generation from Case Studies and Interviews 3.4.2. Hypothesis Testing and Quantitative Analysis

4.

Designers Gain Necessary Insights by Experimenting

1 1 5 9 11 11 16 18 22 27 ...32 32 37 42 .42 43 45 45 48 49 50 51 52 ...58 61 61 65 69

4.1. Case A: Paper Bike 2003/2004 (Designer-Observer) 69 4.2. Case B: Vehicle Interface for IT Generation 2003/2004 (Designer-Observer) ..74 4.3. Case C: Convertible Experience 2004/2005 (Project-Manager-Observer) 80 4.4. Case D: Task Management Software 2005/2006 (Manager/Partner-Observer) 85 4.5. Cross-Case Analysis Reveals Pattern 90 4.5.1. Execution Hypothesis: Designers Succeed through Experimenting and Adapting 93 5.

Managers Should Encourage Experimenting

94

5.1. Reviewers Often Discourage Experimenting 94 5.1.1. Case A: Paper Bike 2003/2004 (Designer-Observer) .94 5.1.2. Case B: Vehicle Interface for IT Generation 2003/2004 (Designer-Observer)

96 5.1.3. Case C: Convertible Experience 2004/2005 (Project-Manager-Observer)..97 5.2. Reviewers Can Encourage Experimenting as Exemplified by Case D: Task Management Software 2005/2006 99

IX

A Unified Innovation Process Model for Engineering Designers and Managers 5.3. 5.4. 6.

Cross-Case Analysis Reveals Pattern 101 Censorship Hypothesis: Reviewers Should Encourage Experimentation rather than Censor Ideas .; 105

Unified Innovation Process Model for Engineering Designers and Managers 106 6.1. Activity Functions 6.1.1. Micro (Phase) Level 6.1.2. Macro (Project) Level. 6.1.3. Recursion of Activity Function String 6.2. Design as Insight Assembly Process 6.3. Designer-Initiated Feedback Pathways 6.3.1. Re-Plan >. 6.3.2. Revise 6.3.3. Rework.... 6.4. Reviewer-Initiated Feedback Pathways and Gates 6.4.1. Approver and Re-Plan Feedback Pathway 6.4.2. Censor and Rehash Feedback Pathway 6.5. Ontology for Model

7.

8.

.:

Quantitative Results

127

7.1.

Findings Concerning Execution Hypothesis

127

7.2.

Findings Concerning Censorship Hypothesis

132

Discussion

8.1. Methodology and Data 8.1.1. Qualitative Analysis 8.1.2. Model Formulation 8.1.3. Quantitative Analysis 8.1.4. Performance Measurement 8.2. Limitations and Applicability of Results 8.3. Recommendations for 310 Curriculum 8.4. Contribution 8.5. Future Work 9. Conclusion 9.1. 9.2. 9.3. 9.4.

Designers Should Move to Execution as Quickly as Possible Designers Should Repeat the Activity String Frequently Managers Should be Careful Not to Censor Unknowingly Managers Should Encourage Designers to Execute

10. References

X

r.

107 108 111 .113 114 114 115 116 117 117 118 119 121

138 138 138 139 140 143 146 148 149 151 153 156 157 158 159 160

A Unified Innovation Process Model for Engineering Designers and Managers 11. Appendices 11.1. 11.2. 11.3. 11.4. 11.5. 11.6. 11.7.

Summary of Data on Teams Exemplary List of Variables Tested Quantitatively Summary of Reports from SPSS Regression Analysis Definitions for Report Coding Scheme Information given to Project Outcome Performance Judges Questionnaires Administered during Projects Team Diagnostic Survey Administered after Completion of Projects

166 166 168 172 180 181 206 210

XI


List of Tables Table 1: Differences between the Front End of Innovation and the New Product & Process Development Process (Koen, et al., 2001) 13 Table 2: Comparison of prevalent new concept development process models from engineering design and innovation management 28 Table 3: Comparison of perspectives' features

39

Table 4: Summary of studies, perspectives and data streams

41

Table 5: Comparison between design research and traditional case study research by Minnemann (1991) 47 Table 6: Process of building theory from case study research (Eisenhardt, 1989)

62

Table 7: Summary of relationships tested quantitatively at the design team level

66

Table 8: Summary of relationships tested quantitatively at the individual designer level. 67 Table 9: Examples of actions performed during each activity at the micro (phase) level to show the universal applicability of the model at this level 109 Table 10: Ontology of model - Actors

123

Table 11: Ontology of model - Rules

123

Table 12: Ontology of model - Functions

124

Table 13: Ontology of model - Axioms

125

Table 14: Summary of results of quantitative analysis performed to test Execution Hypothesis 131 Table 15: Summary of results of quantitative analysis performed to test the Censorship Hypothesis 137 Table 16: Comparison of prevalent new concept development process models from engineering design and innovation management with the 'Unified Innovation Process Model for Engineering Designers and Managers" 150

XII


List of Figures Figure 1: Proposed "Unified Innovation Process Model for Engineering Designers and Managers" depicting the kernel of the design process. It shows where designers gain the insights to advance a design and where reviewers intercept the design process at the censor and approver gates 7 Figure 2: Design Thinking summarized: The iterative process of needfinding & benchmarking, brainstorming, prototyping and testing 15 Figure 3: Comparison of typical views of design process held by designers vs. managers - designers see an iterative learning process while managers see a linear filtering process (adapted from Stanford Design Group and Thorn (1980) 17 Figure 4: Pahl & Beitz' Design Process Model accounts mainly for different levels of refinement, vaguely for feedback and learning but not for actors or decisions (Pahl & Beitz, 1996) 19 Figure 5: French's Design Process Model accounts for feedback and different levels of detail but not for actors, decisions or how learning occurs (French, 1999) 20 Figure 6: Cross' Design Process Model accounts for different levels of detail, feedback, iteration and decisions but not for actors and how learning occurs (Cross, 2000) 21 Figure 7: The innovation funnel shows how many ideas result in only one successful product (Stevens & Burley, 1997) 23 Figure 8: Thorn's Model of Innovation Management accounts for the decisions made by management in the innovation process but it does not account for how ideas are generated, for feedback or for iteration (Thorn, 1980) 24 Figure 9: Stage-Gate® Process, which is the standard for innovation management does not account for idea generation, iteration or feedback (Cooper, 2001) 25 Figure 10: Van de Ven's Innovation Journey provides a descriptive model that accounts for iterations, feedback, actors and decisions but it does not explain how the ideas are generated (Van de Ven, 1999) 26 Figure 11: The four possible energy states described by organizational energy, a measure of an organization's level of mobilization of its full potential (Bruch, undated) 30 Figure 12: Timeline of Design Curriculum Depicting Major Milestones

33

Figure 13: 'Design Loft'- the classroom of the curriculum studied

34

Figure 14: Timeline of points at which research questionnaires were administered to designers 52 Figure 15: Timeline of Paper Bike project.

70

Figure 16: Initial wheel bearing design that was a "failure"

72

Figure 17: Redesigned light-weight wheels with laminations and cored holes

73

Figure 18: Buttons mounted to front and back of steering wheel with driving as the primary task 76

XIII

A Unified Innovation Process Model for Engineering Designers and Managers Figure 19: QWERTY keyboard mounted to steering wheels as intermediate between driving and typing focus 76 Figure 20: Foot-steering to free the hands for typing only to focus on typing as primary task 77 Figure 21: Final design with unique button layout and haptic feedback to reduce need for visual feedback 79 Figure 22: Examples of ideas tested to control airflow: a) counter airflow creation using blowers, b) nose flow dampers, c) vortex generators, and d) redirectors 81 Figure 23: Wind tunnel model of hole in the windshield

83

Figure 24: Comparison of final design with base case

84

Figure 25: BlinxBar as benchmarking

input tool

inspired from

interface

discovered

during 86

Figure 26: Lego™ pieces were used to simulate the attributes of complex tasks. The different colors stand for different kinds of attributes (such as place, time, resources, documents etc.). This visualization provided the inspiration for a task management interface, which assembles tasks from interchangeable and reusable activities. Each block can be fit with any other block and is interchangeable so that tasks may be modified for reuse without the need for recreating it. For example, a weekly meeting preparation task may be updated for each week by modifying specific documents that are needed and the time of the meeting without the need to modify the other attributes such as place and responsible persons 88 Figure 27: Task Management Interface inspired by Lego™ pieces that represent attributes, which are interchangeable and can be assembled into a task 89 Figure 28: Theory of Adaptive Design Expertise, which suggests that designers succeed by adapting the findings gained by transitioning between practice and theory (Neeley, 2007) 92 Figure 29: 'Unified Innovation Process Model for Engineering Designers and Managers' depicting the kernel of the design process and where reviewers interrupt its flow ". 107 Figure 30: Activity function string "Plan", "Execute", and "Synthesize" which constitute the core of the model 108 Figure 31: Activities and how they map to design process phases at the macro (project) level 112 Figure 32: Recursive nature of the activity function string.

113

Figure 33: Insights that advance the design are gained in execute and synthesize activities 114 Figure 34: Observable designer-initiated feedback pathways

115

Figure 35: Reviewers (e.g. managers, experts or instructors) intercept the design process at two gate points and initiate two additional feedback pathways. ..118 Figure 36: "Field Observation" activities described in design documentation correlate positively (Beta=0.531) and significantly (Sig. = 91%, R2 = 0.28) with output

xiv

A Unified Innovation Process Model for Engineering Designers and Managers performance measured by external judges suggesting that transitions from planning to execution and breadth of inquisition impacts performance 128 Figure 37: The total number of distinct URLs shared within design teams correlates positively (Beta=0.514) and significantly (Sig. = 90%, R2 = 0.27) with output performance measured by external judges suggesting that breath of inquisition impacts performance and that it might be possible to predict performance automatically 130 Figure 38: The number of emails sent by design team coaches correlates positively (Beta=0.630) and significantly (Sig. = 96%, R2 = 0.397) with the total number of activities documented by designers. The number of emails correlates even stronger (Beta=0.816) and more significantly (Sig. = 99%, R2 = 0.666) with the total number of prototyping activities suggesting that coaches have a positive impact on overall execution and prototyping in particular 133 Figure 39: The number of emails sent by the 'anti-censor' member of the teaching team correlates positively (Beta=0.610) and significantly (Sig. = 95%, R2 = 0.372) with output performance 135 Figure 40: Response rate to Team Diagnostic Survey is 92%

142

Figure 41: Unified Innovation Process Model for Engineering Designers and Managers depicting the kernel of the design process. It shows where designers gain the insights to advance a design and where reviewers intercept the design process at the censor and approver gates 154

XV


ix

i


1. Introduction 1.1.

Motivation

Innovation is the basis for economic growth and is therefore to be maximized.

However, both designers and managers can impede

innovation despite their good intentions. Designers create innovations by generating new ideas, demonstrating their feasibility and then developing them to full functionality, ready for production. Managers steer the design process by allocating resources based on their judgment of the merits of each idea.

They also have to ensure that value is created for

shareholders. The two groups have different approaches to succeeding at their tasks and often do not understand each other's actions and decisions. This has a negative impact on the ability of each group to do its job. The goal of this research is to foster innovation by reducing the barriers between the two groups. BusinessWeek launched a new section called "Inside Innovation" in 2006. This sections' manifesto reads "we dedicate ourselves to the proposition that making innovation work is the single most important business challenge of our era" (Nussbaum, 2006).

Similarly, Friedman (2005)

argues that in today's "flat world", the ability to innovate successfully decides the survival of companies, communities and nations. Leadership in industry identifies innovation as the most important driver of

1


competitiveness as well as their number one job priority (Palmisano, 2006). At the same time, 35% of CEOs call an "unsupportive culture and climate" a

critical

roadblock

to

innovation

(Chapman,

2006).

Nussbaum,

BusinessWeek's former editor-in-chief, described the situation in a speech at the Royal College of Art (RCA) in London (2007) as follows: "There are two great barriers to innovation and design in the world today. Ignorant CEOs and ignorant designers. Both groups are wellintentioned and well-dressed—in their own ways—but both can be pretty dangerous characters." It is the aim of this research to further the understanding of how innovation is accomplished and how the achievement of innovation can be hindered or supported by managers and designers.

The

results should guide both groups on how, when and where they can become helpful characters that foster innovation. Innovation is "the process of [...] the development and implementation of ideas by people who over time engage in transactions with others within an institutional context" (Van de Ven, 1986).

Although there is

considerable disagreement over where exactly the process of innovation begins and ends, most scholars agree that generating a new idea and providing proof-of-concept are part of the innovation process. This part of the innovation process, which is also known as the "fuzzy front end" (Reinertsen, 1999), is the subject of this research. The research applies to how new concepts are developed from idea genesis to proof of

2


feasibility, but not viability. Furthermore, the focus is on new concept development in formal institutional contexts, where functions and responsibilities such as design versus management are established and defined, rather than new concept development in social settings or informal networks as described by Cockayne (2004). The innovation process at the "fuzzy front-end" is poorly understood and presents one of the greatest opportunities for improving the overall innovation process (Koen, et al., 2001; Reinertsen, 1999).

Since the

foundation for the success or failure of new concepts is laid during this phase, it is of particular importance to understand how new concepts are created and how the innovative output of this phase can be maximized. New concepts at the proof-of-concept level are the output of this phase, where the prototype successfully demonstrates the feasibility of an idea, but is not intended to be an early version of a production unit or process. Even though many models and theories exist for the creation and management of innovation, few if any combine the perspectives of both the designer (or engineering designer) and the manager. This is because management (or innovation management) research at business schools typically strives to understand how to identify market opportunities or maximize resource utility, whereas design (or engineering design) research is concerned with solving technical problems or satisfying the

3


needs of the end-user. Both approaches ignore two aspects at the core of the design process: 1. How designers acquire the knowledge that allows them to create new concepts. 2. How managers and designers interact to achieve enterprise objectives. Van de Ven (1986) included transactions between people in the definition of innovation presented above, and design research studies have demonstrated the importance of social interactions between design team members during design activity (Cross & Claybum, 1995; Minneman & Leifer, 1993). Brereton (1998) has also shown the importance of learning through shifting between theory and hardware to successfully design in an engineering context.

No attention, however, has been given to the

intercept between designers and managers. If designers and managers are truly as dangerous and ignorant as suggested by Nussbaum (2007), then it is time to devote attention to their interaction and to increase their empathy for each other's perspective and actions. Improving the understanding of the interaction between the design process itself, the process participants, and the process outcome will help both sides — designers and managers alike — to appreciate the other's actions and thereby increase their innovative output.

4


1.2.

Engineering Design Process Management Model

Research in the context of an engineering design curriculum was performed in order to develop this understanding. In this environment, with built-in process documentation, communication logging, and performance measurement, it is possible to study three critical aspects: 1. The evolution of solutions through the design process 2. The interplay among designers 3. The interactions between the designers (students) and their managers (teachers) Case studies of how designers arrived at their solutions revealed that significant insights, which allowed advancement of the designs, were typically gained while building and testing a possible approach, rather than while planning it, and that these insights were often unexpected. This suggests that in order to create new concepts, designers must go beyond the theoretical phase and implement their ideas so they can learn from their experiments to create new ideas and advance the design. The fact that many of the important insights were unexpected suggests that designers have limited ability to plan for insight discovery. Therefore, it can be challenging for designers to justify their actions and use of resources, before they actually build and test. In several instances, the designers gained important insights while they built and tested ideas despite advice from their teachers (i.e. managers) or

5


experts not to build or test (based on the preconception that the outcome was known a priori, and therefore such activity would be wasteful). Hence, if managers are not convinced by the merits of an idea, and successfully prevent designers from building and testing it, they block the designers from gaining insights necessary to advance the design. In such cases, managers block the use of resources for fear of wasting time and money. Indirectly, however, they block innovation and accomplish the opposite of what they intend. Following the methodology suggested for building theory from case study research (Eisenhardt, 1989), the engineering design process management model shown in Figure 1 was devised. This model provides a theoretical explanation for the hypotheses generated through case study research and interviews.

Unlike other models from innovation management or

engineering design, it incorporates the actions of both designers and managers. The model is therefore expected to help each side to better understand the other side's behavior, which should make both managers and designers less ignorant.

6


RE-PUN

r

—

INSIGHTS •

-

-

-

-

;

i

H PLAN )-7E| EXECUTE)-* SYNTHESIZE) < — i

REHASH

E

-

WPRO

:ENSO

cc

WISH-

LU

REWORK

^•SOLUTION

—' '-

REVISE RE-PLAN

Figure 1: Proposed "Unified Innovation Process Model for Engineering Designers and Managers" depicting the kernel of the design process. It shows where designers gain the insights to advance a design and where reviewers intercept the design process at the censor and approver gates.

In the model, the different steps of the design process have been abstracted to three universal activities, which occur both sequentially and iteratively. These activities are recursive and can be found anywhere from the macro level of the project as a whole, to the micro level of performing a specific task. It therefore applies universally to design processes with time constants ranging from a few seconds to several months or even years. Hence, these activities represent a fractal representation of the design process. The model represents how the output of the various activities is evaluated and fed back into the system for iteration, or moved into subsequent process activities.

It reflects the observation that most insights that

advance the design process are gained when designers 'do' (i.e. execute or synthesize) design rather than when they 'debate' (i.e. plan) design. In addition to providing an abstracted view of the design process, the model

7


specifically accounts for the interference of management with the design process. Managers or other outside reviewers can intercept the design process at two decision points: a) at the end of the design process when they approve or reject a proposed solution, and b) between the plan and execute activities when they review and possibly censor the planned approach to creating the design. The model therefore provides a theoretical explanation for the findings from the case studies. These findings are: 1. Designers must move from the 'plan' to the 'execute' step rapidly and frequently in order to maximize the probability of gaining the insights that enable the creation of new concepts and innovation. 2. Managers or other outside reviewers, such as experts, can stifle innovation by censoring ideas after the 'plan' activity, and before the 'execute' or 'synthesize' activity. By doing so, the potential to discover insights is reduced or eliminated. The contribution of the 'Unified Innovation Process Model for Engineering Designers and Managers' is in synthesizing the perspectives and duties of engineering designers and managers. A comparison with the affordances of prevalent models for the process of new concept development indicates that the synthesis achieved by this model is more comprehensive. It can therefore serve as a guide for engineering designers and managers so that they better understand each other.

8

The model is also an


instrumentation map for design researchers.

They can utilize it to

determine observable transition points and feedback pathways for design process measurements. The specifications in the ontology provide distinct definitions of each activity and pathway to aid their efforts. 1.3.

Outline of Thesis

The research described in this thesis is based on evidence and data collected in an engineering design curriculum. The thesis consists of four major sections: 1) introductory materials, 2) hypotheses generation and model development, 3) hypotheses testing through quantitative analysis, and 4) discussion and conclusion. The thesis begins with an explanation of how design thinking is a suitable approach to creating innovation. Chapter 2 provides an overview of the current understanding and models of design and innovation as seen from the engineering design and the innovation management points of view. This overview shows the gap between the two different points of view and reveals the need for research that unifies them. Chapter 3 describes the research methodology. It includes a description of the curriculum in which the research was performed, and the methodology, which was used for the investigation from the design and management perspectives. The chapter also provides an overview of the data streams used to generate and test the hypotheses. It concludes with a description of the analysis

g


procedure and explains why the procedure is suitable to realize the research goal. Case study and interview data are presented and analyzed in chapters 4 and 5 to generate the hypotheses that are the core contribution of this research. Following the hypothesis generation, a theoretical explanation for the findings is provided in chapter 6. The engineering design process management model presented in this chapter is the outcome of the effort to build theory from case study research (Eisenhardt, 1989). The model is described with an ontology that specifies all parts of the model and demonstrates its internal consistency.

In chapter 7, the hypotheses

generated by this research are tested quantitatively. The thesis ends with discussion and conclusion chapters. The discussion evaluates the approach taken, describes the resulting limitations, and provides suggestions for future research. In the conclusion, suggestions are provided for how the findings may impact the practice and management of design and innovation.

10


2. Literature Overview The need for innovation and the view that designers and managers can threaten the creation of innovation were described in the introduction. This chapter explains how design thinking is a possible way to achieve the desired innovation and identifies gaps in the research to date. It begins with a set of working definitions that describe what part of innovation is under study, what is meant by engineering, design, engineering design, and design thinking. Based on these definitions, it is shown how design thinking creates the desired innovation and why managers must understand the design process.

A review of the

engineering design and innovation management literature reveals the gap between the two disciplines that this research aims to fill. 2.1.

Design Thinking to Achieve Innovation

The goal of this research can be broadly defined as aiming to increase innovation. Innovation is a) "the act of introducing something new" or b) "something newly introduced" ("The American Heritage® Dictionary of the English Language," 2000). In other words, innovation is the motor of progress for society as new ways compete with old ways and (if more desirable) replace the old ways in a process described as "creative destruction" (Schumpeter, 1994). Such innovation occurs in all areas of life, especially in the areas of technology, economics, and sociology.

11

A Unified Innovation Process Model for Engineering Designers and Managers This research is restricted to innovation for the purpose of achieving growth of market or profitability in a business context.

Three types of

innovation occur in this context: Innovation of a) business models, b) logistics and operations, and c) products, services and markets1 (Pohle & Chapman, 2006). All three types of innovation begin with a wish and if successful, end with an implemented solution that fulfills this wish. Although there is no consensus among scholars on when the innovation process ends and though many scholars require market success to consider a new concept an innovation, all scholars consider the formulation of an approach to satisfy the wish and a demonstration of the approach's feasibility an essential part of the innovation process. This part of the innovation process is often called the "Fuzzy Front End" (Kim & Wilemon, 2002; Reinertsen, 1999) or "Front End of Innovation" (FEI) (Koen, etal., 2001).

In the FEI phase of the innovation process, new ideas to satisfy a wish are generated. The output of this phase is new concepts, which are refined for commercialization in the formal, well-structured and sequential "New Product and Process Development" (NPPD) phase. Koen et al. (2001) summarize the differences between the two phases as follows: 1

Innovation types defined (Pohle & Chapman, 2006): a) Business model - Innovation in the structure and/or financial model of the business. b) Operational - Innovation that improves the effectiveness and efficiency of core processes and functions. c) Products/services/markets - Innovation applied to products or services or "go-tomarket" activities.

12


Table 1: Differences between the Front End of Innovation and the New Product & Process Development Process (Koen, et al., 2001)

Nature of Work

Commercialization Date Funding

Revenue Expectation

Activity

Front End of Innovation (FE!) Experimental, often chaotic. Difficult to plan Eureka moments. Unpredictable.

New Product & Process Development (NPPD) Structured, disciplined and goal-oriented with a project plan. Definable.

Variable. In the beginning phases, many projects may be "bootlegged," while others will need funding to proceed. Often uncertain. Sometimes done with a great deal of speculation.

Budgeted.

Both individual and team in areas to minimize risk and optimize potential.

Believable and with increasing certainty, analysis and documentation as the product release date gets closer. Multi-functional product and/or process development team.

The differences between the two phases suggest that a distinctly different approach, skill-set and mindset are required to succeed in each phase. The development of new concepts, by definition, requires entry into unknown territory. Drawing on nautical navigation as an analogy, NPPD seeks to navigate to a defined coordinate around known obstacles whereas new concept development is comparable to sailing through unmapped territory; the destination is not known and the laws of nature and discoveries made along the way determine the course. Koen et al. (2001) state that "considerable literature exists on best practices for the

13


start of the NPPD process as well as within it" while the FEI "presents one of the greatest opportunities for improving the overall innovation process." This research aims at understanding how the FEI can be improved. It analyzes how new concepts are developed from idea generation to proof of concept prototypes, the process of 'Design Thinking', and how management affects this process. Design thinking has evolved from 'Engineering Design'. Traditionally, the process of creating new concepts by way of generating new ideas and demonstrating their feasibility has been considered the process of engineering design. Sheppard (2003) characterizes the work of engineers as to "scope, generate, evaluate, and realize ideas". This definition adequately describes the work of engineers but it equally characterizes the work of a marketing person, who implements a new sales method after evaluation among alternatives generated in a brainstorm. Furthermore, "design problems reflect the fact that the designer has a client (or customer) who, in turn, has in mind a set of users (or customers) for whose benefit the design artifact is being developed" (Dym, Agogino, Eris, Frey, & Leifer, 2005). The marketing person described above developed the new sales method with two clients in mind: a) the customer who is expected to buy more and b) the business owner who is expected to have a larger income. So is she a marketing engineer, a marketing designer, or an engineering designer?

She is a 'design thinker' because the

underlying cognitive thread for both endeavors is design thinking.


Absent any comprehensive definition of design thinking, the following definition of engineering design (Dym, et al., 2005) can serve as a suitable definition of design thinking: Design Thinking "is a systematic, intelligent process in which designers generate, evaluate, and specify concepts for devices, systems, or processes whose form and function achieve clients' objectives or users' needs while satisfying a specified set of constraints." The iterative design thinking process, which has been popularized by the design consultancy I DEO, one of the world's most innovative companies (Nussbaum, Berner, & Brady, 2005), can be summarized as shown in Figure 2, which is adapted from Stanford University's Design Group:

(RE)DEFINE THE PROBLEM DESIGN NEVER ENDS

TEST LEARN

PROTOTYPE BUILD

NEEDFINDING AND BENCHMARKING UNDERSTAND THE USERS. DESIGN SPACE

BRAINSTORM IDEATE

Figure 2: Design Thinking summarized: The iterative process of needfinding & benchmarking, brainstorming, prototyping and testing

15


This summary conveys that design thinking is an understood methodology although it is unstructured in comparison to downstream activities. In fact, one can argue that it is the approach taken naturally by anyone with a problem that cannot be satisfied by current solutions but requires a novel alternative.

Design thinking is the systematic iterative process of

creating and testing new concepts for solution exploration. It is the natural method to navigate unknown waters, to find and push the boundaries of the possible and to create innovation. It is applicable in engineering to create a man-made material with new properties and in management to devise an incentive system that rewards creative thinking. Design thinking, as described here, is equivalent to design as seen in the context of engineering design or business design.

It is important to

differentiate between design in the context of design thinking, where it refers to the iterative process of creating new concepts, and design in the context of industrial or artistic design, where it refers to aesthetic form giving. For simplicity, the term design will be used henceforth to reference design thinking. 2.2.

Gap between Designers and Managers

In a world that depends on new solutions for survival and advancement, it is vital to understand how new concepts that can lead to innovation are designed and how to manage the process of new concept design.

16


However, designers and managers see the design process in drastically different ways as summarized graphically in Figure 3. Designers view the design process as an iterative learning process, which begins with a problem and ends with a new concept. Managers, by contrast, view the design process as a linear decision process, which begins with new concepts and ends with market success.

DESIGNER VIEW (REDEFINE THE PROBLEM

TEST

PROTOTYPE

NEEDF1NDINGAND BENCHMARKING

BRAINSTORM

MANAGER VIEW Idea generation Idea acceptance Idea realisation

Figure 3: Comparison of typical views of design process held by designers vs. managers - designers see an iterative learning process while managers see a linear filtering process (adapted from Stanford Design Group and Thorn (1980)

The following sections provide an overview of the current perspectives on the design process from the engineering design and innovation management points of view.

17


2.2.1. Engineering Design Point-of-View A review of the literature on design shows that research in the area of engineering design is mostly restricted to the process of selecting and refining technical solutions to fulfill an identified client need. Only recently, attention is devoted to how the insights, which drive the process are gained, and no attention is devoted to how management or its decisions affect the work of designers. Three popular models are introduced below as examples of how engineering design researchers and practitioners understand the design process.

1

18


c

Task Market, company, economy

)

T

Plan and clarify the task: Analyse the market and the company situation Find and select product ideas Formulate a product proposal Clarify the task Elaborate a requirements list

Requirements list (Design specification)

Develop the principle solution: Identify essential problems Establish function structures Search for working principles and working structures Combine and firm up into concept variants Evaluate against technical and economic criteria

Concept (Principle Solution)

Develop the construction structure: Preliminary form design, material selection and calculation Select best preliminary layouts Refine and improve layouts Evaluate against technical and economic criteria

Preliminary Layout

Define the construction structure: Eliminate weak spots Check for errors, disturbing influences and minimum costs Prepare the preliminary parts list and production and assembly documents

Definitive Layout

Prepare production and operating documents: Elaborate detail drawings and parts lists Complete production, assembly, transport and operating instructions Check all documents

Product documentation

< (

Solution

>

i

J

Figure 4: Pahl & Beitz' Design Process Model accounts mainly for different levels of refinement, vaguely for feedback and learning but not for actors or decisions (Pahl & Beitz, 1996).


Pahl and Beitz (1996) depict the design process as the stepwise process shown in Figure 4. Their model provides a detailed recipe for the flow from initial task to final solution. It emphasizes the stages of refinement and lists the activities required to reach subsequent stages as a list of instructions. The model accounts vaguely for feedback and information gained in the process by mentioning upgrades and improvements and the adaption of the specifications. However, it does not indicate how new information is gained and provides no information on decision points or actors. It also fails to graphically convey the highly iterative nature of the design process, and visually it is too complex to be used by practitioners or management.

Feedback

i i 1

I

Needs

\&-

Analysis of Problem

^/statement \ ^ ^ Y 0 ' problemy^^

Conceptual Design

^ 7 " f t

Selected r g ^ Schemes'/Jr

Embodiment of Schemes

Detailing

WOrklngl Drawings, I

Figure 5: French's Design Process Model accounts for feedback and different levels of detail but not for actors, decisions or how learning occurs (French, 1999).

French (1999) provides the much simpler, but less descriptive, design process model shown in Figure 5. Unlike the previous model, this model shows that the design process is actually triggered by an implicit need rather than an explicit task or order. This model also represents feedback

20


as an element of the design process, differentiates between activities and stages, and applies generically at different levels of detail. However, the model also fails to describe how new insights are gained, does not display the highly iterative nature of design, and does not include decisions or actors.

iOartfylng; Objectives

I

Establishing Functions

t

Setting Requirements

^tprgbferns;

t

Evaluating Alternatives

„ ^

Determining Characteristics

.

f

> ^

Generating Alternatives

i

J

Figure 6: Cross' Design Process Model accounts for different levels of detail, feedback, iteration and decisions but not for actors and how learning occurs (Cross, 2000).

Cross (2000) has presented the design process model shown in Figure 6. Even though more abstract than the previous models, it does clearly and explicitly account for different levels of detail in the design process, the iterative nature of design and the evolution of solutions and problems through feedback between the two.

It is therefore more useful in

21


describing the activities occurring during the FEI phase than the other models, which are more applicable to the NPPD phase.

The model,

however, does not show how the insights that result in feedback are generated and does not include actors or decision points. The three models differ greatly in complexity and level of abstraction. All of them account in some way for the iterative nature of design through feedback.

None of them, however, represent the decision points and

actors. Innovation management has a different view as shown in the next section.

2.2.2. Innovation Management Point-of-View Innovation management researchers and practitioners are concerned with maximizing the innovative output and the efficient use of limited resources. Their focus is therefore on the decisions that have to be made to select the right idea from a pool of ideas. Little attention is given to how these ideas are created and their view is linear rather than circular. Four models of the innovation process that are popular in the innovation management world are provided in this section to illustrate this.

22


3,000 Raw Ideas (unwritten)

Major

*»" KJ

i

Create

Paradigm

Process

t

Product

I

Active Dimension Figure 28: Theory of Adaptive Design Expertise, which suggests that designers succeed by adapting the findings gained by transitioning between practice and theory (Neeley, 2007).

Neeley argues that to succeed, designers must move between "three dimensions, the active, the abstractive, and the adaptive". The active dimension is related to prototyping and testing ideas, the abstractive to learning from the results and combining them with theory, and the adaptive to turning the lessons learned into insights and altering the design accordingly. Brereton (1998) also found in her research on design engineers that they learn most and perform best if they alternate frequently between interaction with hardware and theoretical abstraction. This suggests that experimenting alone is not enough; designers must

92


also spot opportunities for insights and adapt these insights in their design.

4.5.1. Execution Hypothesis: Designers Experimenting and Adapting

Succeed

Through

The four cases demonstrate that the design process is a process of creating opportunities to gain new insights, and of advancing the design by adapting these insights. Those insights are gained through learning by experimenting. Therefore, if designers can increase their learning rate, they will have more insights at their disposal, which they can then assemble into new concepts. The case analyses revealed that most insights were gained during prototyping and testing rather than theoretical deliberations. This finding suggests that it is important for designers to move from debating (or planning) to doing (or executing) in order to maximize learning and discovery. The resulting Execution Hypothesis is: Designers who move from planning to execution most frequently and adaptively will perform best in new concept generation.

93


5. Managers Should Encourage Experimenting The preceding chapter showed that designers gain the insights needed to advance the design during execution. It is therefore important that they move from theoretical debates over the possible merits of an idea to actually constructing and testing it. A second analysis of the cases and the semi-structured interviews with students from the course at the University of St. Gallen, Switzerland, suggest that reviewers and experts can prevent this transition from idea to prototype - thereby blocking the potential for innovation. The following analysis leads to the hypothesis that designers who are given the freedom to try will perform better than those who have to justify their actions to reviewers beforehand. This has important implications for reviewers and managers.

5.1.

Reviewers Often Discourage Experimenting 5.1.1. Case A: Paper Bike 2003/2004 (Designer-Observer)

The design team that constructed the winning paper bike in 2003/2004 discovered during testing that the interface between the axle and the wheel hub provides opportunities for major improvement.

In order to

reduce the weight penalty due to non-paper weight, the designers considered eliminating lubricants and traditional bearings in favor of a simple cardboard-cardboard interface.

Even though some members of

the design team were initially skeptical about this, the designers tested

94

A Unified Innovation Process Model for Engineering Designers and Managers this prior to the race, and found the design to be sufficiently strong for the stresses expected during the race. However, during the review session on the day before the race, the teaching team expressed strong concerns regarding the reliability of the design. One member of the teaching team even urged the designers to redesign the interface before the race, predicting that the design would fail. Although the designers considered this, they trusted their test results and finished the race victoriously with their novel design.

In the epilogue of their report, the designers write: "Lastly, I wish there was a meaningful way to have the design review after the race instead of before. While I understand the need to have a milestone prior to the race to preclude procrastination, there were several concerns expressed about the design and skepticism about whether it would survive the race. Our team specifically worked to push the design envelope with a non-traditional design. We chose not to use bearings or lubricants, but only after several testing the concept. We eliminated much of the frame tubing f to reduce the weight, and had tested the design to ensure it was strong enough. Yet several of the "wishes" from the design review would have pushed us back to a more traditional design, based on the fear of failures during the race. It was pointed out that race conditions were very difficult to duplicate or simulate in testing, so in essence our testing did not prove that the design would work. In the end our bike performed perfectly during the race, even surviving an unplanned "Lawrence Lap". Presenting the design after the race would have given us test results from the race to validate that our design was adequate and sufficient to meet the requirements of the race. Unfortunately it is a "chicken and the egg" scenario, so I do not know if there is a simple way to resolve this." (Bailey, et al., 2003) Had the designers not tested the design before the review, it is likely that the critique by the teaching team, whose members are considered experts and authorities, would have killed this new concept. The associated lost

95

A Unified Innovation Process Model for Engineering Designers and Managers learning opportunity would have impacted not just this team, but many future teams as well as the majority of design teams used the same design during the following years.

5.1.2. Case B: Vehicle Interface for IT Generation 2003/2004 (Designer-Observer) When the designers who worked on the vehicle interface for the ITgeneration decided to build a prototype that would let the driver steer by foot in order to free their hands for typing, the teaching team made it clear that in their eyes, this would be a waste of time.

In an email to the

designers, a member of the teaching team wrote: "/ strongly suggested that you forget about 'proving', with just one weekend of experiments and testing, that foot steering, accelerator and brake control is an easy to learn, intuitive, reliable and safe way of driving a car. And that it will greatly improve the driver's ability to do text messaging while driving. There are so many reasons why you don't want to even think about this driving style as part of your particular project that I won't even try to start listing them..." (Bailey, et al., 2004) However, the designers proceeded with the idea anyway. Even though, as correctly predicted by the teaching team, this idea did not work and it was not used in the final system, the insights gained during testing shaped the final outcome. From the test, the designers learned that the human cognitive ability is the limiting factor to their design and not dexterity. This insight completely changed the design requirements and the team's expectations on the typing speed that could be achieved while driving reasonably safely.

96

The designers would have missed this project-


changing insight if they had abdicated to the teaching team and not tested the idea.

5.1.3. Case C: Convertible Manager-Observer)

Experience

2004/2005

(Project-

The design team that worked on the convertible experience project initially received great help from the carmaker's engineers, who ran several simulations for the team on their CFD computers. simulations takes about one day to complete.

Each of these

However, when the

designers asked the company's engineers to run a simulation on a 'hole in the windshield', they were refused the help because the idea was too outlandish. Only after the designers had successfully shown the merit of their concepHn reality, was the concept given time on the CFD computer. After the final presentation, one engineer from the company stated that "We couldn't have done this", referring to the fact that the organizational make up of the company precludes such a 'crazy' idea from being implemented or even tested.

This indicates that at the company,

reviewers and experts would likely have prevented the idea from being validated

based

on

limited

conventional

wisdom

or

for fear of

embarrassment if it failed. Similarly, when the designers wanted to cut a hole into the windshield of the car, they consulted with various experts for help with the cut. The designers write:

97


)

"The team had researched with countless experts the process of cutting windshield glass, and had been told that it simply wouldn't work. Nonetheless, the team recognized that removal of the windshield would be destructive regardless, so they took the opportunity to attempt a cut. Using a diamond coated cutting disc at 6000 rpm in a Dremel tool, cooled by flowing water from a small pump over the windshield, this imperfect process yielded an entirely usable and clean hole with only a few cracks propagating from the corners of the cut." (Arvizu, et al, 2005)

This shows that even experts may err in knowledge and judgment, and advise against a course of action because they do not understand the goal behind it. Wiley (1998) writes that "novices may outperform experts in conditions in which experts cannot make use of their domain knowledge". She continues saying that "experts can be outperformed by novices when a new task or context runs counter to highly proceduralized behaviors. Experts perform worse than novices when a shift from standard means of representation is required or when a standard response is inappropriate." In experiments, Wiley found also that "domain knowledge can indeed act as a mental set and promote fixation [...] on the incorrect solutions, preventing a broad search of the solution space" (1998). This suggests that experts can inadvertently prevent viable ideas from being tested based on their limited and sometimes erroneous preconceptions. In doing so, they prematurely lay to rest potentially successful new concepts and prevent designers from gaining necessary insights.

98

A Unified Innovation Process Model for Engineering Designers and Managers 5.2.

Reviewers Can Encourage Experimenting as Exemplified by Case D: Task Management Software 2005/2006

The interface for the task management software system designed by a team of management students was inspired by Lego™ pieces.

It is

unlikely that software engineers would use a hardware toy to prototype an interface or that managers would consider representing attributes of a business task with toy pieces. However, in this case, the designers were encouraged to venture out into uncharted territory and to try unproven ideas with atypical tools in order to create new concepts. The following interview excerpts with student designers show the importance of being allowed the freedom to try, and even more importantly, to be encouraged to try. Student: "Auch [...], dassman einen Rahmen hatte fur verschiedenen "crazy ideas", es wurde uns gesagt: "Ja macht mal einfach", gerade "the dark horse", "Macht irgendwas, auch wenn es nicht brauchbar ist". Ich glaube, dass man nicht unter Druck steht: "Ihr musst das von Anfang an jetzt so machen" und dass man einen Rahmen fur seine Gedanken hat."

Student: Also that the environment allowed for all the "crazy ideas". We were told: "Yes, just do it", especially "the dark horse", "Just do something even if it is not useful". I believe that therefore you are not under the pressure that "You have to do it this way from the beginning" and that one is given the room for one's own ideas."

Interviewer: "Du wurdest also sagen, Interviewer: So you would say that the die Moglichkeit Fehlerzu machen, possibility to make mistakes has dass es okay ist, hat geholfen." helped? Student: "Ja. Ja, so untypisch (fur die) Student: Yes. Yes, it is so unusual for Uni. Hier musst du nicht immer alles university. Here you always have to auswendig lernen und verstehen und memorize everything and understand immer richtig machen, sonst musst du and always do it right - otherwise you gehen. Und das war jetzt wirklich mal have to leave. And this was finally a course where you can really do what ein Kurs wo du selber machen konntest was du wilst. Klar, es gab you want to. Of course, there was a eine Zielvorgabe, aber das war bei unsgoal given, but that did not mean that we worked too goal focused. We at zumindest nicht so, dass wir zuviel

99

A Unified Innovation Process Model for Engineering Designers and Managers Ziel-fokussiert gearbeitet haben. Wir haben erstmal (einfach) gemacht..."

first simply just did something.

Interviwer: "Einfach mat machen... Wurdest du sagen, das "einfach mat machen" hat auf dieses Ausprobieren ?

Interviewer: This just doing something... Would you say that this "just doing something" had an impact on trying?

Student: "Ja, aufjeden Fall. Basteln und wenn und wenn uns Ideen kamen sind wir gleich in Bastelshops gegangen und haben irgendwas gekauft und habe uns zusammengesetzt und gesehen es geht (zum Beispiel) nicht."

Student: Yes, for sure. Crafting and when we had an idea, we went to the crafts stores right away and bought something and then we put it together and saw it (for example) did not work.

Student Designer B Another student alluded to this as follows: "Wir hatten hatte nicht die starre Zielvorgabe von oben herunter gehabt. „Macht das und das". Nein. Eigenart vom Projekt war, dass wir selbst entwickeln konnten. Dass Ideen uberall aufgekommen sind und gefiltert werden mussten. [...] Warnaturlich Freiheit, dass wir dadurch gelassen das machen konnten, was wir wollten. Und die [Freiheit] war wichtig."

We did not have the fixed target given from the top down as in "you do this and that". No. It was the uniqueness of the project that we could develop on our own. That ideas come from everywhere and had to be filtered. It was important that we had the freedom to do what we wanted to without fear. And this [freedom] was important. Student Designer A

The importance of the reviewers' openness to new ideas and the ability of designers to trust them were described by another, student designer: "Das Verhaltnis Teaching-Team zu den Studenten [war wichtig], we'll dadurch ganz klar kommuniziert wird, dass dujeder Zeit bei ihnen vorbeischauen kannst. Es ist eine Kommunikation da, die relativ klar durchbringt, dass dujeder Zeit vorbeikommen kannst. Zum Beispiel mat bei Barbara ins Buro laufen kannst. Das Teaching-Team erlaubt Losungen fur ein Problem auf den Tisch legen, die noch nicht vollstandig durchdacht sind. [...] Es sagen ja immer alle: "es gibt keine blode

100

The relationship of the teaching team to the students [was important], because through it, it was clearly communicated that you can come round at any time. There is a communication, which gets across relatively clearly that you can come by at any time. For example walk into Barbara's [Note: a member of the teaching team] office. The teaching team allows you to present solutions for a problem, which have not been thought through yet. [...] Everyone always says "there are no dumb

A Unified Innovation Process Model for Engineering Designers and Managers Frage". Aber das [Vertrauen und die Offenheit] schafft wirklich auch den Rahmen, wo du erstmal bereit bist, dass Node rauszulassen. Andernorts machst du es nicht."

questions". But the [trust and openness] really create the environment where you are finally willing to let out the dumb. Elsewhere, you don't do it. Student Designer C

These comments suggest that the designers would not have been as successful if they had operated in the regular framework: under close supervision by reviewers and experts who rely on traditional tools, are constrained by conventional wisdom, and maintain the authority to kill an idea before it is tested. However, they also show that reviewers can have a positive effect by encouraging experimentation and empowering the designers to venture into new territory.

5.3.

Cross-Case Analysis Reveals Pattern

In Cases A, B, and C, the designers succeeded by pursuing approaches that experts and other reviewers had explicitly advised them not to pursue. In several instances, the teaching team and experts were limited by their knowledge

and

experience,

which

led

to

premature

judgments,

constrained the perceivable solution space, and made them wary of new and unproven concepts. The only way to convince the experts in these cases was by demonstrating the functionality in reality. This, however, may not be possible if the reviewers or experts have the authority to stop the designers from executing and testing an idea.

Furthermore, even though reviewers and experts may already know the immediate result of a proposed idea, they cannot imagine the indirect

101

A Unified Innovation Process Model for Engineering Designers and Managers lessons, which can be learned from testing an idea. Therefore, they may have to let designers go down the 'wrong' path for some time to gain the insights that allow for the creation of new concepts. On the other hand, reviewers can help designers by encouraging and empowering them to experiment. The interviews from Case D show that the reviewers had encouraged experimentation and deferred judgment until test results were known. Here, the designers succeeded when they went beyond their traditional toolset and tried something unusual. Thus, reviewers and experts must recognize that designers will only create more standard results if they use only standard tools and practices.

Reviewers and managers must also acknowledge that experimentation with new ideas comes with a lot of failure and that failure should not be perceived as negative.

The students at the University of St. Gallen

especially emphasized this. One student said: Student: "Die einzelnen Prototype/! Student: The individual prototypes and und Paper die wir hatten waren ja oft papers, which we did were often only nur Versuche. Wir hatten die Freiheit, attempts. We had that freedom that dass mat was daneben gehen konnte.things could go wrong sometimes. I Glaube ich sehr wichtig. Ok, vielleichtbelieve that is very important. Ok, nicht alles erreicht, aber man lernt maybe did not accomplish everything davon." but one learns from it. Interviewer: "Fail early and fail often - Interviewer: Fail early and fail often and succeed sooner?" and succeed sooner? Student: "Genau. Kann ich mir Student: Exactly. I cannot let that woanders in Fachern so nicht happen in other courses. In other erlauben. Im anderen Fach im Paper, courses, in a paper, I am afraid that it das vor Angst im anderen Fach, is directly reflected in the grade. schlagt sich das direkt in der Note wieder." Student Designer A 102


In several interviews, the students declared that being given a second chance allowed them to take risks, which they were unable to take in other classes. They argued that in other classes, they have one submission deadline with no feedback beforehand and whatever they turn in seals the grade. Therefore, they play things safe and simply regurgitate what they were told while taking as little risk as possible. In this class, on the other hand, they realized that they would have another chance to make things right and thus could try out ideas, which they were unsure about. The students also commented on the positive attitude of the teaching team towards failure. They explained that in other courses, failures were turned into "burn marks" whereas in this class they were almost celebrated.

Here, a failure counted like a success if it was carefully

analyzed and lessons were learned and insights gained from it. They also felt that the teaching team understood that failures were a necessary part of operating at the cutting edge of new discovery and not the result of a lack of planning or thinking.

It is therefore important that reviewers

appreciate failures as possibly helpful to the advancement of the design, and that they communicate this to the designers. Finally, reviewers must consider the motivational impact of their feedback on designers in addition to its effect on the ability to execute. One student responded to the question about significant events as follows in two separate questionnaires:

103

A Unified Innovation Process Model for Engineering Designers and Managers "We get excited when we get ideas. Then they get shot down and we lose motivation for a week." "Getting bashed by the TTeam 3-4 weeks in a row was bad for team morale. Then it was just trying to get along after that." These comments demonstrate that by killing ideas, reviewers not only prevent designers from gaining insights but also risk the motivation of the designers. To overcome many of these issues, Parnas and Weiss (1985) recommend that reviewers should "make positive assertions about the design rather than simply [...] point out defects" and that "the designers pose the questions to the reviewers, rather than vice versa". In their studies of design research reviews at the Navy, they have found: "Reviewers are often asked to examine issues beyond their competence. They may be specialists in one aspect of the system, but they are asked to review the entire system." This happened in several instances in the cases described and resulted in erroneous judgments by the reviewers. The focus on review of the system rather than a specific section occurred by choice of the reviewers and by the way the review was arranged. Parnas and Weiss (1985) also found that: "Often the wrong people are present. People who are mainly interested in learning about the status of the project, or who are interested in learning about the purpose of the system and may turn the review into a tutorial." Observations indicate that this problem also occurs regularly during design reviews in 310 (especially during reviews of high performing design teams who work on exciting projects).

104


5.4.

Censorship Hypothesis: Reviewers Should Encourage Experimentation rather than Censor Ideas

Managers, experts and reviewers should encourage the shift from planning to execution, if designers gain most insights that advance the design through experimenting. However, in academia and industry alike, regularly scheduled review sessions, gates and milestones are designed to keep projects on schedule, feasible and within budget, not to gate learning. At these points, the project ideas and concepts are scrutinized and many unproven ideas, which are risky in the eye of the reviewer, are killed. Therefore, instead of accelerating the design process, reviewers impede it by acting as censors. They bar the designer from creating learning opportunities that hold the potential for discovery and insight. Wheelwright and Clark (1992) have shown that "autonomous or tiger teams" are the most effective vehicle for developing new concepts. They suggest that motivation through ownership is an important reason for the superior performance of these teams.

The lack of involvement from

outside reviewers in those teams may be another important reason. These teams can simply try out ideas and learn as they wish without requiring approval before shifting from planning to execution. This is stated in the Censorship Hypothesis as follows: Designers who can move freely from planning to execution will outperform those who must pass through approval gates.

105


6. Unified Innovation Process Model for Engineering Designers and Managers At this point two hypotheses have been formulated.

The Execution

Hypothesis postulates that designers gain the insights needed to create new concepts through learning by doing. The Censorship Hypothesis suggests that to increase learning by doing, reviewers should give designers more freedom to try out their ideas. These two hypotheses are derived from the evidence presented. However, to build credible theory from this evidence, a logical explanation is required. The unified innovation process model for engineering designers and managers (henceforth 'model') shown in Figure 29 was developed to further the logical expression of the findings. It depicts the design process and explains how its participants' actions affect it. The model represents the kernel of the design process and shows where reviewers interrupt its flow. It provides a theoretical and logical explanation for the findings. The model can be used as a communication tool by designers and managers, and as an instrumentation map by design researchers.

106


RE-PLAN

o

REWORK LEARNING

WISH-

a. "

Q

|EXECUTE)H[SYNTHESIZE|-^•SOLUTION PLAN)--XI REHASH

REVISE RE-PLAN

Figure 29: 'Unified Innovation Process Model for Engineering Designers and Managers' depicting the kernel of the design process and where reviewers interrupt its flow.

The following sections describe the generic nature of the model, the feedback pathways and decisions points, and an ontology for the model. Concepts are illustrated using examples based on the design of a bond to fasten two parts together. The sections show that the model provides a logical explanation for the hypotheses developed previously. Hence, the model aids the prior case studies in building credible theory on how designers succeed and on how reviewers can stifle innovation. 6.1.

Activity Functions

At the core of the model are three activity functions: 'Plan', 'Execute', and 'Synthesize' shown in Figure 30. All phases of the design process, and the activities they entail, can be abstracted to these three activities. The entire string represents the design process from start to finish - going from a 'Wish' (some form of prompt, need, or problem) to a 'Solution'.

107


WISH-

PLAN)-

1 EXECUTE)-fsYNTHESlZE)

••SOLUTION

Figure 30: Activity function string "Plan", "Execute", and "Synthesize" which constitute the core of the model.

6.1.1. Micro (Phase) Level At the micro level, the three activity functions, Plan, Execute, and Synthesize occur repetitively during every phase of the design process. The following table and subsections demonstrate their applicability in the needfinding, brainstorming, prototyping and testing phases.

108


Table 9: Examples of actions performed during each activity at the micro (phase) level to show the universal applicability of the model at this level.

Phase

j r §si1

y £1

X^YPA

PLAISl)

EXECUTE)

SYNTHESIZE)

Who to observe? What to observe?

Observe and collect data

Develop PoV & define need or problem

What is a possible solution?

Articulate idea

Synthesize own ideas with ideas of others

How to manufacture? What tools to use?

Manufacture

Assemble with other parts

What to test? How to test?

Perform test

Analyze result & determine if wish is satisfied

#

Designers begin a design process by searching for a need that they will address with a solution. Typically, this is done through observation of users interacting with an existing product or system. In this needfinding phase, designers begin with the planning activity, during which they identify where they want to observe users and how to best record their

109


observations. Then, during execution, the designers observe the users and collect data. Finally, this data is used during synthesis to develop a point of view and to define the need and actual problem. Designers then continue the design process by brainstorming possible solutions and approaches based on the need discovered previously. During this phase, they once again go through planning, execution and synthesis. In a typical brainstorming session, a designer will imagine an idea, which is an act of planning. By subsequently articulating the idea to the group, the designer is executing the plan. Finally, the group will use this idea and synthesize it with previously articulated ideas. The result is then used as the basis to plan their next ideas, which results in continued iterations of the activity string. A typical task facing a designer during the prototyping phase is to decide on a fastening method between two physical parts. A designer will enter the planning activity of this task with the goal of fastening two parts together.

During planning, the designer explores feasible fastening

methods, and selects one or two that are the most appropriate for the application.

In execution, those methods are implemented by, for

example, drilling holes, cutting threads and turning screws or by applying glue and clamping the parts together.

Synthesis then represents, for

example, the act of inserting the two fastened parts into the larger system or performing a tensile stress test to determine the durability of the bond.

110


(Note: both of these acts become execution in another activity string that represents the testing process.) The last phase in a design process is testing. During testing, designers repeat the three activities as follows: They first plan to determine what question needs to be answered and what test would answer this question. In execution, the actual test is performed, with the help of test subjects or specimens, and the resultant data is recorded. Finally, during synthesis, designers analyze their data and compare the results with their hypotheses.

6.1.2. Macro (Project) Level At the macro (project) level, planning is associated with needfinding, idea generation, brainstorming, and the plotting of an approach. Going into this stage, designers have a rough idea of what they want, and coming out of it, they have a plan to tackle the problem with their know-how. The plan usually consists of one qr more concrete ideas, a division of labor, and sometimes includes contingency planning in case of failure.

111


Figure 31: Activities and how they map to design process phases at the macro (project) level.

Once armed with a plan, and management consent if needed, designers begin to execute. As its name implies, execution is where the work gets _ done. Drawings are crafted, and prototypes are built, modeled, machined, sculpted or coded. 'Getting real' is the central theme for the execution function; this is where designers channel their ideas from their heads into their hands, birthing them into the world and making them testable. Last in the design process chain is the synthesis activity. Synthesis is the gathering of the fruits from execution to form the output solution. Synthesis occurs in many different ways and typically includes assembly of the parts into a whole system and testing. Given the iterative nature of design, this string is traversed repeatedly, the activities always occur in this order, and feedback occurs on the pathways described in sections 6.3 and 6.4.

112


6.1.3. Recursion of Activity Function String The foregoing examples illustrate that the three-activity string (Plan, Execute, Synthesize) is a universal kernel of the design process. Design activity during all phases can be abstracted to these three fundamental steps. The examples also show that activity strings are actually nested within one another; for every activity at one level, there is one or more entire activity string included at lower levels in a recursive pattern, as illustrated in Figure 32. The time constant of one traversal through the entire activity string can therefore range from a few seconds for the generation of an idea during brainstorming to multiple years in the case of designing and building a new aircraft.

PLAN > | EXECUTEyjSYNTHES^

Figure 32: Recursive nature of the activity function string.

113


6.2.

Design as Insight Assembly Process

Designers create new concepts through consideration of new knowledge or new combinations of existing knowledge. However, to reach past the known or obvious, designers need at least one new useful insight. Designers must therefore maximize the probability of gaining the necessary insight(s), to maximize the probability for success. Insights are new knowledge that is gained through study or experience, and adapted to advance the design.

The case and interview data

presented in Chapter 4 show that most insights are discovered while designers try an idea rather than debate it. This occurs during the execute and synthesize activities rather than during the plan activity. To reflect this, the model is enhanced as shown in Figure 33.

INSIOHTS WISH-

PLAN

>

1M

EXECUTE

SYNTHESIZE:

SOLUTION

Figure 33: Insights that advance the design are gained in execute and synthesize activities.

6.3.

Designer-Initiated Feedback Pathways

Design is rarely a linear process. In fact, one might argue that design is never linear, but rather helical — 'all design is redesign' (Fruchter &

114


Demian, 2005; Girczyc & Carlson, 1993).

Iteration and feedback are

important because they allow designers to apply their insights to advance the design. Hence, the model is further enhanced to express the circular nature of design by means of feedback pathways. The resulting model is similar to the framework proposed by Park and Cutkosky (1999). Figure 34 shows the designer-initiated feedback pathways that are observable. Even though other feedback pathways probably exist, they are not externally observable and are therefore not considered here. The qualifier 'designer-initiated' is used to differentiate them from the 'reviewerinitiated' feedback pathways introduced later in this chapter.

Each

feedback pathway is described below. RE-PLAN REWORK INSIGHTS

WISH-

PLAN ) — | EXECUTE^SYNTHESIZ^

SOLUTION

REVISE

Figure 34: Observable designer-initiated feedback pathways.

6.3.1. Re-Plan Largest of the three feedback pathways, the 're-plan' pathway extends from the synthesis stage to the input of the planning phase. Re-planning signifies the action taken by designers when the results gained during

115


synthesis are so different from what was expected that designers must return to planning to change their approach. This pathway is engaged when the problems in synthesis are large in scope and require a reconsideration of 'everything'. An example for this at the macro level is when the project aim changes mid-development-cycle. Similarly, this happens at the micro level, when for example a 'wild' idea, such as relying on gravity and friction as a fastening method, was followed but then failed in synthesis, and no contingency plans had been made beforehand.

In these cases, new knowledge is brought back to the

planning phase and the design process restarts. 6.3.2. Revise The 'revise' pathway, like the 're-plan' pathway, reads from the synthesis stage. Instead of feeding into the planning phase, however, it modifies the execution activity. Revision occurs when the results of synthesis are not sufficient to qualify as a solution, but they are not so far off that the overall approach must be changed. Examples for this can be found at the macro level: if a 'wild' idea has failed, but a contingency plan was made, the execution and synthesis simply need to be repeated using the alternative approach. In a similar fashion, this happens at the micro level if, for example, during prototyping, the adhesive used to fasten two components heats up and dissolves during normal operation of the system. In this case, the specifications for


the adhesive are amended, but the overall plan does not need to change. The execution must simply be repeated with a different adhesive that is designed for higher operating temperatures. 6.3.3. Rework Most frequently engaged is the 'rework' pathway, which serves as a feedback mechanism to the execution activity only.

Reworking is the

process of re-executing until the output is satisfactory enough to advance to synthesis. This feedback pathway is the most frequently traveled due to the highly unpredictable nature of activities that occur inside the execution activity. Reworking is the repetition of the execution phase with slightly altered input. Again referencing the fastening example, reworking occurs when execution fails to produce acceptable output. If the bond is broken when the glue is partially set, the gluing will need to be reworked. 6.4.

Reviewer-Initiated Feedback Pathways and Gates

Reviewers intercept the design process at two gate points: after the plan activity, when they give permission to execute the proposed approach, and at the end of the design process, when they accept the proposed design as the solution to their wish or require a redesign. These reviewers are external to the design team. They are managers, advisors, experts, coaches, teachers, and clients. At these two gate points, any of them can initiate two additional feedback pathways as shown in Figure 35.

117


RE-PLAN K

o CO

111

REWORK

INSIGHTS §

WISH

SOLUTION

Figure 35: Reviewers (e.g. managers, experts or instructors) intercept the design process at two gate points and initiate two additional feedback pathways.

6.4.1. Approver and Re-Plan Feedback Pathway The largest reviewer-initiated feedback pathway is that created by the approver. The approver judges whether the output of the design process satisfies the original wish. If the approver is satisfied by the proposed solution, then the design process is finished and the proposed solution becomes the solution. However, if the approver is not satisfied with the solution, then the 'Re-Plan' feedback pathway is activated and the designers have to return to the plan activity and reconsider their approach.

Continuing on the adhesive selection example, the 'approver' could be the project manager or customer, who would give the specification for minimum bond strength. This person can either approve the method and release the part based on the results of the gluing process, or can send the designers back to the planning phase if the outcome does not meet his

118


or her expectations, which are frequently not made completely explicit at the start of the design process. Regardless of the amount of feedback the approver provides when sending the designers back to the plan activity, the designers return to the plan activity with more experience. The traversal of the execute and synthesize activities allowed them to gain insights, which they can apply in their redesign efforts. 6.4.2. Censor and Rehash Feedback Pathway On the other hand, designers are deprived of the opportunity to gain insights when the 'Rehash' feedback pathway is activated by a 'Censor'. Censors are people with the authority or influence to prevent the design team from moving certain ideas to execution. They make decisions and recommendations based on their judgment of the proposed plan. Undoubtedly, these censors want to help the designers by ensuring that resources are only spent on economically or technologically feasible ideas. However, they restrict the ability of the designers to test novel ideas and to make the discoveries that lead to the necessary insights. When an idea is censored, the designers will rehash the plan activity. In this case, the designers will go through the planning process again but without significant new information. It is therefore unlikely that the new plan will be significantly better.

119

A Unified Innovation Process Model for Engineering Designers and Managers Censors can only avoid this problem if they provide the designers with detailed feedback and information, which will result in a significantly improved plan. However, as was shown in Cases A, B, and C in Chapter 5, reviewers can also err. In particular, if they fail to recognize that an idea falls outside the bounds of their own limited experience and expertise, or do not see that their expertise acts as a constraining mental set, then they risk killing potentially viable ideas before they can be proven. In the worst case, censors hold designers hostage in a planning loop by forcing them to rehash the plan activity without allowing for the development of new insights.

They stifle the possibility for discovery,

insight, project progress and innovation. In the process, they can also damage designer morale. Returning to the example of bonding two parts: One can imagine a scenario where an aircraft manufacturer asks designers to devise methods to lighten a fuselage, in addition to making it less likely to fail in fatigue and less expensive to produce. The designers might think of the rivets that hold together sections of the fuselage as being a potential source for improvement: they are heavy, act as stress concentrators, and take a long time to fasten in production. The designers propose to weld together the sections of the fuselage as a way of meeting the given requirements. However, a senior engineer tells them that the aluminum used is too thin to allow for a uniform and strong weld that would hold up


in flight. The reason makes sense to the designers, they go back to brainstorming, and shortly thereafter propose chemical adhesives as a bonding method. To the project manager, who has outdated knowledge on chemical adhesives, the idea seems crazy, and he tells the designers to go back and work on a different way to achieve the project goal. The designers may abandon the idea now, because the project manager has the authority to halt work on it, or because a senior engineer asserts influence by way of expert status or reputation. As a result, a potentially highly innovative idea that could have resulted in enormous profits is killed. In this realistic scenario, a potentially successful idea is discarded without any testing or data, and, in the process, the designers' motivation fades. If this occurs frequently, the designers are likely to stop proposing new, let alone 'wild', ideas altogether. The censor gate and rehash feedback pathway are the final piece of the model. Even though self-censorship by designers certainly occurs and is an important issue, it is not generally externally observable. The only way to overcome self-censorship is by making designers understand that they must transition to the execute activity to gain insights and by encouraging this transition. 6.5.

Ontology for Model

The foregoing description of the model shows that it provides a logical explanation for the previously developed hypotheses based on the case

121


and interview data. The model explains that designers should transition from planning to execution so they can gain new insights and it shows how reviewers can prevent this transition when they act as censors. In order to strengthen the model, an ontology was created.

This

specification of a conceptualization (Gruber, 1995) demonstrates the internal consistency of the model and describes the unique characteristics of every component of the model. The model is a conceptualization of the design process that represents the activities of designers and managers.

All actors and functions are

specified using axioms and logical rules in the ontology. The following Tables show the ontology in pseudo-code form.

122

Approve

Individual Individual Individual Individual

Actors

;• •; ; "

.

123

IF Designer Estimates (SolutionPlan AND OperationsPlan AND ComponentPlan) will combine to PotentialSolution, THEN Plan COMPLETE IF Censor Estimates (SolutionPlan AND OperationsPlan AND ComponentPlan) will combine to PotentialSolution, THEN Execute STARTS IF Censor Estimates (SolutionPlan AND OperationsPlan AND ComponentPlan) will NOT combine to PotentialSolution, THEN return to Plan via Rehash ELSE Execute STARTS IF Designer Estimates (Component does NOT Satisfy ComponentPlan) AND (Operations do NOT Satisfy OperationsPlan), THEN process returns to Execute via Re-Work ELSE Execute is COMPLETE AND Synthesize STARTS IF Designer Estimates Assembly Satisfies Wish, THEN Synthesize is COMPLETE AND Assembly IS PotentialSolution IF Designer Estimates (Assembly does NOT Satisfy Wish AND Component does NOT Satisfy ComponentPlan), THEN return to Execute via Revise ELSE return to Plan via Re-Plan IF Approver Estimates PotentialSolution Satisfies Wish, THEN PotentialSolution IS Solution AND Process is COMPLETE ELSE return to Plan via Re-Plan

Rules

who has Wish developing PotentialSolution who ends design process by approving PotentialSolution as Solution - typically same as Customer who can reject planned approach due to authority - either by hierarchical or expert authority

Table 11: Ontology of model - Rules

Synthesize

Execute

Censor

Plan

Customer Designer Approver Censor

_

Table 10: Ontology of model - Actors


Functions

124

f(x) -> (y): Function uses x as input to create y as output ?: Input or output is optional for function Plan(Wish, Customer, ?lnsight, Designer) -> (SolutionPlan, ComponentPlan, OperationsPlan, ?lnsight) Mentally formulating a path to a solution Censor(?Censor, OperationsPlan, ComponentPlan, SolutionPlan) -> (?OperationsPlan, ?ComponentPlan, ?SolutionPlan, ?lnsight) Evaluating the proposed approach Execute(OperationsPlan, ComponentPlan, ?SolutionPlan, ?lnsight, Designer) -> (Component, ?lnsight) Giving embodiment to component Synthesize(Components, SolutionPlan, OperationsPlan, Wish, ?lnsight, Designer) -> (Assembly, ?PotentialSolution, ?lnsight) Assembling components to satisfy wish Approve(PotentialSolution, Wish, Approver) -> (?Solution, ?lnsight) Evaluating the proposed solution

Table 12: Ontology of model - Functions


(Design) Process New concept Wish Insight Rehash Re-Plan Revise Rework Description Operation OperationsPlan Component ComponentPlan Assembly PotentialSolution Solution SolutionPlan (To) Satisfy (To) Estimate

Axioms Series of steps to create a new concept that Satisfies a Wish A product or process that has not been seen before A desire or hope for something (to happen) (Ref: Oxford American Dictionary) New knowledge gained by Designer through study or experience To put into new form without new Insight To review and change approach based on new Insight To alter details of component based on new Insight To repeat process with new Insight to accomplish originally Intended component Representation of something or its characteristics Specific action Description of Operations that combine to design process Piece of Solution Description of Component Synthesis of Components Assembly that Designer estimates to satisfy Wish PotentialSolution that Approver estimates to satisfy Wish Description of vision of PotentialSolution To fulfill expectations To approximately judge

Table 13: Ontology of model - Axioms


125


The ontology shows that insights can be created by any of the five functions (Plan, Censor, Execute, Synthesize, Approve). However, the 1 analysis presented in Chapter 4 showed that designers gain most insights during execution and synthesis and not during planning. It is therefore important that designers transition promptly from planning. Furthermore, since insights generated by these functions can be used as an input to any of the three activity functions (Plan, Execute, Synthesize), designers can apply more insights if they repeat these activity functions more often. This supports the Execution Hypothesis. The ontology also shows that in the absence of a censor, there are no systemic barriers that can prevent the transition from planning to execution.

This supports the Censorship Hypothesis that without

censorship, designers can freely transition to execution and test their ideas. Combining these results, the ontology makes it clear that if a censor rejects an idea, the designers are redirected to the plan function and have little opportunity to create insights themselves. In this case, the censor must fill this gap and provide the designers with insights that will allow them to create an improved plan.

126


7. Quantitative Results The model and ontology presented in chapter 6 provide an explanation for the findings from Phase 1 of this research. They support the Execution Hypothesis that designers who move from planning to execution more frequently will create more opportunities to gain insights and therefore perform better than those who spend more time planning and debating ideas. They also support the Censorship Hypothesis that reviewers who censor ideas before they are tested can prevent designers from gaining necessary insights and thereby reduce performance. These hypotheses are tested during Phase 2 of this research.

In this phase, the data

collected from Study 7 performed during academic year 2007/2008 is analyzed quantitatively. The results are described in this chapter. They provide further support of the hypotheses. 7.1.

Findings Concerning Execution Hypothesis

If the Execution Hypothesis is correct, one should find a positive correlation between the activities undertaken by designers, especially prototyping, and their performance. The Execution Hypothesis was thus tested by comparing the count of each kind of design activity (determined through coding the design reports) with the outcome performance (measured by external judges). Using linear regression analysis, it was found that the number of field observations reported by the designers correlates positively (Beta=0.531) and significantly (Sig. = 91%, R2 = 0.28)

127


with output performance. Field Observations are defined in the reportcoding scheme as "User field observations, people-centered needfinding by observing actual usage in the field including surveys." The number of field observations is therefore an indicator of how many times the design team not only thought about users, but also entered the field and observed them. A field observation is therefore an act of execution and marks a transition from planning to execution. The positive correlation between the field observation count and outcome performance supports the hypothesis that designers learn through execution.

Number of "Field Observations" Documented by Design Team vs. Output Performance

X

" R1 - 0.282

^

^

1a

X

3

^

-

^

X

E

^-""""^ •S

I

X

" ....) )C

1

%

4

S

Number of "Field Observations" Described In Desfen Documentation

Figure 36: "Field Observation" activities described in design documentation correlate positively (Beta=0.531) and significantly (Sig. = 91%, R2 = 0.28) with output performance measured by external judges suggesting that transitions from planning to execution and breadth of inquisition impacts performance.

128


The number of field observations is also an indicator of the breadth of the investigation made by the designers; more field observations are likely to result in more insights. Similarly, the number of unique URLs shared among design team members provides a measure of the breadth of the investigation: every URL is a proxy for a possible solution, which the design team considered. A comparison between the number of URLs shared within a design team via email and the output performance (measured by external judges) paints a similar picture as that created by the field observations. Figure 37 shows the relationship between the number of distinct URLs shared within a design team and output performance. They correlate positively (Beta=0.514) and significantly (Sig. = 90%, R2 = 0.27). This reinforces the suggestion that designers who consider more options will perform better.

Furthermore, this finding suggests that the number of

URLs shared within design teams might be used to indicate performance, which could contribute toward automated design team performance measurement and prediction.

129


Unique URLs Shared Within Design Team vs. Output Performance

f

X

^ ^ — " - " " " " " ^ R2 = 0.26S

^^K X

*

-

^

^

V.

^

X X 100

ISO

200

2S0

300

Total Number of Unique URLs shared within Design learn via Email

Figure 37: The total number of distinct URLs shared within design teams correlates positively (Beta=0.514) and significantly (Sig. = 90%, R* = 0.27) with output performance measured by external judges suggesting that breath of inquisition impacts performance and that it might be possible to predict performance automatically.

Table 14 summarizes the results of the quantitative analysis performed to test the Execution Hypothesis. The results support the hypothesis in two instances. In the other instances, no significant correlations were found or 7

the correlations are too weak to draw conclusions (R2 = 0.072 and R2 = 0.284 cumulatively for three variables). The small sample size (N=11 teams) can be expected to have contributed to this.

130

A Unified Innovation Process Model for Engineering Designers and Managers Table 14: Summary of results of quantitative analysis performed to test Execution Hypothesis. \- Independent Variable Design activity documented and coded in design reports

Dependent Variable

Finding

' [;'!,£

Output performance measured by external judges

The number of "Field Observations" correlates positively with output performance (Beta=0.531, Sig.=91%, R2=0.282)

Design activity documented and coded in design reports

No significant correlation found

Output performance Sum of design measured by outside team members' judges activity via email, wiki, and WebDav Average of design team members' satisfaction with team measured using Team Diagnostic Survey (Wageman, et al., 2005) Individual design team member's satisfaction with team measured using Team Diagnostic Survey (Wageman, et al., 2005) Design team members' satisfaction with design Individual design process output team members' activity via email, wiki, and WebDav Design team members' perception of individual and team energy state measured using instrument adapted from Bruch & Goshal (2003)

The total number of URLs included in emails by the design team members correlates positively with output performance (Beta=0.514, Sig.=90%, R2=0.265)

No significant correlation found

The number of conversationinitiating emails correlates negatively with the individual's satisfaction with the team (Beta= - 0.268, Sig.=97%, R2=0.072) No significant correlation found The combination of the number of conversation initiating emails, distinct URLs in emails, and wiki pages authored by an individual relates to the individual's perceived quality of the team's energy (Beta= - 0.268, 0.452, 0.299 respectively, Sig.=99.9%, R2=0.284)

131


7.2.

Findings Concerning Censorship Hypothesis

If the Censorship Hypothesis is correct, one should find that the feedback from possible censors correlates negatively with the number of activities undertaken by designers and their performance.

The Censorship

Hypothesis was thus tested by comparing the number of emails sent to design teams by reviewers to output performance measured by external judges and to the number and kind of activities documented by the designers. These correlations were also tested using linear regression analyses. The comparison between the emails sent by the various kinds of reviewers and the kind and number of activities documented by designers shows that the number of emails from coaches is significant. Figure 38 shows that the number of emails sent by coaches correlates positively (Beta=0.630) and significantly (Sig. = 96%, R2 = 0.397) with the total number of activities documented by designers. The number of emails from coaches correlates even more strongly (Beta=0.816) and more significantly (Sig. = 99%, R2 = 0.666) with the total number of prototyping activities. This suggests that coaches have a positive impact on overall execution and prototyping in particular. If the first hypothesis is valid, this results in higher performance.

132


Emails from Coaches vs. Prototyping and Total Activities O O X

("ROHbtaLProtolypes

X

SUMjotaLactivities llnear(PRQTotal_Prototypes)

• - - - UneartSUM_tota1_aEt*vlties&

R* = 0.666

Q X R! = 0.397

1E Z 35

O

M

Q

X

X

IS

20

24

30

35

Number of Emails from Team Coaches

Figure 38: The number of emails sent by design team coaches correlates positively (Beta=0.630) and significantly (Sig. = 96%, R2 = 0.397) with the total number of activities documented by designers. The number of emails correlates even stronger (Beta=0.816) and more significantly (Sig. = 99%, R2 = 0.666) with the total number of prototyping activities suggesting that coaches have a positive impact on overall execution and prototyping in particular.

Coaches are not involved in the official review process and do not have authority to censor ideas. Instead, their job is to support the design teams and to help them find a solution to the design problem. The results of this analysis suggest that they do so by encouraging execution and prototyping and therefore act as the opposite of a censor. The data does not

reveal

significant

correlations

between

activities

and

the

communication by official reviewers (teaching team members and liaisons), which may again be attributable to the small sample size.

133


A comparison between the number of emails sent by the official reviewers and team performance (measured by external judges) indicates one significant correlation (Sig. = 95%, R2 = 0.372). The number of emails sent by one teaching team member correlates positively (Beta = 0.610) with design team performance as shown in Figure 39. This specific member of the teaching team can be described as an 'anti-censor' who typically encourages ideas rather than objecting to them.

The

communication by other members of the teaching team (some of who have censored ideas in the past as described in chapter 5) has not been found to correlate significantly with design performance or activities. If it is assumed that all reviewers act as censors, then this finding is contrary to what the Censorship Hypothesis would suggest. Alternatively, this result can be interpreted to support the Censorship Hypothesis through reversal. It suggests that reviewers, who encourage ideas instead of censoring them, do have a positive impact on performance.

j

134


Number of Emails Sent by Encouraging Member of Teaching Team vs. Output Performance 3.2

1 I

3.1

1 1>

3

IS

JO

2.8

2.7

:Per

2.s

5

2.S

1&

2.4

1 a

23

2.2

0

1

2

3

4

5

S

1

8

Number of Emails Sent by Encouraging Member of leaching Team

Figure 39: The number of emails sent by the 'anti-censor' member of the teaching team correlates positively (Beta=0.610) and significantly (Sig. = 95%, Fr = 0.372) with output performance.

The positive correlation between the email behavior of coaches and execution, especially in the form of prototyping, and between the email behavior of a self-proclaimed 'anti-censor' and performance suggest that design coaches and reviewers can indeed encourage execution and positively impact performance.

These findings indirectly support the

Censorship Hypothesis through reversal. The absence of a significant negative correlation between reviewer email behavior and design team performance or activity precludes a direct quantitative validation of the hypothesis.

The fact that positive encouragement and feedback have a

positive effect on design activity, however, suggests that negative

135


feedback and discouragement have a negative effect on design activity, leading to ideas being discarded without testing. One may argue that the lack of a significant negative effect of communication by reviewers is not surprising and that the Censorship hypothesis cannot be tested in a project-based engineering design curriculum.

The goal of this education method is to teach students

through the experience of design activity. Therefore, it is perceivable that the teaching team might encourage almost any kind of action for pedagogical reasons and not censor ideas.

However, as explained

before, members of the teaching team have been found to censor ideas and therefore this test was performed. Table 15 summarizes the results of the quantitative analysis performed to test the Censorship Hypothesis.

136

A Unified Innovation Process Model for Engineering Designers and Managers Table 15: Summary of results of quantitative analysis performed to test the Censorship Hypothesis. , Independent Variable

Reviewers' (teaching team, coaches, liaisons) communication with design teams via email x

Dependent Variable Output performance measured by outside judges \

Design activity documented and coded in design reports

Finding The number of emails from the 'anti-censor' member of the teaching team member correlates positively with output performance (Beta=0.610, Sig.=95%, R2=0.372) The number of emails from coaches correlates positively with total design activity and with prototyping activity (Beta=0.630, Sig.=96%, R2=0.397 and Beta=0.816, Sig.=99%, R2=0.666)

The details of the statistical analysis performed in SPSS and a list of the variables tested are included in the appendix.

137


8. Discussion The previous chapters described the qualitative and quantitative data analysis and a theoretical model that provides a logical explanation for the hypotheses developed. This chapter discusses the research approach, the validity and applicability of the results, and the contribution of the work done, and provides an outlook on how this research might be continued in the future.

8.1.

Methodology and Data

This research was started without preconceived hypotheses. Instead, the hypotheses emerged through simultaneous development of an abstract model of the design process and analysis of data from observations and interviews.

The continuous shifting between field data and theoretical

abstraction ensured that the model remained realistic. At the same time, the model helped pinpoint areas for detailed data analysis.

8.1.1. Qualitative Analysis

The methodology for analyzing the cases and generating the hypotheses closely followed established practice (Eisenhardt, 1989) by using withincase and cross-case analyses and enfolding the current literature. The simultaneous rather than successive development of theory and data analysis, however, bears the danger of selection bias and a premature focus on specific aspects.

138

Therefore, based on the qualitative data


analysis, no claim can be made towards the magnitude of the issues discovered but only to their existence. By contrast, the effect of researcher bias in the descriptions of the cases is controlled for. First, the case descriptions are derived mostly from the written documentation created by the designers. Second, to ensure that the descriptions accurately match the view of the designers, members of the design teams described reviewed all write-ups. These reviewers are not involved in the research and the descriptions were modified based on their feedback. 8.1.2. Model Formulation The unified innovation process model described in Chapter 6 was initially represented as a continuous feedback control system diagram. The idea to model the design process as a control system is based on the observation that design activity is a continuous comparison between actual and desired output and that adjustments are made until the actual output matches the desired output.

However, in discussions with

researchers and practitioners, it was found that a decision flow diagram would provide a better representation.

This representation combines

elements familiar to both engineering designers and managers. It also illustrates that the design process consists of both continuous and discrete elements.

139


The labels for each block are part of the daily vocabulary of designers and managers. On the one hand, this ensures that both sides can quickly relate to and grasp the model. On the other hand, the use of common terminology can lead to ambiguity because everyone has a unique preformed understanding of the meaning of each label. The ontology, which explicitly specifies every block and every function, is expected to eliminate this ambiguity. In addition to specifying all terms in the model, the ontology also helped during the creation of the model.

The

requirement to define and differentiate each pathway and block in terms of its unique characteristics led to a clear and concise model that is internally consistent. The ontology is presented in pseudo code. Even though it would be possible to express it using the language, symbols, and syntax used by computer scientists, it is not expected that this would improve the quality or usability of the ontology. 8.1.3. Quantitative Analysis All quantitative and qualitative data used in this study is from open-ended long-term projects. The data describes the design process from original need for innovation to functional proof-of-concept prototype. This allows for a more realistic investigation than data gathered from two-hour laboratory experiments would.

However, this also reduces the

comparability of the data because every project is unique, and because


only a limited number of factors can be measured and controlled for. At this time, when the interaction between designers and managers is barely understood, this kind of field research is appropriate to uncover factors and relationships, which must be verified and quantified in controlled experiments in the future. The analysis was primarily performed at the design team level rather than at the individual designer level. The design team level was chosen as being the significant level because the output is measured at this level. As a result, the number of samples used in the quantitative analysis is small (N=11).

The uniqueness of each project also reduces comparability

between projects.

To further complicate matters, a small number of

missing responses can result in significantly distorted results. Figure 40 shows that the response rate to the Team Diagnostic Survey is 92%, which is extremely high for a survey. However, this hides the fact that in one case, only one of three design team members responded. In this case, the value used for the team represents the opinion of one team member only.

141


O G

Responded No Response

Figure 40: Response rate to Team Diagnostic Survey is 92%.

The effect of missing responses is also of concern for the data collected through electronic logging. Only emails that were sent through the official email list provided by the course were archived and logged. If an email was sent directly to the team members, rather than through the list it was missed in this investigation. It is not known what percentage of emails was lost in this fashion. It can be suspected, however, that in particular, teams who did not want the reviewers to see their correspondence used this method to hide ideas from the eyes of reviewers who had access to the email list archives. The design documentation analyzed through coding prompts a similar concern. During the coding process, it became apparent that different design teams documented their process with different levels of detail and resolution: some teams had documented minor iterations as separate prototypes whereas other teams clustered multiple improvements into one prototype generation.

142

The coding procedure, where four coders first


coded the reports independently and then gathered to review all codes and to classify them, was used to control for this as much as possible. Only linear correlations were tested during the quantitative analysis. Inspection of the data scatter plots had shown that the sample number was too low and the data distribution too irregular for it to be possible to detect a specific shape of curve (such as a U-Shape or inverse U-Shape). The quantitative analysis was therefore restricted to testing linear regression, which assumed only linear correlations. Similarly, the analysis of the impact of email communication on activities and performance was restricted to the count of emails regardless of content. This assumes that each reviewer maintains a consistent style of feedback across all teams over the long term and that therefore, it is not necessary to analyze the individual content of emails. In the eyes of the researcher, this assumption can be made based on his communication experience with each reviewer. 8.1.4. Performance Measurement The difficulty of accurately measuring design process performance is a key challenge in design research, as this study confirms again. In this research, performance was measured in four ways: 1. Outcome performance measurement by external judges 2. Outcome performance measurement by designers who created design

143


3. Design process performance measurement by designers using Team Diagnostic survey 4. Combined outcome and process performance measurement by reviewers based on course grades The narrow spread of the grades into three levels (with only one data point at one of the three levels) limits the value of grades as a differentiating measurement scale. Grades were therefore discarded as a performance indicator. The Team Diagnostic Survey, which has been shown to accurately measure work team satisfaction (Wageman, et al., 2005), does not measure the output of the process. Even though from a purely productive point of view, this aspect does not matter, it must matter to managers interested in long-term success and employee retention.

This

measurement tool is therefore appropriate to measure performance from a process point of view and should be included in design performance measurement at the individual designer level. However, given the spread of responses within teams, its utility as a measurement tool at the design team level is limited. Output performance by the designers themselves is a highly biased indicator, which was discarded in favor of the more objective performance measurement by external judges.

144


The outcome performance measurement by external judges represents the least biased measurement tool available. For this measurement, twopage project summaries created by the design teams were given to nine external judges who had no prior knowledge of the project or the design team. They were therefore able to make judgments based on the output only, unbiased by process observations or preference for certain people. The instructions and materials given to the external judges are included in the appendix. Originally, judges were asked to rate each project based on innovativeness. However, interviews with the judges revealed that each judge viewed the result from a different perspective. The judging scheme was therefore revised to separately measure performance from the perspective of an investor, a gadget lover, and a user as indicated in the instructions. For a design to be successful in the market, all three types of customers must be convinced of the idea's value. An investor must first support the business plan with funding, then gadget lovers or early adopters must begin buying the first generation of the product, and then the average user or the masses must follow. Design performance was therefore measured using the average of the three categories. One may argue that a two-page summary is not sufficient to judge the outcome of an eight-month design project. One the other hand, it can be argued that the two-page summary is ideally suited for this form of assessment.

It is the work of the designers and represents their

145

A Unified Innovation Process Model for Engineering Designers and Managers communication style and ability to rationalize their design as they would in presenting it to an investor or customer. Rationales not communicated in this summary are unlikely to be presented in a pitch to investors or users.

8.2.

Limitations and Applicability of Results

The research described in this dissertation was performed in the context of an engineering curriculum rather than in an industrial setting. Naturally, this questions the validity of the results outside of education. As described in section 3.1, the curriculum, which served as a living laboratory, closely resembles industry, and all design work was performed on challenges given by industry. Additionally, the 'Unified Innovation Process Model for Engineering Designers and Managers' was presented to practitioners at the product consultancy I DEO and prompted the following comments: "Prior to IDEO, I experienced censorship constantly. In fact, it's part of the reason why I left that company. On any given day, I'd find myself spending 30 to 40% of my time creating PowerPoints in order to justify work that I should have been doing anyway as part of innovation strategy. I had to create the decks so that my boss could take it to his boss who would take it to his boss, and so on through various levels of senior management, so that they could take the PowerPoint, and...censor it. "At the corporation where I worked prior to IDEO, the notion of small experiments or prototyping was not part of the ethic. It was frustrating for those of us who worked in innovation. I didn't think of myself as a designer back then but I certainly wanted to get stuff done, so I was interested in doing more than talking." Holly Kretschmar, Practice Lead at IDEO

"I think it is just important to point this out. The censorship as a key; as you said, it's a gate switch or it's something that most organizations don't let people actually get in the execution mode and

146

A Unified Innovation Process Model for Engineering Designers and Managers they spend a lot of energy on the censorship part and you see so many work-arounds." Diego Rodriguez, Partner at IDEO These comments indicate that the model is applicable to industry and resonates with both designers and managers. It can therefore serve as a tool that fosters communication and understanding between the two sides. The breadth of the investigation, using multiple locations and cultures, also suggests that the findings

are

relevant

to

individuals

and

organizations outside of Silicon Valley, and are not restricted locally by culture or other circumstances. The results are also expected to be applicable to innovation outside of engineering design. In all areas of innovation, whether it is technology, business model or social innovation, important insights can be gained during execution. Innovators in all areas and disciplines should therefore consider prototyping and testing ideas rather than censoring them after only theoretical deliberation. At the same time, it is important to point out that the recommendations are limited to new concept development. Managers and designers must be careful to understand when and where new solutions are desirable and when they can be dangerous.

For example, software would become

unusable if interface programmers created a unique design for each screen based on what they think is the best user interface for the application they are working on. In this situation, censorship, templates

147


and rules are needed so that users who are familiar with one screen can easily navigate other screens. It is therefore important that designers and managers know where they want innovation and where they do not, and that this is clearly communicated and agreed on. The 'Unified Innovation Process Model' should help them understand the importance

of aligning their

expectations. 8.3.

Recommendations for 310 Curriculum

The findings from the research provide several suggestions for the 310 curriculum. During the report coding, it was found that the resolution and style of the design documentation differs greatly between design teams. In order to obtain better comparability between projects, the reporting scheme should be standardized. The requirement for teams to complete standardized progress report forms each week in addition to the current design documentation is a possible avenue. This way, the design teams are left with the freedom to present their work in any fashion they want, while at the same time a more complete and comparable record of activities is obtained. Of course, these forms would have to be carefully designed with clear definitions of what activities and findings are to be included. The correlation between the email communication by coaches and the level of activities by design teams suggests two things: First, the result

148


can be used to demonstrate to coaches and students the importance of regular communication with each other. Second, the count of emails from the archives can be used to identify the most active coaches who should be asked to coach again in future years. 8.4.

Contribution

The contribution of the 'Unified Innovation Process Model for Engineering Designers and Managers' is in synthesizing the perspectives and duties of engineering designers and managers. Table 16 provides a comparison with the affordances of prevalent models for the process of new concept development. This summary indicates that the synthesis achieved by this model is more comprehensive than that achieved by other models known to the author. It can therefore serve as a guide for engineering designers and managers so that they better understand each other.

149


Discipline

Table 16: Comparison of prevalent new concept development process models from engineering design and innovation management with the 'Unified Innovation Process Model for Engineering Designers and Managers".

S2 o Model c

Innovation Management

.£ 0 TOO c UJ

focus on têTBa^lifieabfThei0,: \ ^——.Eorget-MerNoftnotifiGationjsystemassuresJhe-userJhatnb'item E^rvrriot-âiKli-ifsrw-itifioati/^nrct/ctairnfoooi irao f h o i i c ^ r t h a t L n n < i l a m -__„ will-be.forgotten by offering-audio feedback/when an item js'left "y~. a pocketCl_y feC\ («0, . Features The MiniPocket offers several features which enhance the Miqi: storage experience: i The Pockets are easy to use with one hand. == lfS -f»—-Aecesslo-any-item is fast and convenient. _ L!V~ E} V andin9 _.!!5. r 'H s u s e d t 0 c r e a t e a storage area that fits ~^*'~"*âhd-protects:iterns-ranging from CDs to cell phones to

® rr o j \ \\ m

1

cbsespptomafiStlw

r

The user_can\Chdbse tobe reminded if itemVare'fdrgotfen in — ~ _ a pbckftwrien exiting the carl / / r-\ \ \ •—Use.oteeihng area-for-storage utilizes previously unused space'into.use ifTthe feature full Minijarckpit. ' "~ *-"*"

Team

%J —_

11 1 ffO J Bo-Axel Blomberg | Paul Copenhaver | Evan-Earnest"| Carrie! Edwards | Joonas Jahkola | llkka Jarsta | Senni Kirjavainen

v@xd

\ TLiaso'ri. i»deff.2a'b'el,-BMW:

"HCoaches _ Larry Ch'entfPL'illi'Palasto P

items out of sight

UL c m

187


Stanford University - E310,2007-2008 Team Based Design with Corporate Partners

Portable Assistant of the Service Technician of the Future Vision MiniG, a combination of a novel device and software, represents the center of a solutions package that enables technicians to work efficiently. By leveraging current and emerging technologies, the miniG portable assistant will assure that service technicians are able to fully concentrate on their core tasks by automating all supporting activities, such as generating documentation. It also provides data relevant to the technician's work and captures new information essential t o the customer and company. Additionally, new business processes are made possible by the miniG t o assure customer satisfaction.

The Team Liaison Ronald Bieber Stanford University Andreas ICatson is ttaubnMiuanfor&atfu

Michael Lau tncl*uff*t»ntof*«A»

Pratyus Patnalk (iraty«is@ftaBtfbntadu

Robbie Hotop rtioiBpîtiiftfordLcdu

Tyler Riding u&tag@3anfl»tf«dij

St.Gallen University Oominik Burkolter Domlnik Wurzer dom!naiwuil«r@tyitiiLn

Features Versatile and ambidextrous design • Large touch screen and context aware shortcut buttons • Automatic screen orientation Process orientated software • Easy and convenient work reporting by voice recognition • Simple and accurate parts cataloging utilizing RFID technology • Automated arrival/work status generation to the customer • Picture, video, and audio capturing for documentation • Access to a wide variety of information from reports and manuals • Fast and convenient access to critical data and responsible experts Portable

• Size: 10.9 in (277 mm) x 5.3 in (134 mm) x 2.0 in (SO mm) • •

188

Weight: 1.96 lbs (889 g) Screen: 7 in (178 mm) wldescreen display at 1024x600 resolution

Eva Knellwolf ev».fcnc£walf#f*udent4>nisg«Ji

Coaches Ernst EnsSlin Gretchen Anderson

m

Corporate Sponsor


Design The design team aimed to create a solution that supports service technicians in their daily work. Over a seven month period, the design team took the following steps to develop the final design: • • • • •

Characterize typical service technicians' daily work by researching, interviewing, and observing Examine a service technician's current toolkit and interaction modes to identify unaddressed needs Research and assess current and emerging technological solutions Create prototypes and refine design based on user testing Focus on a solution that addresses the needs of all service technicians

Physical context-aware buttons provide feedback and easy access information on demand

comfortable extended use

Service Technicians of Today DB Kommunikationstechnik (DB KT), the customer of this project, employs 950 service technicians in 95 different locations. Currently, mobile service technicians primarily rely on paperwork and mobile phones for communication with the central office. However, these solutions are no longer efficient compared to the technology available today. These service technicians spend up to 30% of their working day on transportation and require additional hours to fulfill unpopular administrative work. They also encounter frequent time-consuming problems in the field such as searching for machines and seeking the proper expertise. Service technicians are in need of a solution that provides support in every step of their working process, and the miniG portable assistant is the answer.

m

189


RE-THINKING THE CENTER STACK "" TEAM I MEMBERS i

»

Mika Heikkinen Fern Jira L Nicole Sampson |

Diana de Anda Miguel Barousse Octavio Narvdez Agustin Piancarte

BACKGROUND LIAISONS lohn Lenneman Frankie James

As the automotive industry evolves, each new model year brings another proliferation of features and functions to the passenger cabin. Although the consumers have expressed a strong desire for personalization, the bid to provide "something for everyone" often wins out, resulting in a progressively more complex human machine interface. These user interfaces are often sited as sources of driver distraction and frustration. Our main goal is to find a viable solution that re-thinks the conventional center stack and streamlines the user interface, while providing ready access to the most important features to each individual user.

TEACHING TEAM JiLee Alberto Vega Victor Gonzalez COACHES Mark Bianco Vicente Borja Luis Equihua

ME-310 2007-2008

190

DESIGN STRATEGY GM Team is composed of seven members from four different cultures. Each person brings a unique perspective on design and the automotive experience. As such our design is built to be understood by and adaptable to the international market GM serves. Our primary design directive was to allow safe access to features for the driver and passengers. By creating a customizable, tactile based interface we have simplified the user interface and reduced the reliance on LCD based nested menus. Our kinesthetic approach seeks to - Limit the number of options found in the primary controls area to features most commonly used by each specific user - Reduce the nunt-and-peck nature of today's crowded center stacks. - Lessen the amount of the driver's distraction caused by taking their eyes off the road. Team GM has designed a specific area called "Experience Zone", in which the controls can be selected and placed according to the user's needs.


RE-THINKING THE CENTER STACK /ess Wires

/ friendly HMI integrative

DESIGN REQUIREMENTS KEY CONCEPT Maintain Access to Features

EMBODIMENT Simulation of the following main systems: Audio, Climate. Navigation, Entertainment.

Personalization

Graphics on interface and iconographic shapes of the device can be selected by the user.

Safety

Accessing features through the HMI while driving must not constitute a distraction.

Flexibility

The HMI must be adaptable to new technologies, services and needs of the users.

Interaction

Rear passengers should have the opportunity to access the controls of the features reviously mentioned.

; / ;

£Z personatfzab/e

I

versa:

Sleek

The Experience Zone is the culmination of lessons learned from several disparate prototypes created at both UNAM and Stanford over the past eight months. These prototypes gave us invaluable, and often unexpected insights on how vehement users are about their preferences for location, the power of muscle memory, a distinct disdain for clumsy adapters as a method of integrating their cars with innovations in personal electronics, such as cell phones and iPods, and the impact of (un)intuitive interfaces on safe operation of any moving vehicle. Both passengers and drivers desire easy access to the controls fhey deem essential. The EZ allows for a tailormade solution that can be mass manufactured while still allowing for the selection of features and visual palettes in an intuitive package that resonates with users in a wide variety of cultures.

191


192

Ifllir -Atmospheric Water Generator

fflfi§6i® global Background

T h e Vision Team Immerse aims to design and develop an Atmospheric Water Generator that produces clean, affordable drinking water even in adverse climatic conditions. The task includes development of a new, radical technology that is energy efficient and works reliably under a wide humidity range. In addition, the look and feel of the hew device would create a new user interaction and provide added comfort and portability for home and office use.

Scarcity of pure drinking water is a big problem in the world today. According to several surveys, one out of every three persons on the planet lacks accessibility to fresh water. This has necessitated the need to come up with alternative sources of drinking water as the conventional sources such as ground water and rivers are neither universally available nor very pure at times. Air water generators have been addressing the need to generate pure drinking water from atmosphere for the past two decades. However, the design presently in vogue has a limited applicability. The present technology is not a reliable option in adverse climatic conditions, like low relative humidity and extreme temperatures.

asss© agists®©©-'

V,

I Liaison _ I George Alvarez immerseglobol,, i CEO Immerse Global

©

^ D r y Air

III!

s

QPlEp

Deliquescent

^"ld Water water

m. Water g Vapor

^

Condenser

Tank

Water

Fitter

3

»

Drinking Water

*

Product Innovation Engineering Program i Erik Brannstrtm Erik Dahlbeck j Pontus Sundberg David Eriksson \ Johan Wenngren Reza Hashemi Jenny Ahmart Henrlk Bruce j

Heater

[pJS-r] • — • [ u a giwi]

AAoiSt A'*r_ '—

Stanford University Harshit Gupta Anders HSggman

Produces enough water for one family even under dry conditions (7-10 liters of water per day at 25°e, 35% relative humidity). The technology is energy efficient and is environment friendly (no refrigerants involved). Produces clean and healthy drinking water.

Features

Team Immerse design uses an aqueous solution of the desiccant - lithium chloride - to absorb moisture from air. Desiccants are chemical substances that have a natural tendency to absorb moisture from the environment. The key advantage of a desiccant over conventional refrigeration cycle is that its performance does not deteoriate appreciably at low humidity levels. Also, the liquid solution enables easier handling of the substance. The CUBE can manage two very important things - an effective water collecting system and a high airflow. The air flow needs to be high because of the small amount of water at low RH levels. Another aspect is that the prototype uses a true distillation process to extract the drinking water. This process naturally kills any microbes and fungi that may be present in the solution, thus producing clean, pure drinking water.

Present Design

- Atmospheric Water Generator


195


Kodak DIGITAL HqBILE-CONTROU.ECI0IGITAL CAMERA SaSTEM

MOBILE-CONTROLLEDI DIGITAL CAMERA SMSTEM

Everyoneln System

MOBILE-CONTROLLED DIGITAL CAMERA SaSTEM

______ A

The Kodak Everyoneln system consists of a camera that may be controlled with a cell phone. Place the camera wherever you'd like. ' Loadthecomplimentaryapplication on your cell phone. Now the user can see the camera's viewfinder, pan and tilt the perspective, and capture and send images—all through a cellphone.

FEATURES 20DA Live View See the camera's image live view on a mobile phone, via Bluetooth connection. Instant Image feedback at 3 frames per second.

Or, set your camera down and let your friends take the pictures via their phones.

Remote Control From the phone application, users can pan and tilt the camera, zoom i n / out, and capture images.

Device to Internet Transfer E-mail pictures from mobile or post on Flickr.com by using Wi-Fi technology.

Storing Once captured, images are stored in albums on the cell phone.

Quality Pictures 5 Mega pixels camera and 20x digital zoom.

Control Multiple Cameras with Multiple Phones: Forgot your camera? You can use your phone to control your friend's camera.

Ease of Use: GUI that allows user to control the features, take pictures and share.

PRODUCT E010

Sharing Device to mobile photo transfer by using Bluetooth transfer between mobiles.

FEATURES E01D Live View 2.0 As the processing power of cell phones increases, expect at least 7 frames per second by 2010. Find Me system The Everyoneln camera will be able to locate the user by 2010. When desired, the phone will emit a beacon, which the camera will swivel to find the phone. Panorama: Automatic wide-persepctive images using existing pan/tilt capabilities.

196


Kodak

MOBILE-CONTROLLED DIGITAL CAMERA SUSTEM

MOBILE-CONTROLLED DIGITAL CAMERA SSSTEM

SPECFICATIONS Dimensions (WxDxH)

3.90x2.09x0.83 in

Weight

4.55 oz

Resolution

Up to 5 megapixel: (2592 x 1944 pixels)

File format

JPEG/EXIF

Exposure compensation

+2 ~ -2EV at 0.5 step

Zoom

Digital up to 20x (5 megapixel up to 6x)

Sensor

CMOS 5 megapixel (2592 x 1944 pixels)

Focal length

5.6 mm

Focus range

10 cm ~ infinity

Macro focus distance

10-50 cm

Shutter speed mechanical shutter

1/1000-1/4 s

Battery

Battery (BL-6F) 1200Mah for the internal camera, 2 AA NiMH - 2000mAH rechargeable batteries for servos and board

DIGITAL

MOBILE-CONTROLLED DIGITAL CAMERA SSSTEM

MARKET NEED a VIABILITY During extensive field testing of over 100 high school and college students, we discovered that people lovet ._ to pose for pictures, but hated being left out oif a snapshot. We began exploring ways to get everyone inside of the picture, including cameras that could be thrown, rolled, flown, bounced and remote-controlled. Though remote control seemed the most promising option, we didn't want to burden the user with yet another device to carry. Our ah-ha moment came when we realized that nearly every young adult carried a possible remote control around with them all the time—their cell phones. We believe that by letting the user remotecontrol the pictures he or she takes, the Everyoneln system lets him spend less time stuck behind the lens and more time creating pictures with friends to share and post. To test our perceived market need and receive feedback on the Everyoneln system, 48 earlyadaptors tried the Everyoneln system. The resu Its? 42 out of 48 users reported that they would buy the Everyoneln camera if comparably priced with conventional digital cameras on the market today. Q . Would you buy the Everyoneln camera? YES 87.5%

DESIGN TEAM Stanford University Pontificia Universidad Javeriana Engineering 310 2007 - 2008 Team Based Design Innovation with Corporate Partners

Designers Santhi Elayaperumal Jackie Bernstein Johannes Jung Giovanny Arbelaez Maria Montesdeoca Carlos Rinc6n

Liaisons Ashfaq Syed Jeffrey Witkop Richard Young Team coaches Uri Geva Carlos Serrano

197

TKK

Lauri Tolvas, Industrial Engineer Tuull Utrianen, industrial Engineer Communication

We created a system that is intuitive, and which allows the user to operate different functions from key devices according to the users' needs. We wanted to free the users' eyes,

Buttons and screens are convenient in a stable environment but what if you are on the go? You want to interact with the environment, not with your devices. To operate your devices you need your hands to push buttons and eyes to look at screens. It also takes time and effort to retrieve your devices from pockets and bags. Additionally learning user interfaces is stressful and inconvenient

Engineering & Systems Division Timo Vuori, Researcher

Seta Suslluoto, Marketing

Coaches

Seokchang Ryu, Mechanical Engineer

John Murray, Principal Engineer

Technology Collaboration Group

Chingju Hu, Mechanical Engineear

Dan Rosenqvist, Industrial Designer/ Marketing

Scientist & Director

Jacob Federico, Mechanical Engineer

TKK

Liaison Deaima VWIkes-Gibbs, Lead

Stanford University

Intuitive control method for portable devices

Panasonic

hands and cognitive capacity. Using our solution doesnt isolate the user from the environment but enables him to do it in an accessible and discreet way. Welcome to the magical world of Panaclick.

"free your hands, free your eyes, free your mind... with just one click"

Mafeushla Electric Industrial, Ltd (PANASONIC)

Corporate sponsor

We chose to demonstrate our control method with two devices: A mobile phone and an MP3 player. Our choice was based upon the functions these devices offer, more than the devices themselves. We believe that in the future,

Utilizing the technology the user already carries with him allowed us to implement the system without adding extra devices. The users of cell phones and mp3 players often already use headphones so the implementation of a device in them was a natural choice for the team.

In order to make the user interface as fast and intuitive as possible we implemented only the essential functions. When the user wants to perform difficult tasks, they can use the controls on the device itself. The most essential functions can be performed without using hands or eyes, discreetly and on the move.

regardless of how devices evolve, people will still want to speak with each other over a distance and also listen to music for entertainment.

Double Teeth Click

Reject Call

-' »f ,,-V**'" Single Teeth Click

Answer Call

^

- , \

Cellphone with bluetooth capebRltte3

. -**-•

Triple Teeth Click

fepliNe^p-, /

Teeth Click + Tilt Your Head Left

Previous Track

Next Track

Cancel The Last Command

Double Teeth Click Teeth Click + Tilt Your Head Right

Play/ Pause

^C-^&I^MîW^'^M,

Teeth Click + Move Your Head Slowly Forward or Backward

Volume Control

ite.BBîf^Ss' :a£ t

o o

The Wonderwall is a room for improved customer experience which features a recommendation system, an adaptable environment and a community link. The recommendation system lets users explore different outfits created around a specific product of his choice. The content is generated by an online community which links single items to create meaningful combinations. Every customer can actively contribute from within the store or over the internet which ensures an accurate community acceptance rating for each product and combination. The interface allows access to previously bought or bookmarked items as well as items just found in the store. All of these may be used to create and share outfits. Wonderwall can access information about all the products a retailer has on offer, regardless of whether they are available in the store at the moment or not. Through that the border between online and offline shopping diminishes and gives the user the choice of his preferred shopping and delivery channel — at any time.

Inspiring information

The Wonderwall has been created to improve customer experience. Today the shopping experience is impersonal, often stressfull, and the consumers lack the information they need to make good and satisfying purchase decisions. We aim at solving these problems by providing an inspiring in-store recommendation system that lets its users actively contribute to the content.

I

The Wonderwall allows the customer to control the surrounding of the room. By scanning a Moodobject, the user can adjust the images, sounds, colors and the lights of the room to a new appealing theme. This provides an agreeable environment for the customer to get into any mood he likes — to calm down if he's stressed and to activate his senses.

The Environment

ENGINEERING 310: ENGINEERING DESIGN ENTREPRENEURSHIP 07-08

Wonderwall

Project name: Retail store of the Future Created by: Carolin Reichmann, David Steijer, Jakob Wallsten, Nando Muller, Tytti-LottaOjala Liaison SAP: Erica Dubach, Jasser Al-Kassab E-mail: [email protected]

accurate r e c o m m e n d a t i o n s d u r i n g t h e next visit t o t h e store.

back a n d ratings, w h i c h are i n t u r n t h e basis for even m o r e

b e shared with t h e o n l i n e c o m m u n i t y to obtain qualified feed-

ously saved items a n d create new outfits with t h e m . T h e s e can

O n his p e r s o n a l c o m m u n i t y page, the u s e r can access p r e v i -

Community

o r d e r it to his h o m e .

where else t h a n i n t h e store, t h e c u s t o m e r can conveniently

sonal c o m m u n i t y site. If the i t e m of interest is located s o m e -

the fitting r o o m for h i m to try it o n , o r b o o k m a r k it to his p e r -

either buy the p r o d u c t right away, request it to b e delivered to

can zoom in to view a m o r e detailed image. F r o m h e r e he can

If t h e user wants t o find out m o r e a b o u t a particular item, h e

View items

c o m m u n i t y site a n d share it with his p e e r u s e r s .

ticularly likes a n outfit, h e can b o o k m a r k it to his p e r s o n a l

access m o r e i n f o r m a t i o n a b o u t each c o m b i n a t i o n . If h e p a r -

can easily navigate t h r o u g h t h e r e c o m m e n d a t i o n s given a n d

W i t h the intuitive t o u c h screen u s e r interface, the c u s t o m e r

Explore outfits

.;

.

»

®)(A^f^)^)

(a> 1

iXfi,

^?®£t

Community page

Explore outfits

•. I

i

the c u s t o m e r can easily explore outfits that have b e e n created a r o u n d that item, by t h e o n l i n e c o m m u n i t y .

i i

I n t h e retail store of t h e future, all p r o d u c t s will be labelled with RFLD chips. By s c a n n i n g a n item, i n the-fitting r o o m ,

ENGINEERING 3 1 0 : ENGINEERING DESIGN ENTREPRENEURSHIP 0 7 -

Wonderwall

University of ScGallen

0) 3 01 CO CD

03 3 Q.

CD

CD W (Q 3

o

3 CO 3" CD CD 3' CO

m

O Q. CD

CD CO CO

o o

3

o"

i—H

5" 3 o

ProQuest Dissertations

ProQuest Dissertations

Suggest Documents