Effective Framing in Design

Thesis Thesis Thesis Thesis

This thesis is about how New Product Development (NPD) and design teams 1 can successfully make products that people want. It is partly motivated by the reality of 30,000 new products hitting the shelves each year but only 10-30% of them lasting into the second (Gavetti and Rivkin 2005). The vast majority of new products, in other words, fail. Given that companies rarely manufacture and release products that simply don't work, one major cause 1 While design and New Product Development can be seen as different entities NPD invariably involves some design and the outcome of the design process is very typically the development of a new product. The difference is largely semantic with an emphasis on different terms in different communities. For example, researchers approaching from engineering design typically refer to it as the design process, where as researchers from organizational behavior or business strategy will typically use NPD. In this thesis I shall use both design teams and NPD teams interchangeably.

of these failures is making products that people don't really want or need. To help avoid this, the first challenge for NPD team is to frame the design challenge based around real user needs. I set out to find out how to do this better.

Yet while most NPD and design research focuses on process, I found that process alone didn't account for the difficulties NPD teams encounter. As an engineer by training, I have spent many years making products, devices and systems to meet the specifications given to me. If something needs to be designed to withstand 300Mpa of stress and fit within a defined space then engineers harness all their creative and professional expertise to meet the challenge. Sometimes the challenge is too much and we may question the specifications. Does it really have to be 300MPA or is 200MPA enough?

Can I break the system into two to allow me to free up some space? Engineering design can be a highly creative activity, though it is often overlooked as such. Less often, however, do engineers question the entire form and purpose of what it is they're creating. Do we need a device at all? Maybe a service would do? Will people feel comfortable using the product or might they be embarrassed and soon put it to the side?

These kinds of questions are usually tackled by the marketing and strategic leaders in a company. Often then, an engineer's role is more of an implementer, someone who can make it happen and solve some tough challenges along the way.

This approach can work very well. For example, when designing the guts of an engine, the engine seals say, the customer is far away. There are few customers who have bought a car because of the engine seals, but no cars that would work without them. In these circumstances an engineer's work is a technical design challenge. The seals need to be made to work as efficiently and cheaply as possible. I call this Under the Hood Design.

Yet the experience is very different when designing products that a customer touches, uses, relies on, shares, creates perceptions of and associates with. The steering wheel of a car has to turn the wheels easily and reliably yet it also has a greater meaning as something drivers touch each time they use the car. A leather steering wheel brings forth different associations than a plastic one, a pink steering wheel different associations than a black one. The choice of material has functional characteristics -how well you can grip it, whether it heats up in the sun -but it also has other less tangible attributes that play a part in the selfpresentation of the driver. Leather may look sophisticated, but maybe a new plastic would perform better. Replacing a steering wheel with a joystick may prove easier to use; but would the jet plane look be appropriate for a family car? How can designers and engineers begin to make these kinds of decisions? This is Meaningful Design (e.g. Diller et al. 2005). A product's success or failure rides on getting these kinds of decisions right (Zirger and Maidique 1990;Rothwell 1972). Sometimes failure is a result of not realizing the social implications of a product or a feature. Other times what people really want is unclear or misleading.

This perspective is also supported by economic analysis. Technical proficiency is no longer all that is required for businesses to compete in the global marketplace (Pink 2006). The UK's Design Council created an index of over 150 firms recognized as effective users of design and design research. Tracking the stock market performance of these firms has shown that this emphasis on design pays off financially. The Design Index firms outperformed the standard FTSE (Financial Times Stock Exchange) 100 companies by 200% between 1994(Design Council 2008. There is something to be learned from firms that do design well.

Spray sugar, the Segway, the Newton and Powder Net Spray sugar, the Segway, the Newton and Powder Net Spray sugar, the Segway, the Newton and Powder Net Spray sugar, the Segway, the Newton and Powder Net I have repeatedly encountered the difficulties of figuring out the right thing to make in my personal experience as a designer and through high profile cases from respected companies.

Six years ago I worked on a consulting project for a sugar company who derived 90% of their income from selling sugar cubes. But sugar cube sales were dropping as people and cafés increasingly favored sugar granules in small packets. They turned to us to find out what was next -what was the next big product in sugar? Trained primarily as engineers the team approached the problem from a primarily technical perspective. We identified 'problems' with sugar cubes such as speed of dissolving and versatility in sugariness. We used trends of technical evolution from TRIZ (Altshuller 1999) to identify sugar products that would function better, solving some of these problems. A favorite concept of mine was spray sugar.

Sugar in liquid form in a spray container has numerous benefits such as easy application, versatile dosing, an even distribution and instant dissolving. In many ways, technically it was superior to granulated sugar or sugar cubes. But users, and the company, didn't go for it.

Spray sugar didn't feel like sugar. Sugar should be granules, not come out of a nozzle. People felt strange spraying sugar into coffee at a café; it was more what you might do with medicine or cleaning fluid than food. Though in many respects functionally superior we hadn't understood what users really wanted.

I'm not alone in having made errors of this sort. Before its official launch the Segway Human

Transporter was one of the most hyped inventions of all time. As its inventor, Dean Kamen, stated in Time, "The Segway will be to the car what the car was to the horse and buggy," (Heilemann 2001) But it didn't pan out that way. The Segway has remained an invention, not a successful product innovation; it has not yet achieved market acceptance (except by the small number of enthusiasts of Segway polo). While time will still tell if the Segway will achieve its promise, how did the initial forecasts prove so misguided?

The Segway's disappointment can be partly blamed on the focus on technology rather than user needs. The product was built from a technology standpoint and the visions of its creators rather than by first understanding the needs of consumers and creating a product to meet them. Much of the initial hype was due to the secrecy regarding exactly what the project, dubbed Ginger, would turn out to be. Secrecy before development meant that the initial tests of a Segway were based on the experiences and use of the members of the company and close collaborators rather than real users in the context of use. As it turned out, the Segway provided mixed benefits at best to many of its initial intended buyers such as the postal service and the police. The first mail carrier to deliver a piece of mail with the Segway, for example, had this experience: "[Chris] Pesa enjoyed trying out the device, but it didn't save him any time: He couldn't sort the mail between homes as he could when walking his route. And if it rained, it was impossible to carry an umbrella, because you needed both hands to steer." And the police force in the town of its development, Manchester, "found the machines useful for downtown parking control, says department spokesperson Shawn

Fournier, but that was about it. He adds that the mountain bikes his department employs to patrol certain beats 'are cheaper, and they don't have batteries that run out of juice," (Rivlin 2003).

The self-balancing technology of the Segway is undoubtedly impressive, but the user needs it was addressing were weak. In the context of use, the needs were more than just getting from place to place more easily. It was partly this emphasis on technology and engineering rather than users that led to the disappointing Segway sales. In essence, the development team focused on the How of the engineering implementation rather than first being sure about What should be made in the first place. 2 Analyses of product failures are harder to come by than analyses of successful products. A failed product typically doesn't make the news. One that has received much lip-service however, is the Apple Newton PDA (Personal Digital Assistant). The Apple Newton, like spray sugar, and the Segway was a technically advanced product. It was packed with features, software and some of the fastest hardware for its time. The intent was for the Newton to be a mini-computer in your pocket. Yet, the Newton didn't catch on; it remained too big, slow and struggled with handwriting recognition. Ten years after the Newton's demise, Palm Computing's Palm Pilot, learning from their first attempt, the Zoomer, took on the mantel of efficiently replacing users' paper-based personal organizers creating the world's first truly successful PDA. The designers of the Newton created a technically impressive product but misunderstood what was most important to people at the time;

people didn't need a replacement desktop computer, they wanted a replacement for their personal organizers that could be synchronized with their desktop computers (Patnaik and Becker 1999). With less exacting technical specifications, the Palm Pilot was both small and fast enough to do what was needed well.

In Chapter 06 I present more detail on a fourth example, relating the story of Powder Net, 3 a company founded, and even named after, the premise of creating tiny sensors. Tiny sensors are a worthy goal and a technical challenge. Yet the company had to quickly adapt to clients for whom size was not really an issue; they were more concerned about ease of installation, long-life and reliability. Though a focus on size created buzz, what clients really needed for real applications was something quite different. To succeed, Powder Net required a readiness 2 The Segway also faced other challenges that reduced their sales including a flawed sales modellaunching on Amazon where people couldn't try them out -and difficulties with local regulations, for example, getting Segways permission to be rode on sidewalks. For a thorough treatment see (Kemper 2005) 3 The company name has been changed throughout this thesis to listen, adapt and learn from their target market to create a product that is more than a technological invention.

Each of these examples illustrates a core assumption of this research: that it's important for NPD teams to understand the needs of their target users to be able to develop a product that will be of value to them. This assumption is in many ways at the heart of the user-centered design process.

Design is performed by teams Design is performed by teams Design is performed by teams Design is performed by teams

These examples also show that the process of figuring out what a market needs, then engineering a product to meet those needs is not always a straightforward process. In reality, NPD teams are cross-functional -comprising members from the core disciplines of marketing, engineering, industrial design, manufacturing and, increasingly, members from the social sciences such as sociology and anthropology (Squires and Byrne 2002). The backgrounds and perspectives that each of these members brings causes them to see different things as important so that in a negotiation about what a product should do or how it should do it each will address their own interests (Bucciarelli 1994). Figure 1.1, from

Kleinsmann's thesis, "Understanding Collaborative Design" (Kleinsmann 2006), illustrates how different actors in a team bring different viewpoints. The word 'feasible' may prompt an engineer to think of whether a product can be made, a business specialist to consider if the market is large enough, an industrial designer to question if the product can be appealing.

In the early stages of NPD when teams are performing research and testing prototypes with users there are opportunities for different team members to learn different things from these encounters. For example, in a project addressing people's attitudes and potential ways to encourage recycling the team split up to learn from potential customers. The business specialist came back from her encounter more convinced that their offering should be based around a recycling service. The engineer came back convinced that a new type of bin to help sorting was what was needed. And the information specialist felt the solution should involve better communication about recycling. We see what we are prepared to see and different disciplines are prepared to see different things. Bucciarelli's ethnographic studies of the design process (Bucciarelli 1988) highlighted the complex and social nature of design process.

Figure 1.1 Different actors in a development team bring different viewpoints (Kleinsmann (2006), used with permission)

These differences of opinion often result in conflict and changes of direction for the project. In other words a project does not always end up being what was expected at the start. Diversity in teams can be very valuable (Page 2007) and in NPD teams diversity in skills is essential to success. Diversity in teams has been shown to enhance creativity, complex thought and thoughtful decision-making, yet it also has costs such as conflict, inefficiency, and failure to share non-redundant knowledge (Stasser and Titus 1985;Reagans and Zuckerman 2001;Nemeth 1986;Dougherty 1992;Chatman et al. 1998;Ancona and Caldwell 1992). This essential diversity creates conflict as the members of a team seek to come to a shared understanding about who their target market is, the needs of their users, what it is they are making and how it should be made.

In this thesis I seek to illuminate how teamwork plays out in the context of user-centered design as NPD teams perform the early stage activities of the NPD process -scoping the situation, performing user research, understanding user needs, and negotiating what the team should make; in other words, framing the design situation. Some teams work together to successfully frame the design situation around real user needs and develop a project that their target market really values; others frame the situation in a way that eventually creates a product that people don't want, remains "just a gadget," or is soon discarded.

Research questions Research questions Research questions Research questions

Throughout this thesis I define framing as consisting of four primary features:

1. A desired end state or goal 2. Relative importance and relevance of features (prioritization of designers' attentions)

3. Boundaries to the design situation (problem scope, solution scope, resource constraints) 4. Criteria for evaluation (of new information, features, and possible solution concepts)

I will return to this definition in Chapter 02 to place it in context with alternative views and studies of framing in design. A team that has come to agreement on these four features is

generally clear about what it is they need to do. Successful framing, I will argue, requires that these aspects are chosen based on real user needs from grounded observations with real users.

To understand the role of framing in design I gathered data from a student design setting and from professional designers to answer the following primary research questions: 5. What role does framing play in successful design?

6. How do design teams settle upon a suitable frame for their design situation?

7. What tools could help support design teams to better understand and apply the framing process towards successful design?

This thesis is roughly organized to address these questions in order.

Contribution of this thesis Contribution of this thesis Contribution of this thesis Contribution of this thesis

The primary contribution of this thesis is to untangle the dual dimensions of framing a design situation successfully, and whether or not the NPD team is on the same page about that framing. A deeper understanding of the complexities of this process allows me to recommend a set of themes and design principles for teams aiming to negotiate the early stages of NPD.

To arrive at this endpoint I hope to also make five other contributions.

1. First, through an investigation of the lessons NPD students learn during an NPD class I highlight the value of experience working in multidisciplinary teams and the difficulty NPD teams have in effectively framing the design situation.

2. Second, I identify the primary set of activities that are themselves framing activities.

To understand the influence of these activities I propose the Framing Cycle which illuminates how teams negotiate a shared frame during the design process.

3. Third, I introduce the Design Path framework built from the dimensions of framing the design situation according to real user needs, and the degree to which a team is on the same page. I illustrate the framework by showing the three most common paths that design teams follow. 4. Fourth, I highlight the role that metaphor plays in our understanding of the design process and the contrast between traditional text book models of the design process and how design is experienced in practice. By contrasting metaphor with analogy, I

show how metaphor is used as an effective framing tool early in the design process.

Thesis outline Thesis outline Thesis outline Thesis outline Below I outline the content and contribution of each chapter. While the thesis will prove most readable when read sequentially I have tried to write each chapter so that it can also be read as an individual contribution.

In Chapter 02, Background, Chapter 02, Background, Chapter 02, Background, Chapter 02, Background, I begin by discussing the different strands of research that have tried to address issues relevant to this thesis. I discuss different approaches to the design process and introduce and define the notion of framing as it applies in NPD. I also introduce prior research on the formation and negotiation of shared understanding in design teams.

This chapter places my work in the context of research that has come before it.

In C C C Chapter 03, Methodology, hapter 03, Methodology, hapter 03, Methodology, hapter 03, Methodology, I discuss the advantages and disadvantages of the research methods available to design researchers studying framing. I present the justification for my hybrid approach of gathering data from student NPD teams and interviews with industry professionals.

In Chapter 04, Chapter 04, Chapter 04, Chapter 04, Lessons Learned in NPD Lessons Learned in NPD Lessons Learned in NPD Lessons Learned in NPD, , , , I present a study of the lessons NPD students chose as the most salient to them after a NPD course. This study provides further evidence for the importance of helping multidisciplinary teams work together and to provide tools and understanding for effective framing based on user needs. In this chapter I discuss framing in the context of where it fits in the design process and how it has been studied in the past. I begin by introducing the notion of design as a wicked problem, one not easily amenable to traditional design methods. In this respect much of the important work of design is in the problem-setting rather than problem-solving. Then, I review a number of different approaches to the user-centered design process that enable us to design in spite of design's wickedness, and discuss how other researchers

Introduction Introduction Introduction Introduction

New Product Development (NPD) is a multidisciplinary activity that affects business success and requires engineering skill, industrial design talent, careful management, the skills to understand people and an understanding of team processes and dynamics. As such, design research exists in and has drawn from many fields of endeavor including the fields of marketing, engineering, software development, organizational behavior, psychology, cognitive science, anthropology and sociology. An engineer, like myself, wishing to study the NPD process must therefore begin a rapid schooling in deep and unknown fields. For example, a recent meta-analysis of papers published in marketing, business strategy and NPD journals (Page and Schirr 2008) found that studies of NPD have continued to increase over the period from 1989-2004. In particular, teams and the integration of different functional roles and disciplines continues to be the most popular stream of research accounting for 14% of the total papers published during this period. This cross-disciplinary nature of design makes the contributions so numerous it would be impossible to review them all here. In this chapter then I attempt to set the scene for this research by limiting the discussion to the most relevant prior streams of research.

I begin by taking a historical perspective on design theory emphasizing, in particular, the notion of NPD as a wicked problem. I then discuss the design process I studied -the usercentered design process, which evolved partly to resolve some of the difficulties in traditional linear, analytic design approaches. I then discuss the two core areas of this thesis, the framing of a design situation and previous studies to understand how framing is accomplished in cross-functional design teams.

Wicked Problems, problem Wicked Problems, problem Wicked Problems, problem Wicked Problems, problem----solving and solving and solving and solving and problem problem problem problem----setting setting setting setting Design is often associated with problem solving. The literature on problem-solving is broad and deep. A strong theme however, is that problems are readily addressed using rational, analytic techniques. In contrast to this view, in 1973, Rittel and Webber characterized the social policy problems associated with urban design as wicked problems (Rittel and Webber 1973). These types of problems are not readily amenable to standard analytical problem-solving processes as they are ill structured and poorly defined. In these situations, problem setting leads just as much to the solution as the problem solving. The problem formulation itself is the problem. The concept of wicked problems was proposed in response to the then dominant rational problem-solving methodology as exemplified through the research of Herbert Simon (e.g., Simon 1969 and. This is more than just a case of these kinds of problems being harder problems. It is an issue to do with our very conceptualization of a problem, the elements it contains, where we start, at what level we address it and how we know when we've solved it. Indeed, Rittel and Webber persuasively argue that solving a problem in these situations is not wholly relevant, as a once and for all solution is not possible.

Rittel and Webber provide ten common characteristics of a wicked problem including, for example, there is no definitive formulation of a wicked problem. In other words, a wicked problem is one that will be formulated in different ways by different people at different times. Dorst (1997 70) explains:

"design tasks may be analyzed and subdivided in a number of different ways, and there is no a priori way to determine which approach will be the more fruitful. Therefore, design task and solution are always and inherently developed together."

Other characteristics of a wicked problem are listed in Table 2.1. Of particular relevance are wicked problems don't have an enumerable set of possible solutions, and there is no immediate or ultimate test of a solution to a wicked problem -solutions are not right or wrong, they are only better or worse. Experience in NPD may quickly tell you that many of these characteristics also apply to NPD projects. For example, an ideation session for an NPD project can never claim to have exhausted every possible option, in contrast to, for example, determining what next moves are possible in a game of chess (a classic problem-solving challenge). Testing of NPD projects is also fraught with difficulty. For example, testing of Research in Motion's Blackberry phones most likely did not anticipate the addictive effect of their long-term use and the future nickname, 'Crackberrys'. Indeed, understanding the real impact of the introduction of a new product is very difficult when the response is affected by the uptake and attitudes of the rest of society. For example, the Microsoft Zune mp3 music player featured wireless peer-to-peer sharing between Zune users, yet the success of a such a feature is largely dependent on how many other people nearby own Zune players. Evaluating this feature is difficult and likely to be misleading in an artificial pre-product launch scenario.

Twenty five years after Rittel and Webber's original paper, DeGrace and Hulet Stahl (1990) argued that software development problems are also worthy of the moniker of wicked problems. Here I argue that NPD can also be seen a wicked problem. If NPD is wicked then problem-setting is key. According to Rittel and Webber then, traditional rational problemsolving approaches will not be appropriate for design teams trying to develop new products.

To address wicked problems Rittel advocated a need for what he termed, 2 nd Generation Design methods (1984). These design methods emphasize the argumentative and social nature of team design as opposed to earlier rational and analytic approaches. Yet specific details on how teams should go about these 2 nd Generation Design Methods remain slim.

A key reason for the need for Rittel's approach was based on the renewed emphasis on people in the design process, as stakeholders, customers, end users and designers. If we recognize that these people will not see things identically due to different values, interests, beliefs and such, then it is no longer possible to design with a purely technical problem-solving approach. The wickedness of the design situation arises through the combination of these perspectives involved in the design process, hence the need for an argumentative approach to designing. The existence of a discrepancy representing a wicked problem can be explained in numerous ways. The choice of explanation determines the nature of the problem's resolution 10

The planner has no right to be wrong More recently, Donald Schön's paradigm of reflective practice has been widely adopted by design theorists to understand design activity. Reflective practice is a model of design based on the study of practitioners and a framework through which to analyze design activity. It is based around the metaphor of Design As A Reflexive Conversation 4 with the situation.

Designers, Schön argues, follow a cycle of Naming, Framing, Moving and Reflecting. As an example, a designer developing the layout for the inside of a new café may first name the important needs the layout has to fulfill such as an area for ordering, an area for waiting, an area for relaxing, a private and communal area and so on. These named features may only become apparent in conversations with potential patrons of the café. The designer then frames the situation as a goal of providing maximum private area for relaxation while providing easy access for ordering and leaving. The designer then makes a move, maybe a sketch, a prototype, a thought experiment, a scenario or a role-playing exercise. As the designer considers the result of her move, maybe through studying her own sketch of the layout, she reflects on how well it achieved her aims. This reflection, in turn, may prompt new features to be noticed as important, maybe access to the restroom, or an alternative framing of the situation. In this context then, problem-setting is a continual process that cannot be easily separated from the development of possible solutions (moves). This coevolution of problem and solution has also been observed elsewhere. For example, (Dorst and Cross 2001) report a protocol analysis study of industrial designers working individually on an artificial design task. In their study they highlight the co-evolution of problems and solutions where "a creative event occurs as the moment of insight at which a problemsolution pair is framed: what Schön called 'problem framing'."

In Schön's paradigm then, framing is a key skill of a designer. Other authors have also emphasized design as a problem-setting activity. For example, Lanzara (1983) Cooper (1998) and, to some degree, Ulrich and Eppinger (1995), outlines a largely sequential design process, one in which teams perform activities with stage gates as decision points and milestones to encourage design teams to make concrete decisions and move forward. The process outlined in Ulrich and Eppinger (1995) is shown in Figure 2.1. Ulrich and Eppinger (1995) While the process model appears linear it is acknowledged that design teams will perform a large amount of iteration during a project, with the result that an actual development process will not map cleanly to the stages above. Design teams follow a series of divergent and convergent phases as they iterate to a final result (Boehm 1995). In particular, the earliest stages of the design process are characterized by incomplete information leading to a high degree of uncertainty and ambiguity for product development teams (Iansiti 1995;Eisenhardt and Tabrizi 1995). Cycles of divergence and convergence and iteration are ways that allow teams to cope with this uncertainty. These early stages are commonly called the 'fuzzy front-end' of new product development (Khurana and Rosenthal 1997), and it is in these early phases that important decisions are made that have a strong impact on the project outcomes (Cooper 1998). Not only are decisions made in these phases that have important effects such as on the development cost for a new product, but it is in these phases that new opportunities themselves are identified.

Studying design team framing in the user-centered design process presents a unique set of challenges. And it is critical to select a research approach matched to the phenomena being investigated. To explain my approach to studying design team framing I begin by discussing the criteria for evaluating a suitable research approach. After comparing typical approaches against these criteria I present my approach: a hybrid of studying many student design team projects together with interviews with professional designers and an industry case study.

Criteria for a research approach Criteria for a research approach Criteria for a research approach Criteria for a research approach Two primary goals for choosing a research method are to ensure we give ourselves the opportunity to observe and study important events in the design process, and also to have confidence that our findings will be applicable beyond the immediate study setting. In my case I am interested in informing both design practice and design education. If a researcher both sees the important events and is confident they can generalize at least to a larger subset of real design practice then they are in a good position to provide recommendations. To achieve this goal I believe design research methods must meet three criteria before they can provide solid recommendations for designers.

Metaphor and analogy are often confused. Indeed it is not uncommon for them to be used interchangeably. However, as I shall show, there are important differences between analogy and metaphor and how they are used in design. In presenting this study I shall first provide definitions for both analogy and metaphor as they relate to design practice. I will then describe a study that brought together two sets of data to determine the role each plays in problem framing and concept generation. The study was conducted jointly with Alice Agogino at the University of California, Berkeley, and Julie Linsey and Kris Wood at Texas A&M University.

Development

Stage gate user-centered design models typically follow the generic design stages of: Identify user needs -Generate concepts -Select concepts -Detailed Design -Manufacturing and ramp-up. Distinctive at least of the user-centered design process is the emphasis on an initial understanding of user needs -to understand what needs the product must fulfill. It is generally acknowledged that a team who uncovers latent, implicit, or hidden, needs may have a greater design opportunity than teams that identify surface level, explicit, well acknowledged needs. Campbell's customers' need to eat is a surface level need, but the need to maintain their pace of life over lunch may be a hidden level need (albeit only just below the surface).

Software development has developed its own variations of a user-centered design process including the Waterfall model (Royce 1987) and its successor the Spiral model of software development (Boehm 1995) (itself a facilitator of modern practices such as agile software development).

Design processes from contemporary design practice Design processes from contemporary design practice Design processes from contemporary design practice Design processes from contemporary design practice In design practice, as design firms aim to move higher up the food chain, innovation on process continues at a rapid pace. Respected companies and researchers working in the area of new opportunity recognition have developed their own frameworks and processes for the early stages of product development. In many ways, these processes apply only to the first few stages of the Ulrich and Eppinger design process, identifying the what to make rather than how to do it. In other words, they are not so concerned with the challenges of detailed design and manufacturing that takes place in the later stages.

These processes emphasize a highly people-centered approach to design advocating intense user research as a source of insights for new product and service offerings. Frequently these processes emphasize the non-linear, highly iterative nature of the process encouraging their teams to bounce between making ideas concrete in the form of prototypes and continually testing with users the insights and concepts throughout the process. Beckman and Barry (2007) (derived from Owen 1993 and, and Kelley and Littman at IDEO (2001). It can be seen that these design processes, though using different terms, have at least two common features. First, teams engage in both analysis -deconstructing and understanding a situation -and synthesis -putting together insights to produce concrete design solutions and directions. Second, teams are expected to alternate from the concrete physical world, the world of observations, products and behaviors, to the abstract, theoretical world where frameworks, models and metaphors are used to help explain the concrete behavior. Beckman and Barry (2007) argue that these basic models can also be seen as one of problem finding, problem selecting, solution finding and solution selecting. They explain that, "Much of the focus of education today -particularly engineering education, but also business education -is on problem solving. The innovation process emphasizes problem finding as well. Identifying, framing, and reframing the problem to be solved are as important in this process as solving the problem or finding an appropriate solution" (Beckman and Barry 2007 44) Design ethnography has become a widely touted method for design practices following these approaches (e.g. BusinessWeek 2006; Elliott and Jankel-Elliott 2003). Design ethnography employs methods such as in-depth interviews, shadowing and participant observation to reach deeper insights about a target population. Mariampolski (1999Mariampolski ( 75, also 2005 usefully compares a shift of using ethnography for market research rather than focus groups to moving from black and white to color: "Going from focus groups to ethnography is somewhat like moving from black and white to colour -the immediacy of the smells, textures, tastes, heat, sounds, movements, and muscular strain all stimulate an enriched level of understanding. If the research objective is to understand consumer shopping patterns, the ethnographer can tag right along at the supermarket or department store. If we need to understand home cleaning patterns and products, ethnography allows the researcher to sniff the air around the home, stare at hairballs on the sofa -actually to see the success or failure of product performance and share the consumer's look of satisfaction and pride after a job well done."

The use of ethnography in design strongly emphasizes the skill of observation. This is largely due to some consensus that people don't always do what they say they do nor directly know why they do what they do. For example, in an analysis of data in a wide variety of settings, researchers concluded that:

"what people say, despite their presumed good intentions, bears no useful resemblance to their behavior" (Bernard, Killworth and Sailer 1982 63) When it comes to predicting long-term purchasing behavior consumers are also unreliable (Ovans 1998). Beckman and Barry (2007), give as an example a study conducted on families' TV watching habits. Parents repeatedly said they didn't allow their young children to watch violence on the TV, but when they spent time with the families the researchers saw the children were regularly exposed to violence. The parents weren't intentionally lying -as the researchers discovered, it was more accurate to say that parents didn't let their kids watch something that would give them nightmares. Framed in this way violence in cartoons and movies can pass the parents' censorship. In other words, the observations allowed the design researchers to frame the situation in a way the behavior made sense.

User-centered design approached using techniques from design ethnography is sometimes termed needfinding (Patnaik and Becker 1999). User needs and insights from design ethnography are the foundation of the remainder of the design process. However, design ethnography takes time and resources. It is not generally possible to get close to the year or more length studies of academic ethnography. In response to this important conflict between quality of research data and the length of time available, various methods have been proposed including rapid ethnography and quick and dirty ethnography (see Sandhu et al. 2007, for a comparison of some of these approaches).

A study of modern design practice needs to study design teams as they engage in the activities of design ethnography and identifying user needs. Until now, there are very few studies of design teams performing design ethnography for NPD.

Other design process models Other design process models Other design process models Other design process models Readers familiar with contemporary approaches to innovation in, for example, Web 2.0 5 software startups may disagree with the kinds of design processes I have outlined above. As one MBA student commented, "It's not how I see it happening. People have an idea and they try it. If it doesn't work, they change it or try another." This approach, in essence, short circuits the NPD process by skipping the first stages of user research, analysis and even generating concepts. The startup forms based on a seemingly spontaneous idea developed by the founders based on a personal insight about a market need or a new technology. For example, based around the founder's liking for the convenience of alarm wake up calls at hotels they have the insight they could create a service to allow users to set up their own alarm wake up calls from the Internet. The team spends an intense few months developing a prototype site to see if it takes off. If it doesn't, the idea is simply adapted or abandoned. In some senses, this kind of approach is also in use by large web-based firms including Google.

The Web 2.0 model is very much a build it and see approach.

Although I have not formally studied this approach I believe this approach is particularly fruitful in the world of Web 2.0 development because of a number of contextual features of this environment. In comparison to the development of physical products a number of constraints are starkly different. First, the development overhead is lower including capital expenditure required. It is generally cheaper to host a website and code some web pages than it is to get a functioning physical prototype built for, say, a new kind of bike. Secondly, prototyping is generally cheaper and quicker. A talented web development engineer can, in many cases, mock up several different at least partially working designs a day compared to the several weeks it may take to machine a new metal component. Web development projects also have the advantage of being closer to eliciting feedback from users and collecting use data through tracking user's actions on a site. In a connected world, users are more likely to provide a quick note of feedback on an online service than they are likely to return from a biking trip and call up the company who designed the bike. Finally, small web startups, until recently, often make products for users like themselves -in other words, they are a potential user of their product. When this is the case, developers can rely less on user research as they can legitimately claim to know much of what is required of their product. For instance, in a talk at Startup School at Stanford in 2006, Joshua Schachter explained how the development of the social bookmarking site del.icio.us was initially a product to help him better manage his own bookmarks. When that need is shared widely enough it is reasonable to develop based on your own perceptions of what is needed. Yet, as Nielsen (2008) persuasively argues with a typology of designers' role as potential users (The Designer is the user, The Designer Understands the Product, and Designing for a Foreign Domain), this is rarely the case.

Finally, the internet is also relatively new meaning customers are perhaps more likely to forgive occasional errors than they are in more established domains such as the automotive industry.

Each of these factors reduces the barriers to prototyping, testing, and getting feedback from users. With lower overheads a web development firm can also sustain itself longer on a lower budget as development continues. The factors combine to reduce the risk in failure for these products. If you build it and see that it does not take off you live to fight another day. This approach is also known as the express-test cycle. In contrast, when a working physical product requires a $100k injection mold to build it, the risk greatly increases and therefore the need to be more certain that what you are doing is correct before you do it. Finally, large product development firms cannot easily afford to develop products that may negatively affect their brand. For this reason also, the build it and see approach is more generally suited to startups. Fortunately, in the realm of physical product development advances in the speed and the reduction of cost of rapid prototyping machines (Wright 2000) are continually working to lower the cost between idea and realization. This will enable more and faster trials to be produced at less risk; to help designers fail early and often (Kelley and Littman 2001). This discussion has highlighted the important role of reducing risk in NPD. Indeed, Ulrich and Eppinger (2005) explicitly discuss the NPD process as one of reducing risk.

Effective user research, design ethnography, prototyping and product trials all help reduce product development risk by increasing confidence in the final choice of product.

My research has not investigated the build it and see entrepreneurship model. Indeed, the design process models I have presented here are only the most relevant to current New Product Development. My research studies design team framing as teams follow a usercentered design process for new product development. This is as opposed to framing specifically for software development, or in any one particular domain such as interaction design or engineering design. I now return to the conceptual notion of framing, to more clearly define it and present an overview of what we already know through prior studies.

Framing Framing Framing Framing

Framing has been investigated as part of the design process, and more generally for how frames influence work in group and social settings. Researchers from the fields of sociology, urban planning, engineering, linguistics, cognitive science, management science and organizational behavior have all called attention to the concept of framing or a related construct. Yet despite the attention devoted to it, definitions of framing remain scarce (Stumpf and McDonnell 2002). Before I present how framing is understood in my research it is worth briefly reviewing prior conceptions of framing. Bateson (1972) gives an early analysis of framing 6 where he sees the value of a frame as providing semantic context. The same action performed in different contexts can mean quite different things, for instance, the toss of a coin could be seen as a lighthearted game or result in a life or death consequence. He further compares frames to the mathematical notion of sets to help distinguish between information communicated about the frame or within the frame. In a sense he sees a frame as creating the dividing line between where objects of some type belong and others don't. In this sense, frames are a boundary-setting tool, allowing us to make decisions about what information or actions are meaningful. Goffman (1974)

drew from

Bateson's ideas to develop his idea of framing as it applies to social situations. In Goffman's view, frames are the rules and parameters that govern social encounters. He employs, for example, a theatrical metaphor of front stage and back stage that governs interactions in many service based settings. For instance, when an employee is front stage in a café they wear a uniform appropriate to the brand, treat the customers with respect and refrain from activities like smoking. However, maybe behind the building, you may find that same employee smoking against a wall with his shirt untucked; he is engaging in back stage behavior. Goffman also introduces the concept of keying which includes markers for when a frame starts and ends. Particularly instructive when analyzing social behavior are situations that result in breaking frame -someone shouting in the dentist waiting room, a teacher berated by the principal in front of his students, or simply elements of back stage behavior performed front stage, such as our café employee smoking as he makes a cappuccino (see Fisher (1997) for a good overview of the different interpretations of framing).

Framing is a process of sensemaking. In her thesis, Valkenburg defined framing as "sensemaking devices that establish the parameters of a problem," (Valkenburg 2000 174).

The notion of frames as sensemaking devices mirrors the perspective of Weick (1979) who studied sensemaking in organizations. Sensemaking is closely related to story telling as stories are ways that help us make sense of the world and persuade others of our point of view (Bruner 1992;Simmons 2006). For example, a recent buyer of an SUV may justify her purchase by telling the story of needing the powerful engine and four wheel drive for trips to the mountains when really the purchase is driven by her experience of feeling safe in a larger, higher vehicle. The story forms the rationale behind their decision. Designers do this too; Stumpf (2001 71) explains that she sees frames as forming "the context of what is considered and a form of 'rationale' detailing why an artifact was designed the way it was."

Bucciarelli also touches on the notion of frames in his concept of 'Object Worlds'. He describes the object worlds of different design disciplines as "worlds of technical specializations, with their own dialects, systems of symbols, metaphors and models, instruments and craft sensitivities," (Bucciarelli 1988). In this way, members of a design team, arrive at a design situation with a readiness to distinguish certain aspects from others and to see different elements as important.

Probably the most complete discussion of frames and framing is developed by Donald Schön.

Schön describes frames as "underlying structures of belief, perception and appreciation" (Schön and Rein 1994) and framing as an activity carried out to construct meaning. Schön sees generative metaphor as a means to frame a situation. He describes frames as a way of 'seeing-as' -seeing one thing through the lens of another. An example he gives is an urban planning problem where the framing of a slum as either a 'blighted area' that needs to be cured, or as a 'natural community' that should be preserved, significantly changes the design situation itself. The choice of metaphor -the Slum As A Blight or the Slum As A Community -evokes a different framing of the problem. I shall revisit this perspective of generative metaphor in Chapter 07: Metaphors and framing. The link between metaphor and framing, in contexts outside of design, is discussed extensively by Lakoff (2004) and Lakoff andJohnson (1980 and.

A definition of framing A definition of framing A definition of framing A definition of framing

The different rhetoric surrounding framing should not obscure that most of these researchers are talking about the same construct -different though the language may be they are "internally consistent" (Stumpf 2001 Because most definitions emphasize the tacit "underlying" nature of frames, studying frames and their evolution is a challenge. Here I propose four key constituents of a frame that allow them to be identified and tracked throughout the design process: Studying framing in the design process Studying framing in the design process Studying framing in the design process Studying framing in the design process Schön (1984) used a form of narrative analysis to analyze the contrasting frames a student designer and his mentor brought to a design review and how they interacted to produce the final design. The review highlighted the evolution of the design as the student designer named elements in the situation and gave names to their design strategy. In particular, this study emphasized the importance of shifting frames when a problem became unworkable in one framing.

In an empirical study of design student teams, Christiaans (1992) found that the longer a subject spent defining and framing the problem the "better able he/she was to achieve a creative result." Despite this conclusion it is not clear exactly what designers should be doing when they spend more time defining and framing.

Later, Valkenburg employed Schön's paradigm of reflective practice, developing a coding notation based on the stages of naming, framing, moving and reflecting. In a study, Valkenburg and Dorst (1998) coded the activities of two design teams in competition using the notation to identify how and when a team's framing of the situation changed. The study analyzed video footage of the two teams working over a period of two days and was able to identify changes in frame of the design team. While demonstrating the ability to identify changes of frames was a step forward it is difficult to draw from the study precisely what teams should do differently. Gasson (1998) adopted an ethnographic approach in which she observed the course of a product development project in the telecommunications industry. In the analysis of the project she discusses design framing at the individual and group level noting that the team experienced a "framing problem" due to the decompositional design approach the team adopted -an analytic approach of breaking a problem down into sub-problems and separate design stages. The team's design approach struggled with the "intertwining" of problem and solution, a situation common to wicked problems.

An alternative, practice-based approach at the Stanford d.School advocates that teams adopt a Point Of View (POV). A Point Of View concisely states the relationship between a user and a need 7 . For example, "Campbell's Soup is Tom's quick-and-always-on-hand meal." Examples of these POV are close to what we would identify as a frame.

These prior studies show that framing applies at multiple levels: at the level of the individual (how a particular designer views her task), at the team level (how a team collectively views its task), and at the organizational level (a company's perspective on its business and the value it provides for its customers). My interest here is primarily on the framing that occurs at the team level. As I shall show, framing at the team level rather than the individual level provides an additional level of complexity that cannot be ignored when attempting to understand framing throughout the user-centered design process.

Team framing Team framing Team framing Team framing While understanding framing at the team level may not immediately seem to present particular challenges for design teams it turns out the situation becomes substantially more complex. Bucciarelli provides as an example to consider the page (or screen) in front of you (Bucciarelli 1988 163): "It is an object. A naïve empiricist would sense its weight and measure its size. Another reader might note its colour or its texture. A chemist on the design team would describe its resistance to discoloration and its acidity. A mechanical engineer would be concerned with its stiffness and its thermal properties; an electrical engineer with its electrical properties, its ability to conduct or to hold a static charge. All of these attributes of the object are understood within different frames of reference and they all might contend in a design process, e.g. in the design of the machinery for the manufacture of the paper, or in the design of the paper itself."

Much of the complexity in team framing then is a direct result of the diversity of crossfunctional design teams. When individuals enter a group setting they do so with different perspectives, viewpoints, and interpretations of the issues involved. These differences "interfere with the ability of the group to view issues in similar ways" (Mohammed 2001 408) and decide on a common action. As a result, a substantial part of the collective effort of a team is dedicated to resolving differences in how members interpret issues, and, indeed, in which issues are important. Mohammed further argues that "the process by which individual interpretations translate into collective interpretations has not yet received systematic attention." Divergence between member's frames may be greatest on highly interdisciplinary teams meaning that issues of team framing are particularly relevant for usercentered design projects. As Boos (2007 26) explains, "Each participant is an expert in their specialized field. Based on individual experience, professional training and acquired knowledge, each participant will most likely view the task differently." In this thesis I hope to have provided some of the attention that was lacking.

Frames are cognitive and often implicitly held by individuals; that is they exist, often unconsciously in the minds of individuals. This hidden aspect of frames makes them particularly challenging to study in the team context where an understanding of different members' perceptions is not easily accessible (in contrast to, for example, think-aloud studies of individual designers). While there are studies of framing in design at the individual level (e.g., Schön 1984), studies of design team framing at the group-level and how that negotiation is achieved are rarer. Yet team framing activity has received much attention from researchers in decision-making, organizational behavior, management and psychology. Klimoski and Mohammed (1994) provide a bewildering array of related terms used across different studies including: group cognition, collective causal maps, collective interpretation, intersubjectivity, organizational consensus, strategic consensus, cognitive consensuality, coincident meaning, group belief structure, collective cognition, shared frames, shared meaning, shared understanding, negotiated belief structure, shared (mutual) models, collectively produced frames of reference, social cognition, group culture, shared mental models and collective mind. Once again, the language is intuitively coherent, yet precision is often hard to come by, and where precision is found it is rare to find it combined with a holistic perspective. The outcome of this research is, at the least, an emphasis that the negotiation of a shared team frame, or, more colloquially, 'getting on the same page', is an important part of successful group processes. Another outcome is the insight that there is a lack of clarity regarding its definition, with different researchers proposing that what is shared between group members may include beliefs, attitudes, assumptions, values, understanding, frames of reference, concepts, relationships, metaphors, commitment, interpretation, perception, content and framing. Mohammed (2001) folds the different strands of related research into the term cognitive consensus, the degree of similarity among group members regarding how key issues are defined and conceptualized.

The majority of studies on team framing (or related concepts) allow us to learn about group activities in general but fewer studies are specific to design and new product development. In particular, many studies are of control situations such as air traffic controllers, yet how design team framing affects tasks in uncertain, complex and non-routine situations such as design is still only poorly understood ). Mohammed (2001) provides 9 propositions based on prior research on team framing for the expected implications for team practice. These propositions include the expected implications of: different backgrounds; commitment to positions; group size; unanimous decisions; decentralized leadership; failed attempts; discussing underlying reasons; implementation; and repeated engagement. While in the abstract these propositions make intuitive sense for the actions of teams, the generalized implications remain difficult to translate to the specific context of user-centered design. I shall therefore briefly review some studies where researchers have explicitly attempted to understand design team framing.

In the literature on product design teams, the negotiation of shared frames has sometimes been interpreted as the formation of shared understanding. Shared understanding is necessarily a group-level phenomenon. Song et al. (2003) building on techniques developed in Hill et al. (2002) used the measure of semantic coherence calculated using the linguistic technique Latent Semantic Analysis (LSA) (Landauer et al. 1998) as a proxy for shared understanding measured from design documents (for a justification of this approach see Dong 2005). They found that high performing teams enjoyed high semantic coherence just before stage gates, but cycled between low and high semantic coherence in between, generally ending with high semantic coherence at the end of the process. This pattern was also seen to be true from measures derived from sketches and surveys of design team members . In management, Kilduff, Angelmar and Mehra (2000) found that top performing teams exhibit high cognitive diversity, in terms of their interpretations of a project, early in the project, but later converge on a common understanding. Whelton (2004) also outlined how the negotiation of a shared frame is vital to the outcomes of team design processes during the management of construction projects.

In another study of the conceptual stages of design, Stumpf and McDonnell (2002) used argumentation as a basis for a coding scheme to analyze design team transcripts. They were interested in the negotiation that takes place within design teams as to how the team settles upon a shared frame. The authors identified frame shifts during the design activity and highlighted the difficulty of representing different 'levels of frames', or levels of abstraction, in order to discover frame conflict between members -that is, team members viewing the situation from different and conflicting frames. The focus of this study was not solely the framing activity but also on designing tools to support the experiential learning cycle (Kolb 1984) of design teams in line with a view of the innovation process as a learning model (Beckman and Barry 2007).

More recently, Kleinsmann (2006) used the 'learning history' research method to analyze two industry design projects, a retrospective pilot study, and an explorative observational study.

Her study provided insight into the barriers and enablers for the creation of shared understanding at the actor, project and organizational level. Like Kleinsmann, several other researchers have investigated team mental models in field studies (see Lim and Klein 2006;Mathieu et al. 2006;Smith-Jentsch et al. 2005;Waller et al. 2004). However, these studies are not specific to design teams.

As some of these studies have shown, high shared understanding throughout the length of a project is rarely optimal. To illustrate this, Mohammed conceptualizes cognitive consensus as a continuum of sharing shown in Figure 2.3: "At one end of the continuum, many incongruent interpretations coexist and frames are entirely idiosyncratic. In the middle of the continuum, frames are widely held. At the other end of the continuum, there is perfect convergence and every group member has an identical frame of reference. In general, the extremes of this continuum are considered dysfunctional," (Mohammed 2001 411) Boos (2007), who discusses optimal sharedness for effective group performance, suggests that effectiveness and sharedness vary according to a bell-shaped curve. Other metaphors, beyond convergence, used to understand team framing include assessing the alignment or overlap of individual frames. It is often argued that differences in opinion help a team find more creative solutions, the accepted wisdom being that a team with similar opinions and experiences will explore less of the solution space.

Figure 2.3 A continuum of cognitive consensus

My research studies framing at the team and individual level in the context of the usercentered design process. As I explain in the next chapter on Methodology, I build off the specific definitions provided above while combining this with a holistic perspective on the project drawn from personal experience and the story of the design path as told by the design teams. Below I will reiterate some of the major unknowns that still remain after this review of prior research on framing.

Research questions revisited Research questions revisited Research questions revisited Research questions revisited

With a better understanding of the historical context of framing, approaches to the design process, the user-centered design processes investigated in these studies and prior studies of team level framing we are now in a position to revisit the research questions that guided this thesis.

1. What role does framing play in successful new product development?

Few prior studies were able to provide guidance on what role framing plays in successful design as opposed to average design. In this context by successful design I mean the development of new products that are well received and have strong potential to be adopted by users. Through my study of many design teams' activities I am able to discuss the role framing played in the final form of the design and its evolution in both successful and less successful projects.

2. How do design teams settle upon a suitable frame for their design situation?

Systematic attention is lacking for the study of how individual team members' frames converge or align. Through an understanding of the twists and turns of a design team's path from the perspectives of each of its team members I am able to bring structure to the otherwise confusing and amorphous process of teams negotiating a shared frame.

3. What tools could help support design teams to better understand and apply the framing process towards successful design?

With an improved understanding of the framing process I am able to address a lack of concrete directions for design teams for effective framing. My studies allow more actionable guidelines by providing a theoretical foundation for design teams to understand the framing process and potential pitfalls as well as specific themes and principles for effective framing.

Onwards Onwards Onwards Onwards

Although framing has been investigated across multiple fields the implications for usercentered design teams remain confused. What exactly are the implications for the early stage research and sharing activities that teams perform? How should design teams share their research with their team? What does research on framing suggest that teams do when making decisions on which needs to address or when they're deciding between concepts?

What activities give teams the greatest difficulties and divergence in frames? It is understanding and recommendations at this level that are still lacking for really learning from research on framing. Rather than generalized abstract advice design teams require concrete guidance derived from solid theoretical and empirical foundations in order to change their practice.

Having covered the background regarding framing and the context of my research, in the next chapter I will discuss what is required of a suitable approach to studying design team framing and explain my choice of research approach and data collection methods. research with the three criteria of realism, access to data and quantity. I chose a hybrid approach to understand framing that combines many small scale, in-depth cases studies with graduate student design teams together with interviews with professional designers and an industry case study. This approach provides excellent access to data, close to realistic design situations supplemented by insight into real design cases, and the benefit of comparing many cases with each other from over 60 design projects.

In this chapter I highlighted the important and pervasive influence of both individual and shared frames throughout the early stages of NPD. I also identified the activities that support the negotiation of shared frames and provided real examples of effective and lesseffective means of carrying out these activities. In particular, I emphasized the role that concrete user data, effectively shared, plays in the formation of a shared frame.

The paradoxical nature of user research is that teams seek out information they predict to be important before knowing what is important, and yet the information they gather in part determines what ends up becoming important. That user research serves to illuminate hidden frames helps to explain why teams experience such difficulties in narrowing their focus towards user needs. In other words performing and sharing user research plays an important role beyond its most obvious. Like brainstorming (Sutton and Hargadon 1996), user research serves not only to guide the team towards effectively addressing user needs, but also the latent function of assisting the effective negotiation of shared frames.

While the contributions of this chapter -the framing cycle, and a deeper understanding of the functions and impact of early design team activities -help more clearly understand some of the difficulties teams encounter we still lack a clear picture of a design team's journey, or path, through the design process. Through assessing their current situation and teams' most common patterns we may be better equipped to provide solid recommendations to these teams. In the next chapter, then, I introduce the notion of design paths and a framework to help understand the interplay of effective framing and the negotiation of frames within a team. develop a product to encourage recycling may see it as a question of creating a bin that helps in the process of disposal, or as developing a service to encourage more efficient collection and another member may see it as a problem of raising awareness of local recycling programs. Each of these perspectives leads the members to frame the problem differently.

What ultimately matters however is to frame the problem in a way that leads to a solution users want -a framing that is based on core customer needs.

In this chapter, I introduce the notion of design paths and introduce the Design Path framework to help track a team's progress along the two dimensions of shared understanding and framing according to the needs of its target market. The chapter begins by presenting the research approach for this second study, followed by introducing the Design Path framework used as an analysis tool. From a large study of student design teams I present the three most common design paths observed together with an illustrative case for each. The final part of this chapter seeks to assess the validity of the model in an industry design setting. To do this I present a detailed case study of a technology startup during its first six years and consider its mapping to the Design Path framework.

In this chapter, I presented the notion of design paths as mapped by the dual dimensions of framing with respect to users and shared understanding of the design team. The paths of design teams in both a student and industry setting provided a greater understanding of the effect of the different early stage activities of the NPD teams and their impact on the design paths.

We also saw the power of a metaphor to frame the design situation, for good or for worse.

Yet, the construct I have proposed, design paths, is also a metaphor as the teams only travel down a metaphorical rather than literal path. Through these examples we can see that metaphors cam play a role both as a framing tool and also as a means to understand the NPD process itself. In the next chapter, I shall present two studies to investigate these twin roles metaphor plays in design.

07 Metaphor and 07 Metaphor and 07 Metaphor and 07 Metaphor and F F F Framing raming raming raming Metaphors in conceptual design, analogy and problem framing Summary In this chapter I consider a particular framing tool: metaphor. I consider how the metaphors we use frame our understanding of the design process itself and how that often differs from the experience of new product development teams. I found that different authors put forward different metaphors for the design process and that these metaphors affect how other core design concepts are understood. I also present an analysis of how metaphor is used in the design process compared with its sibling, analogy. The study found that metaphor use was more predominant in the early stages of the design process and analogy found greater use in the concept generation phase.

So far I have presented studies looking at the role framing plays in the design process including effective and ineffective framing practices (Chapter 05). I have also provided a framework that helps understand the intertwined dimensions of framing matched with users' frames and a teams shared understanding about that framing (Chapter 06 (Yang 2007). New design processes, methods or tools only have value if they are adopted by designers, yet designers are understandably reluctant of new approaches they may perceive as an additional burden on already stretched project schedules. Recommendations that (at least appear on the surface to) make the life of designers more complex will be resisted. New tools also need to be usable in a team setting. It is for this reason that many software-based design tools that need input from multiple team members are not adopted.

In contrast to this perspective we can also argue that although there has been increasing research activity into design team framing it is not clear how these findings should influence design practice. In other words, framing has generated a great deal of scholarly discussion but few tangible and actionable findings have resulted that design teams can incorporate and work with.

One of the important realizations of this research is that there are indeed useful tools and practices already in use by design teams, yet these activities are not always performed correctly or teams attempt to shortcut them (for example, by paraphrasing the presentation of research findings). This misuse, lack of use, or shortcutting of existing design tools is partly because teams do not always understand the full value the tools provide -in particular as they relate to understanding the needs of users and the different perspectives of members of the design team. My research has led me to believe that two primary approaches are needed to support effective framing by design teams:

The first is greater understanding of how the different activities, tools and methods a design team employs affect the framing of the situation and the shared understanding of the team.

The second is simple team practices to help design teams negotiate the framing cycle and employ existing useful framing tools such as metaphor.

This chapter is structured by these two approaches.

I address better understanding of effective practices and tools available to designers through a set of design principles structured around four themes. The practices are illuminated with an increased understanding of why they are effective, and why they are often misused.

I address simple team practices by illustrating a simple and lightweight tool supporting the framing cycle that can be used within design team meetings to help elicit differences of frame and different understandings of the project. I also present a lightweight method to support metaphor use in design and work in progress on a software tool to further enhance it.

I close with a short discussion of the importance of increasing awareness of framing issues, and a consideration of the effects of making implicit practice explicit.

Understanding: Themes and design principles Understanding: Themes and design principles Understanding: Themes and design principles Understanding: Themes and design principles for design team framing for design team framing for design team framing for design team framing

The following major themes or directives for NPD teams and twelve design principles were derived from the framing studies presented in this dissertation. The development of the framing cycle, identification of key framing activities, common design paths and the Design Path framework have all influenced their development.

More specifically, the themes and design principles are developed from the many concrete situations of design teams that I observed. In particular I paid attention to the most common pitfalls of design teams. These pitfalls were divided into those that reduced shared understanding in a detrimental way, and those that prevented teams from framing the project around their target market's needs (the two axes of the Design Path framework). The principles are the responses to these pitfalls; the most effective strategies and practices I observed that helped teams successfully negotiate the same activities or avoid the pitfalls.

This selection of practices was then clustered into the four overarching themes -Learn, don't confirm; Share richly; Make decisions on a common basis; and Drive innovation through real needs. As a result, both the themes and principles have consequences for both framing the situation so that it matches users' frames and for the team building a shared understanding.

The themes can be seen as broader directives of goals for teams to achieve. While they should be achieved one way or another there may be many different ways of achieving them. The specific design principles are more concrete. They should inspire tangible actions and design ideas. I will present each of the themes and its associated principles in turn. They are also listed in Table 8.1. For each principle I have included a short description and discussion relating it to developing shared understanding and matching users' frames. The most common pitfall observed in design teams is beginning the project with an attitude of confirming rather than learning. This means that a team sets out on its user research and its process as a whole with an expectation of confirming what it thinks is the correct framing of the problem. That initial expectation is the pseudo-frame built from a typically incomplete and early understanding of the situation and the needs of users. There is great temptation to believe that the initial framing of the situation is likely to be correct. For one it means less work; if you understand the problem already then you don't need to expend time and effort performing research. Second, team members who like action, for example, those who favor concrete experience and active experimentation (Kolb 1984), are able to begin generating solutions, solving problems and building solutions immediately. However, as Beckman and Barry (2007) argue, this concrete approach "often fails to discover the higher level meaningbased needs that can be crucial to the success of an innovation." Third, we live in a culture that values knowing the answers -we place more emphasis on problem solving than problem finding. Adopting an attitude of learning requires humility to admit that you may not know the answer. However, beginning with an attitude of confirming leads to several important difficulties.

A confirming attitude drowns out potential consumer needs in favor of the design team's view. Confirmation can lead to biased research, as one student mentioned,

We were all under the impression that there was this big need for the [original product focus]. And we all thought that we'd just do these interviews, they were a formality. You know, we were going to do the interviews. It was just all going to flow into the next. One mistake we might have made was that we even tried to steer some of the initial interviews to get that result. Because I think that was the whole reason we were doing this: to almost legitimize the initial idea…We were almost trying to fit that in a box of yeah maybe there still is a need there. But there really wasn't.

A confirming attitude can also lead to hearing what you want to hear from interviews, partly because it also provokes shallower user research. For example, the proposer of a project to do exercise while you work consistently heard a need for his product idea in his interviews while the rest of his team heard quite different needs. One of the design team coaches commented, "I try to get them to go further than the obvious stuff -to get beyond obvious statements, to re-unpack their interviews so that field work isn't just a confirmation of what they thought they knew."

An attitude of learning requires skills for listening, keen observation and building empathy with research participants (Hey, Van Pelt, et al. 2007). Teams must stay clear of their own

biases and be open to compelling needs of the customer even if they conflict with gut feelings.

A learning attitude also opens the door to potential reframing of the design situation.

Reframing is almost a confirmation of a learning attitude. A novel insight that sparks a reframe is also the most likely to lead to a new product direction that will differentiate itself in the market. An attitude of learning can also help create a more motivated and coherent team. It forces the team to learn from, and base its decisions on its research and the stories from research participants. In this way, teams are able to come to a choice of direction together, rather than persuading others of their own viewpoints, and they can also rally behind the challenge of meeting the needs of real users.

Learning not Confirming is the first theme because it pervades all of a team's design decisions and thus has the most far-reaching nature. I will now present three design principles for how to reinforce an attitude of learning not confirming.

Choose a team Choose a team Choose a team Choose a team name not tied to a product name not tied to a product name not tied to a product name not tied to a product A team name is typically representative of what the team is doing. However, because team names are usually set at the beginning of the project, when the team is operating within its own pseudo-frames, team names are often misleading and can be harmful. A team name is a mental bind to a direction. 23 For example, one team struggled to release itself from the 'web site' in its team name: "Is it ok to go back and say we're not doing a site? -it's what we started with."

The number of changes of a team name are a loose indicator for how well teams have reframed as they understood their users better. A new name often coincides with a reframing, for example, in his article, The Cathedral and the Bazaar, Eric Raymond describes how, after a reframing of the mail client he was working on, the "design acquired an identity of its own…It was time for the name change," (Raymond 2001 42).

A simple guideline then is to either not select a team name until after the team has completed its user research and has a clearer idea of the eventual project's focus, or select a team name with deliberately little connection to the initial focus. In particular, related to the design principle Design for people not products, in the early stages of a project it is important to avoid a team name associated with a product or product idea. A stronger team name will be focused around a target market than a product group, for example, "Snowboarder aid," is preferred to "Snowboard lift comfort." Teams often make the mistake of assuming they already understand their market. This is particularly the case when the designers themselves could be part of the market group. In the Powder Net case, it was possible to see the values of academia initially transferred to the business world. Across all graduate design projects studied the most common target group included 20-35 year old students or young professionals (fully 40 out of 57 projects). This choice was partly driven by the convenience of access to potential users (and partly by the personal bug-listing exercise that precedes project proposals), however, with the team members part of the target market, it becomes easier to listen to your own viewpoint on the situation and harder to genuinely listen to your users'. It is also easier to dismiss research participants' views that differ from your own. When team members rely on their own viewpoints, differences in frames are less likely to surface until later in the project, and designers are more likely to design for themselves than their research participants.

In the final chapter I shall briefly summarize the major contributions and studies performed in this thesis towards more effective design team framing. Another key variable whose effect on framing remains little understood are team personalities and leadership styles. Design teams operate with diverse combinations of personalities and leadership styles that will affect the framing activities and the development of shared understanding within the team. Determining the consequences of these variables on design team framing is an exciting research challenge.

Team framing activities in the user-centered design process remain somewhat disconnected from systematic design methods such as TRIZ (the Theory of Inventive Problem-Solving).

Another direction, therefore, would be to effectively integrate the early stage framing activities of the user-centered design process with the technical and creative problem-solving tools of systematic design methods (e.g., Van Pelt and Hey 2006 This survey prompts you to reflect on how your project has been going, and give anonymous, honest feedback to your team. It is based on a survey instrument used in professional new product development settings. Completing the team feedback survey is an assignment, however, the content of your responses will NOT affect your grade in any way. This survey is part of the course each year for three reasons:

1. It provides anonymous feedback on how you are viewed by your team. This is a unique opportunity for you to receive extensive peer or 360 degree feedback, and see how you are viewed by others in a team project setting. The value to your teammates depends on your honest, straightforward, and thorough responses. Responses are aggregated, so that individual answers will not be identifiable.

2. It provides you with a chance to reflect on the process and what has worked or not worked for you to date. This is an important process for you to go through, so take your time & be honest with yourself in answering.

3. It provides the faculty with insight into your projects. The faculty want to see your impressions of the class, your project, and your team. Please write a brief description of any problems or conflicts you encountered in ase write a brief description of any problems or conflicts you encountered in ase write a brief description of any problems or conflicts you encountered in ase write a brief description of any problems or conflicts you encountered in working with your team and how they were resolved. working with your team and how they were resolved. working with your team and how they were resolved. working with your team and how they were resolved. Please be sure to mention any difficulties you've had in getting 'on the same page' and specifically how that was resolved (if it was! You're done! Your thoughtful responses will be valuable to you and your team. The team will receive the results as soon as we can process them.

Close this window to exit the survey.

New product development alumni survey New product development alumni survey New product development alumni survey New product development alumni survey This survey was used in the last part of Chapter 04. The survey was web-based but is shown in a printed form for convenience.

Realism

Realism Realism Realism

To provide recommendations for real design situations researchers should strive for realism in their research settings. Realism in design can be further broken down into three key aspects: timescale; constraints; and team composition.

Timescale refers to studying a project that is of typical length for an industry design project.

Depending on the product or service being designed this can range from several months to several years and longer. Studying projects of only a few hours or days will be less realistic than studying longer projects. Constraints refer to whether the context of the project is similar to how it would be in industry. This includes, among others, meeting the needs of a client, negotiations with management and stakeholders, working within a budget, managing schedules, competing interests, project briefs, realistic risk of failure and rewards for success.

Team composition includes having a realistic mix of experienced and inexperienced members. It also includes having members with different disciplines and skills, values and perspectives. In other words, team diversity should match the kinds of diversity that occurs in industry.

Access to data Access to data Access to data Access to data Data is at the heart of research. Therefore the second criterion is sufficient access to data.

Yet access to data varies widely. As I discussed, frames are cognitive and difficult to observe.

Access to designers' thoughts and rationale for decisions is critical to study design team framing.

Quantity Quantity Quantity Quantity

Quantity increases the confidence in research findings. If a behavior has been observed in many similar situations the researcher can be more confident that the behavior is common and is likely to generalize beyond the study participants. If an event is seen only once it is difficult to generalize findings and be confident that this wasn't a unique instance.

Second, studying more design situations provides more chances to see interesting and important events. If the one project you study happens to be very routine or, alternatively, highly idiosyncratic, then a researcher may not witness key events needed to build theory or may build theory based on atypical situations. The more projects studied, the greater the chance of seeing many different situations and the greater the chances of seeing interesting events.

Comparing resear Comparing resear Comparing resear Comparing research approaches ch approaches ch approaches ch approaches Dunbar and Fugelsang (2004 59) provides a useful taxonomy of research approaches. Among the common methods and their implications in a design context 8 are:

In vivo -studying design activity as it happens

In vitro -controlled experiments with designers in carefully chosen tasks

In historico -reconstructing an understanding from historical data Ex vivo -protocol studies, interviews or diary studies as designers go about a real design task

Each of these approaches has its own advantages and disadvantages in terms of the types of knowledge that can be learned. In vivo approaches provide limited access to the thoughts of design team members and no ability to control the parameters, but have a high validity. The in vitro approach, in contrast, can provide high access to a participant's thought processes, and a high degree of control at the expense of external validity. In historico methods provide high validity but provide no control or access to participants' thoughts at the time. Ex vivo methods are a somewhat middle-ground between the other approaches. Ex vivo studies provide relatively high validity, relatively high access to participant's thought processes and a varying amount of control over the situation. As these approaches play out in design research they commonly translate to case-studies of an ethnographic, in vivo nature, or controlled, in vitro, lab experiments with artificial design tasks.

For realism there is no doubt that an in vivo approach studying real design teams and projects in industry is best -it is real. A case study (see Yin (2003) for an excellent discussion of case study research), or action research (e.g. Dickens and Watkins 1999), provides 'real' data for design researchers to understand. In contrast, the in vitro approach of lab studies sacrifices a great deal of realism for the ability to make quantitative comparisons and for control over the study. While industry design projects may take several months, lab studies are rarely more than several hours and occasionally over the course of a day or a week. The collapsed timescale makes for a less realistic design situation without, for example, time for designers to engage in key activities such as primary research, data gathering, time to resolve disagreements and longer term activities such as incubation (Wallas 1922).

Lab studies also have very different constraints to industry projects. Typically, they are performed by either many novice designers or a select few experienced designers. Often they study individuals rather than a full design team because team dynamics take time to evolve and studying teams is more challenging to arrange. Lab studies also suffer from different engagement of designers; performing well in the design task will not earn them a promotion, and performing poorly won't lead to a pink slip. The absence of clients and management moves lab studies further from realistic settings.

Short timescale studies in a laboratory also rarely allow recruiting teams with a past history together or give them time to develop ways of working together and communicating. In the same vein the composition of the team lacks the mix of industry experience often present in industry. In the short time-scale of lab studies participants are generally peers and often meet each other during the study.

Despite these drawbacks, lab studies provide researchers with an unprecedented amount of control over the parameters of the study. Only in a lab study is it possible to maintain control over relevant task parameters. Lab studies therefore provide an accessible means of evaluating causality between an intervention and its effect.

Where the industry case-study approach is undoubtedly realistic it can suffer in both access to data and quantity. Access to data can be limited and hard to come by in industry. Findings or events that may be seen as negative for the company may be restricted or distorted when presented to the researcher. In other cases a company may deny the opportunity to publish the results if the outcome could be seen as negative publicity resulting in an unusually high proportion of positive case studies. It may prove impossible for the researcher to attend all relevant project meetings or have access to the physical artifacts of designing including documents and prototypes. This is particularly the case when studying design teams as the time to launch a new product can be significant and a new product is often a source of substantial competitive advantage and thus closely guarded. Researchers may also face political and social challenges to gain access to data based on trust, seniority and must avoid compromising participants' job security. In retrospective studies it can prove difficult to contact all past design team members. In addition, events may be remembered inaccurately, or be subject to the halo effect of remembering events in a more positive light, and team documents may not have been archived.

Industry case-studies also often require a great deal of time and effort from the researcher.

Studies typically require six months or more of a researcher's dedicated time to build rapport with the design team members and key company stakeholders, and witness the full evolution of a project. In practice this means, in the relatively short time-scale of a PhD, a design researcher is restricted to studying a maximum of about four projects from start to finish.

Student design settings Student design settings Student design settings Student design settings Data in this thesis is primarily built from a middle ground between the industry case-study approach and the traditional lab experiment. I chose to collect data from multidisciplinary NPD teams in a graduate student NPD class. This is effectively a modified ex vivo approach

where we can learn about real design behavior though in a somewhat contrived, though not easily controllable, setting.

The amount of need-finding that should be done. Design coach survey and interview Design coach survey and interview Design coach survey and interview Design coach survey and interview Data from the design coaches was in the form of both written answers to the survey questions and transcripts of the interviews. As the number of coaches was significantly smaller than the number of students, no quantitative conclusions could be drawn.

Qualitatively, however, the coaches' prioritization appeared to mirror that of the students and provided an outside validation of the students' self-assessments. The coaches' comments, however, were more nuanced and sophisticated, perhaps reflecting the form of input. Here are some representative answers to the questions concerning what they see the students learning that is of most value to industry practice:

"Negotiating a wide range of views -different people looking at the same set of information can come to different analyses -they have to work through this as a group."

"The initial ideation is easy when there's nothing at stake. But that second round of ideation, when people have different perspectives -that to me is the other real world learning. Working out who their team is and how to get it to work. That's huge."

"I think the most important thing is to clearly perform market research and market segmentation before tackling any design challenge. User research is also something that is lacking from most industries that I've worked in."

"User needs identification: Stressing use of observation -and story telling using visuals will enhance the students' work, innovation and communication skills."

"Communication skills are at the heart of presenting ideas to team members, clients, end-users, etc., which is at the heart of the user-centered design process (getting ALL stakeholder inputs). Identifying user needs are again a heart of user-centered design. These skills will be at the heart of designer/analyst professional expertise."

Advantages Advantages Advantages Advantages

Although student design teams do not operate in an authentic design setting it is significantly more realistic than a lab setting. For example, student design projects used in this study spanned three months from conception to working prototype; three month projects are not uncommon in industry, particularly in the design consulting business. While the members of student design teams are by necessity learning to do design they nevertheless possess a range of experience. Each team typically has members with at least three years of industry experience together with members setting out on their first multidisciplinary design project. In this way, more experienced members help to mentor and lead the less experienced.

While a University setting will always be different from industry, the faculty work hard to create projects that closely match a common industry setting through enforcing similar stage-gates, deliverables and activities. Alumni of the class have confirmed its similarity to projects in industry, for example, one alumnus commented: "Working on a cross-functional team is so important. I know that today more than ever -the vast majority of my work is on a cross-functional team. In all my classes [during my studies] that class was the closest to reality."

Student design teams in this study are also multidisciplinary with graduate students from business, industrial design, engineering, software development and information management. The mix of disciplines closely mirrors the skills required in real industry projects. Teams are also guided by experienced product development coaches from local design practices reflecting guidance from senior members of design firms.

Student design projects provide a distinct advantage for both access to data and quantity of projects available to study. The open classroom setting allows a design researcher to closely watch the evolution of the project, witness team meetings, successes and difficulties and provides access not only to final deliverables but to intermediate project documents. We have further supplemented our data collection through the use of surveys and team interviews to provide a comprehensive picture of each project.

Finally, studying student design projects enabled me to closely watch the development of over sixty different projects in the course of four years. Studying this many projects has allowed me to observe both unique and repeated situations and to witness many interesting events. The range of projects allows us to compare the experiences of similar teams and teams working on similar projects. With over four hundred graduate students involved we are also able to support our qualitative observations with quantitative analysis from surveys and class outcomes. These benefits of studying student design teams has led them to become a mainstay of data for design researchers across the globe.

Limitations Limitations Limitations Limitations

Despite these advantages I recognize it is easy to dismiss theory built from student design settings. Without the organizational constraints typical of industry projects, the class context and lack of experienced designers it is important to interpret findings with care, judging what is more broadly applicable and what is an artifact of the research context.

In particular, motivation to succeed varies widely in design student settings. Some students take the class for the desire to develop a product for market, others because they intend to be leaders in NPD. Yet, some students inevitably take design classes purely for the experience, because it fits into their schedule or purely for a grade. While this is true, it cannot be said that all participants in industry design teams are highly motivated. Motivation and commitment to a project inevitably varies.

We have attempted to address these limitations in several ways. Research findings and qualitative interpretations were discussed and checked among research collaborators such that only findings we were most confident of are reported. Findings are only included when we were able to verify them through repeated observations. To assess the transferability of findings to industry we conducted interviews with professional designers in industry and a detailed case study of an industry NPD project. When framing issues for design teams surfaced both in the student teams and the industry situation our confidence in the research findings and applicability is increased. Later in this chapter I also carefully review how widely I feel findings from this thesis can be generalized.

Building on prior research Building on prior research Building on prior research Building on prior research

As I alluded to in the previous chapter, I have tried to build upon existing framing research.

In particular, I have attempted to address gaps in research methodology in prior studies by studying:

Multidisciplinary rather than Unidisciplinary teams: Many studies used data from uni-disciplinary design teams in experimental settings. Real-world design is performed with designers from multiple disciplines with varying backgrounds and skill-sets. I therefore studied multidisciplinary teams. teaching students the innovation process through the lens of user centered design. Material covered in the class broadly follows the textbook Product Design and Development Eppinger 1995 and supplemented by readings and lectures on user-centered design and ethnographic research methods. The students also 'learn by doing' through a team project -with project areas ranging over: easier exercise; a sexier soccer bag; more blood donors; local transporter; reducing obesity in the young; and healthy meals for schools 9 (see Appendix for the complete list) -that spans the length of the fifteen week semester.

Each team is interdisciplinary with some mix of business, engineering (mechanical, electrical, chemical, industrial, civil and environmental), information management and industrial design (California College of the Arts and one year from San Jose State University) students. Each team is coached by the three course faculty as well as by a local design professional and evaluated at the end of the semester on how well it has undertaken the process as well as on its final prototype. Faculty and judges from well-known product development and design firms (such as frog design, IDEO, Jump Associates, Apple and Cheskin) evaluate the team's performance based on a project presentation and a prototype display stand and demonstration.

Over the course of this thesis I collaborated closely in data collection with Caneel Joyce, of the Department of Organizational Behavior in the Haas Business School, and five undergraduate research assistants. Three faculty members, with a combined experience of teaching the class of over 30 years, validated interpretations regarding team performance and provided additional insights.

Data in this thesis was also gathered from one semester at MIT. 10 The MIT NPD class follows a very similar format to the UC Berkeley class. The primary textbook for the class is the same, so the teams follow largely the same design process. The team composition is similar -it is a graduate class comprising engineering and business students at MIT with industrial design students from the Rhode Island School of Design (RISD). The class is also team taught by engineering and design faculty. Differences between the classes include having no external design coaches for the teams and an increased emphasis on a working final prototype. A greater part of the design grade is based on the final prototype and consequently less class activity is devoted to user research activities and more to prototyping and testing.

While I find these conclusions compelling, I also recognize the study relies upon self-reported data from the students. In contrast to other research methodologies, such as a written assessment of learning or direct observational data, our use of self-reported data introduces some uncertainty in our conclusions. Students may be biased towards recalling only certain types of lessons learned. When asked, they may be more likely to recall those things that stood out as unusual or unexpected, or had an associated emotional charge, thereby excluding more mundane, but equally important learning.

Data collection Data collection Data collection Data collection

The primary goal with the research approach was to be able to tell the story of a project. To do this well I first needed to understand the activities and actions that were performed. To explain why these activities were performed I also needed to understand the basis for the decisions the team took with regard to, for example, who they chose to observe, which concepts they chose to develop, and the results of their testing. Just as designers listen to the stories of their participants in order to learn about them, as a researcher of designers I listened to the stories the designers told about the design process in order to understand and design for them. In some senses I was performing design ethnography of design ethnography.

Reflecting on the framing carried out by the design teams, I followed Rein and Schön's (1991) suggestion that this frame reflection should be on the stories that identify frames and the values, norms, metaphors, appreciations and directions for solutions they contain (Stumpf 2001 70). In particular, framing becomes visible when teams become stuck or realize a failure with an existing approach, for example, when a team cannot agree on a way to move forward or when an end user rejects an early prototype causing the team to rethink what is important.

The following is a list of the data collected in order to be able to confidently tell the story of each project. 11

Initial project proposals: I captured both the written project proposals from each student in each class as well as observing their presentation of the proposal to the class. This provided the first description of each project, and thus a base from which to measure its adaptation over time.

Short free response survey: For two semesters, several weeks into the semester we asked in a voluntary free-response survey for students to tell us the goals of their projects, the strongest points of consensus on their team about its mission, the most significant issues about which team members were not in agreement, and how they thought their team's mission statement had changed in the past week.

Observations of in-class team meetings: I observed in-class sessions in which teams were working on their projects alone as well as with faculty coaches.

Interviews and observation of meetings outside class: one researcher met with each design team to observe and audiotape a meeting for between 30 -150 minutes. Near the end of the meeting we conducted a short structured interview of approximately 25 minutes to hear the story of the project as they saw it including the customer research performed, mission statement development, challenges they faced or imagined facing on the project, the number of times they had met to date, and the amount of work they had been able to contribute to the project. Design documents produced and exchanged by the teams: We accessed the design documents produced and shared within the teams as well as the class deliverables. These documents, together with observations of two project presentations to their peers during the semester provided a public viewpoint of the teams' understanding of their projects.

Project journals: Each student was required to maintain a design journal throughout the semester. The design journal contained a mixture of meeting notes, design sketches, individual work, class notes, information from external sources including photographs and print-outs from the Internet, and reflection on team process and dynamics. The quality and depth of journals varied widely. Each journal was studied at the end of the projects and the information was used to inform the understanding of the project. In certain cases, quotes were extracted directly from the journals. To learn more about the typical content of the design journals see Song and Agogino (2004).

The same data were collected at both MIT and UC Berkeley save project journals which were not available from the MIT class and several design meeting observations that were performed by a research assistant rather than directly by the researchers.

Industry case study Industry case study Industry case study Industry case study

To help understand the transferability of results to industry I supported the data collected from the graduate design teams with an industry case study and interviews with new product developers in industry. In Chapter 06 I present a case study of the company Powder

Net through the early formative years of the company. As discussed in Chapter 06 I used a criterion sampling method (Patton 2002), constructing interviews with the founders of the company asking them to tell the story of the project as they saw it. The interviews were semi-structured with a core list of questions to understand the original framing of the design situation and the insights and decisions that led to their final framing. When possible the interviews were recorded and transcribed. If the interviews were not recorded then notes were taken during the interviews and written up directly afterwards attempting to preserve as much as possible the original wording of the interviewees.

In the course of studies for this thesis, presented in Chapter 04, I, and my colleagues, also performed interviews with 12 design coaches of the UC Berkeley NPD class, all professional designers, and 18 alumni from the NPD class who are performing NPD in industry to different degrees. Though I do not ultimately present them in this thesis, interviews were also conducted with two other early stage NPD firms as potential case-studies.

Finally, I also drew on my own two years of NPD experience at two design consulting firms I Europe and the US. My own experience was an additional cross-check for findings throughout this thesis, although all conclusions and guidelines are first and foremost developed from the data collected specifically for this research project.

Data analysis and research protocols Data analysis and research protocols Data analysis and research protocols Data analysis and research protocols Data collected for this thesis was analyzed in multiple ways for different purposes and with different colleagues. Table 3.1 details the chapter, data set, data type, analysis colleagues and research publications resulting from each study.

As the analysis of each data set varied for each study, rather than include each protocol and analysis method here they are included in each chapter or referred to in the Appendix.

Methodological issues Methodological issues Methodological issues Methodological issues

In collecting and interpreting this data four methodological issues were foremost: the researcher effect; group interviews; anonymity; and generalizability. I will briefly present each of these issues in turn and how I sought to deal with them.

The researcher effect The researcher effect The researcher effect The researcher effect Whenever a researcher is in direct contact with study participants, the presence of the researcher and knowledge about the research being performed can affect the behavior under study. In other words, in observing and interviewing the design teams I also affected their process. In my case this was also compounded by my role as a teaching assistant throughout the years of the new product development course at Berkeley. A teaching assistant has a role of authority and an obligation to the students to avoid letting the research activities strongly influence outcomes for students in the course. Indeed a primary concern was to ensure students that their thoughts provided for research would not play a role in their class grades. Committee on the Use of Humans as Experimental Subjects (COUHES). 12 I also tried to reduce the effect of research by conducting interviews towards the end or after the class was completed. As teams are graded largely on their process much of their grade is already decided at this point. When conducting interviews I forced myself to listen without providing advice other than what is normally called for in the role of a teaching assistant. Also, in the consent forms for participation and the description of the research provided to the students discussion of the research aims and themes was kept deliberately vague so as to not artificially produce the effects I was trying to study.

Being a teaching assistant also provided me with several valuable benefits. It was expected that I would be present during lectures, in-class lab sessions, presentations and tradeshows.

Design teams were therefore quickly comfortable with my presence. Indeed, in most situations it was apparent that students did not consider me a researcher. As a teaching assistant I was also in the unique situation of being both a peer to the graduate students of the class, and therefore more approachable for them to air their concerns and team issues, while also having the benefit of learning from faculty interpretations and discussions 12 Human subjects approval is included in the Appendix.

regarding team progress. This position was reflected in the students' typical openness to participate in the research.

Group interviews Group interviews Group interviews Group interviews

The majority of interviews with design teams were performed as group interviews. In most cases all, or most, of the team was present for the full length of the interview. Group interviews were performed partly for scheduling reasons. Rather than perform nearly 400 one-on-one interviews, which would have been impossible, group interviews made it possible to reduce that number to less than a quarter. But group interviews were also chosen because of the unique context of design teams. Group interviews allowed me to observe a microcosm of the overall project team dynamics during the course of the interview. It is possible to see who is outspoken, who is quieter, who is a leader and who contributes. By observing social cues such as interruptions I could infer whether the dynamics of the team were adversarial or respectful and cooperative. When asking for the story of the project a group interview provided an excellent opportunity to observe first-hand the differing accounts often produced by group members. As one team member would relate the motivation for a decision, another would jump in to say he had seen it very differently. In this way, bringing the differences of opinion into the open with the team allowed me to learn a rich history of the project as team members built upon and constructed the story. The teams often, though not always, found the interviews both educational and enjoyable.

Group interviews are subject to the dynamics and presentation of the project in a public way.

Where there were strong differences of opinion or personal conflicts team members may have been unwilling to bring these up in the public setting. Group interviews also do not create the ideal environment for more reserved team members to speak their mind. In most cases, however, the combination of data collection methods helped me gain a second or third perspective on team members' experiences. They were able to provide their thoughts in the online team evaluations and through reflection in their journals. On several occasions, individual team members contacted me for a private interview after the group interview.

While I can be certain that I did not learn the full story from all team members over the four years of study, I am certain that I learned enough to understand the bulk of key decisions that affected each team's path through the design process.

Anonymity

Anonymity Anonymity Anonymity With regards transferring learnings to professional NPD teams in industry an important consideration is expertise. A key difference between professional NPD teams and student design teams is that student designers are by necessity learning the process. Many, though not all, industry NPD teams are comprised of members with significant expertise. Lawson and Dorst's (2005) model of design expertise is instructive. They divide design expertise into 7 levels: naïve; novice; advanced beginner; competent designer; expert; master; and the visionary (The model builds on Dreyfus' model (2002)). The graduate students in the NPD classes studied range in expertise from naïve, those with the most simplistic understanding of design, to the rare competent designer who is able to become the creator of the design situation improvising with process as necessary. Most professional NPD teams could be expected to comprise slightly elevated levels of expertise, from novice to expert (often responding to situations with intuition from many years of experience) with the occasional master. While professional design teams then are likely to operate slightly differently due to increased experience there is also significant overlap in the range of skills present between both industry and graduate NPD teams. The Berkeley design teams also benefit from the guidance of professional design coaches and the design faculty who effectively help raise the experience level of the team. We can thus expect many of the results to transfer to regular NPD teams in industry although there may be less relevance to truly expert NPD teams such as those found at the leading design consultancies. It is important to recognize that it is also A key first step of designing is to identify needs that are not being met. My study begins then by trying to identify the needs of design teams. The study I present in this chapter The Kolb model is particularly appropriate for teaching NPD as it cycles the learning experience through concrete, hands-on activities, and experimentation sequenced between activities of abstract conceptualization and self-reflection. Reflective observation, or selfreflection was recognized by Schön (1983) to be a key skill for a design practitioner. Schön refers to the 'learned intuition' of professional practice as 'professional artistry' or 'knowingin-action'. He suggests that it is the ability to reflect both during and after an activity that distinguishes the effective practitioner. Reflection on the design process and the students' team experience is therefore required at multiple points throughout the design projects. The students were asked to reflect on their experiences after each assignment (e.g., their first customer interview), and to share their team reflections at each of three presentations to their peers. By the time they get to the final class assignment, generating the lessons learned that are the subject of this paper, they are well-experienced in reflection. After the collection and analysis of student lessons learned my collaborators and I listened to the experiences and perspectives of the industry design coaches to compare to the students' experiences. The coaches were not shown the results of the analysis of student lessons before providing their thoughts.

Lessons learned

Design coach reflection Design coach reflection Design coach reflection Design coach reflection

Design coaches -experienced designers from industry who are asked to coach and mentor the NPD teams -are used successfully by an increasing number of product design programs (e.g., Eriz and Leifer 2003;Ochs 2007;Cardozo et al. 2002). The design coaches guide the students as they navigate the NPD process, helping them to explore and articulate what the problem space is and what the solutions might look like. Design coaches provide the benefit of an outside perspective on the process and help the team resolve issues with team dynamics. Interaction with industry professionals encourages learning by helping students connect class experiences with real-world constraints, priorities, and quality expectations.

Design teams in the NPD class at UC Berkeley are encouraged to meet with their coaches to seek their advice and share their experiences, at least three times during the semester.

Student reflections show their appreciation of the coaches:

"Design coaches were invaluable. I wished we'd seen more of ours."

"Design coach was an excellent resource and was open and helpful. He was a great contact to the professional world."

"I have a new respect for people who do this professionally."

"Mentorship or outside consulting helps tremendously."

"Talk to the experienced professionals. They know what we have to improve!"

Over 60 design coaches have been associated with the NPD class in the last six years with over twenty of them coaching for more than one year. The design coaches have unique firsthand knowledge of the students' design experiences as they meet with the students and observe where the teams struggle and where coaching is most needed. Often they can elicit information from the teams that the faculty are not able to, as the faculty are seen as controlling course grades, while the coaches are seen as knowledgeable professionals who are offering their expertise. In addition to what the coaches learn and observe about how the student teams work, they have their own body of knowledge about the skills NPD professionals need to know to be successful. They are thus well positioned, with an outside perspective, to determine if the class does indeed develop these skills.

To make responding as easy as possible, three options were provided for the coaches: an email survey, a phone interview or a face-to-face interview. A seven question survey asked coaches to rank the clusters of lessons most commonly identified by the students in terms of both what they see the students learning, and what would serve them best in industry. While some coaches returned the survey form, other coaches preferred to share their thoughts and experiences in a short phone interview covering similar questions. Although the survey questions were used to guide the conversation, the design coaches were encouraged to share the stories and experiences that seemed most relevant to them.

Data analysis and results Data analysis and results Data analysis and results Data analysis and results

In this section I first describe how the lessons learned from the six different years were merged, then present the summary data, and identify important results. I then dig into the lessons learned that focus on the NPD process itself, and analyze the "Customer and User

Needs" category in some depth. Both the customer and user needs lessons and those lessons relating to teamwork bear the greatest impact on design team framing. Finally, I describe how the data provided by the design coaches was analyzed, and how it compares to what the students provided.

Merging 6 years of Merging 6 years of Merging 6 years of Merging 6 years of lessons learned lessons learned lessons learned lessons learned

During the class exercise, the students clustered the lessons learned into categories of their own choosing and named those categories using a process commonly referred to as affinity diagramming (or the K-J method, see for example, Brassard and Ritter 1994). The resulting categories reflected the particular mix of student experiences represented in each group.

Each year, after collecting all the lessons learned, these categories were used as starting points for a high-level clustering exercise to integrate and re-sort all of the lessons from the class. In this step, Post-Its from similar categories, such as 'milestones' and 'deadlines' for example, were grouped together into one category to make the list more digestible. The new clusters of lessons learned were transcribed to create a summary document which was returned to the students. Utilizing the students' category names as much as possible ensured that their perspectives and means of organizing their own experiences were retained.

The high-level clustering performed each year varied in both the naming and granularity of the categories, so to make the data comparable across years yet another high-level clustering exercise was performed. In this case, similar categories were amalgamated and larger categories broken down to form a uniform set of categories that spanned the six years. Each of the individual lessons learned within each category were carefully checked to ensure consistent application of definitions. Each year there were several categories -such as "Effective Workspaces," or "Archiving Documents" -that did not show up in any other years; these were eventually folded into an "Other" category. Categories that consistently showed up across all six years remain distinct in all of the analyses that follow, and all of the final categories I present here were suggested by at least several groups of students throughout the six years. Table 4.2) comprise 35% of the lessons learned, process-related categories (indicated by a P in Table 4.2) comprise 42% of the lessons learned, and other categories (indicated by an O in Table 4.2) comprise 23% of the lessons learned. 'Other'

includes topics that were general and not specific to NPD, such as managing time. I'll now examine the team-related and process-related lessons learned in more detail. together is key to acting as a team rather than a group," and "Everyone is valuable.") To provide a clearer idea of what is included in each team-related category Table 4.3 provides sample quotes from the students. "Face-to-face meetings are best; don't always rely on emails"

General team learning 15 "Agree on process to get buy-in" "Allow for time to gather necessary information so that decisions are fact-based" Team building 11 "Spending time outside of regular meetings can help build team chemistry and enable you to work more effectively"

"An ideal balance between humor/play and serious work can be achieved" Conflict management 7 "Be honest about problems early" "Just because someone says 'yes' does not mean they really agree"

Leadership 7 "Clear leadership is helpful to allocate jobs more efficiently"

"A team leader is not really needed as long as the group can reach a decision. Otherwise, a team leader is needed to reach a decision"

The process-related lessons learned categories identified by the students, not surprisingly, parallel the NPD model the class follows (Ulrich and Eppinger 1995), including: generating the goals and mission statement of the team, customer and user needs research and analysis, concept generation, concept selection, prototyping and testing, and financial analysis. The largest category of process-related lessons mentioned by students, see Table 4.4, related to identifying and dealing with customer and user needs; the phases of concept generation, concept selection, prototyping and testing, and financial, economic and business were less significant to the students. As Customer and User Needs is the most significant processrelated category, I more closely examine the breakdown of the 318 lessons learned in that category to understand what aspects were the most significant.

User needs lessons analysis User needs lessons analysis User needs lessons analysis User needs lessons analysis

Over the last several years, the need-finding process and a deep understanding of customer and user needs have become increasingly important, with both industry and design classes placing greater emphasis on them (see, for example, Leonard and Rayport 1997). The needfinding activity poses the greatest amount of uncertainty to developers because customer and user needs are unknown and out of developers' control. Finding new or unknown customer and user needs has more potential to change the end result of the development process than any other activity (Zirger and Maidique 1990;Rothwell 1972). Yet, arriving at a precise list of needs to address can be a difficult and time-intensive endeavor because consumers often have trouble articulating and prioritizing their needs when they are not responding to offerings with which they are already intimately familiar (Laurel 2003). It is perhaps not surprising then that lessons related to user needs are frequently mentioned.

Two approaches were taken to understanding and analyzing the lessons relating to customer and user needs. One researcher placed each lesson on its own note card and then performed an affinity diagramming exercise (Brassard and Ritter 1994;Beyer and Holtzblatt 1998) in a Accuracy Accuracy Accuracy Accuracy

Finding the "right," "real," "true," or "wrong" needs.

"Find the right customer needs."

"Accurate identification and prioritization of user needs is critical." "Contact with the customers should happen all the time, before, after, and during."

"Need to revisit customer needs repeatedly."

Discussion

"We have to be careful what we mean."

"Our terms were so vague and so broad that we kind of forgot what they meant."

"That term 'appeal' is bothering me. Is it bothering anyone else?" "Let's make sure we're all on board with the last one."

"Are we focusing on protection or prevention?"

Teams that do not take the time to ensure similar interpretations for words risk a false sense of shared frame. On the surface, they appear to have buy-in from all members, but deeper probing reveals differences in interpretation from member to member. In these cases unstated assumptions and ideas influence team member decisions and actions throughout the early stages of the project, but the reasoning behind their actions is unclear to other team members.

"The project focus came out of 'language learning' and it became clear that we all had different conceptions of 'language learning'."

Discussions of the mission statement sometimes reveal members' implicit assumptions about the possible directions of their project:

"Usability and eco-friendliness are not necessarily in line with each other"

In this example, one team member saw the two factors as somewhat conflicting. Statements like these both reveal the frame of the speaker and also subtly influence the frames of team members. While the statement may provoke open discussion of differing opinions, it may also lead others to adopt the speaker's frame without questioning it.

Iteration of the mission statement occurs naturally in the early phases of NPD. To some students:

"Sometimes it seems like the product development's driving the mission statement, rather than the other way around."

"So maybe we need to revise our mission statement based on what we want to do? We need version 3.0."

"We were having trouble refocusing our mission statement since some of us felt we did not have a perfect understanding of the problem. We interviewed more people and as we got more data, we were able to find trends and patterns that allowed us to focus."

A student on the 'Child Swimming Pool Safety' team highlighted the conceptual difficulty of the paradox of a mission statement driving product development, in turn driving your mission statement:

"There are already a lot of good products on the market (fences, pool covers…) that prevent children from drowning. We could choose a product that the child has to wear but [then] it is not prevention anymore."

A student on the broadly scoped 'Improving the supermarket experience' team explained how they viewed the concurrent evolution of their mission statement with their evolving understanding of their project:

"We have been cycling through broad missions to more refined missions and then back out again."

The cycling of broad to refined mission statements illustrates the co-evolution of problem and solution (Dorst and Cross 2001), and the nature of NPD as a wicked problem (Rittel and Webber 1973) 3. Research areas: frames drive research 3. Research areas: frames drive research 3. Research areas: frames drive research 3. Research areas: frames drive research

The initial frames that members hold for their project strongly influence the research The initial frames that members hold for their project strongly influence the research The initial frames that members hold for their project strongly influence the research The initial frames that members hold for their project strongly influence the research "Research moved us towards childhood poisoning risks in the home because it was a much larger issue and something that we thought we could actually improve."

"We all came into the project thinking it was going to be about making locks on cupboards."

Eventually both teams learned that their initial assumptions were incorrect -the actual process of giving blood was not what was hindering donors (it was knowing when and scheduling to come back), and physical access to cupboards was not the key issue in childhood poisoning (it was the short times that toddlers are left unattended). Another team, discussed in more depth in Chapter 06, investigated inadequate seating at airports. Yet their original focus on the travelers and the possibilities of designing bags to be the missing seats, led them to ignore until too late speaking to other key stakeholders such as flight announcers and airport managers.

Teams also made early assumptions and judgments about feasibility, even in the face of uncertain information. Seeking "a problem we could readily address" or "something…we could actually improve" reveals assumptions about what is possible and likely.

Conducting and learning from initial re Conducting and learning from initial re Conducting and learning from initial re Conducting and learning from initial research is difficult when the initial frame is too broad. search is difficult when the initial frame is too broad. search is difficult when the initial frame is too broad. search is difficult when the initial frame is too broad.

A member of the 'Safer Stove' team -which sought to improve safety of household ovens for the blind, the elderly and the disabled -commented:

'I have realized that we have to be much more specific in defining the problem and demographic. I shied away from this at first, not wanting to miss some issue that might present itself during an ethnography that covered a broad scope, but I have come to understand that due to time constraints we need to be more focused."

As team members argued about the breadth and depth of the research they should conduct, "I don't think we can expand on that in a product." "No, that's something we can't do. But we could…"

Here team members' implicit assumptions regarding team capabilities and the possible direction of the project limited the potential solutions the team could produce. The most common implicit criteria that we observed were around feasibility. In these two examples, filtering was made explicit through brief discussion. However, more subtle and damaging errors are made by neglecting those needs that never leave the researcher's mind having been pre-filtered by their assumptions.

Sharing research information, often visually, played a key role in the satisfaction and Sharing research information, often visually, played a key role in the satisfaction and Sharing research information, often visually, played a key role in the satisfaction and Sharing research information, often visually, played a key role in the satisfaction and progress of the design teams. progress of the design teams. progress of the design teams. progress of the design teams. Sharing information from user interviews, secondary research and observations can become a bottleneck. This has also been observed by Liston et al. (2000) who noted that design teams spend more time describing, sharing and evaluating the information they have collected rather than using it for rational decision-making. In the short meeting times available, it seemed nearly impossible to sufficiently share the learning of each team member with the others:

"We sometimes spent so much time collecting data that we had a hard time to synthesize and share the data as a team."

"I feel like we have so much information, let's just put it all out there." Information sharing was enhanced by effective use of tools and space such as plenty of whitespace on whiteboards or paper to share findings visibly to the whole team. Laptop displays facilitated sharing visual information such as photos of people, places and behavior.

The role of sketching in making visible conflicting frames and assumptions is well documented (Akin 1978), which our observations supported. One team member commented:

"I think being able to visualize what the other person is talking about is a problem we need to overcome. Talking a lot and sometimes drawing out ideas help tremendously in communication."

Sharing user research using the exact Sharing user research using the exact Sharing user research using the exact Sharing user research using the exact words and behavior of interviewees helps in the words and behavior of interviewees helps in the words and behavior of interviewees helps in the words and behavior of interviewees helps in the development of a shared team frame. development of a shared team frame. development of a shared team frame. development of a shared team frame. Keeping exact quotes of users and recounting research experiences as stories resulted in team members 'imposing' less of their own frames on the data. Instead, they let the users speak for themselves. Some teams explicitly chose to use quotes from their users to identify needs and others adopted the user perspective sharing and answering questions as if they were the user:

"They said it -that's not my opinion."

"It seemed, when I talked to women, that they…"

"Because she didn't want to…" "It makes Rachel feel…" "She feels…" "She doesn't like…"

"He's on the extreme of independence and not letting anything stop him."

Telling user stories also provides a compact and time-saving way of sharing needs, perceptions and experiences in a memorable way. Making user data explicit helped team members adapt their frames around shared information. Teams that had spent less time performing user research did more information sharing based on personal experience. Their sentences would often start with 'I':

"I think the average user's not going to want…" Indeed Sleeswijk et al. (2007) conducted an experiment for a new tool to share research data and evaluated its effectiveness partly through counting explicit references by designers to either their users or to their own experience. Relating information based on personal experience alone is significantly less likely to lead to the team successfully addressing the issues of real users, except in cases where the designers themselves are potential users.

Relying on personal experience and information also leaves more assumptions, goals and criteria left implicit and unsaid in the minds of the team members which can lead to conflict later in the process.

Teams that actively sought out real user data -in the form of interviews, observations and market research -negotiated a shared frame among team members more easily than those who relied upon their own frames and viewpoints. Some design teams allowed user research to inform and shape their projects while others used it to confirm their own frames. User data helped teams in two ways. First, it provided a concrete reference to an external source of information, forcing individuals to test their own assumptions. Second, it illuminated conflicts among individual members' frames that were otherwise hidden. By grounding the team's conversations in concrete data from an external source, ideas could be evaluated with a common frame of reference while minimizing hurt feelings.

The following examples show teams relying on user data over and above their own assumptions:

"None of our interviews have led us to that conclusion -so we might just have to strike it."

"Did that appear in our interviews anywhere?"

"I want to go to more schools." "Now it's just conjecture."

"It's tough to not jump to thinking of solutions and we keep reminding each other to keep it problem-based and not limit ourselves or constrain our thinking too narrowly."

One team experienced conflict when one member, with a strong explicit direction for the project, related that her user research supported her direction. The rest of the team however, did not hear the same confirmation of needs. Without providing clear, concrete data of the user interviews performed the conflict arose as the team did not believe or trust the user research provided by this one member. As that member related to me in private, "My team is essentially calling me a liar." This conflict required intervention and encouragement to focus on sharing real user data to overcome.

Organizing user needs is a framing activity.

Organizing user needs is a framing activity.

Organizing user needs is a framing activity.

Organizing user needs is a framing activity. The teams followed several prescribed methods of understanding, categorizing and prioritizing user needs. Categorization of needs was often performed individually and then as a team; the frames of individual team members invariably resulted in different categorizations of the same needs:

"We already categorized our own." "Doesn't mean they're the right ones -I mean they're individual ones."

"I separated mine into four groups. How should we do this as a team?"

The categorization of the needs themselves was seen as an ambiguous and uncertain process with multiple, if not infinite, possibilities. Many teams lacked a coherent story around which to select categories. Often a process of enlightened trial and error based on personal experience and intuition resulted in the final categorization.

Naming of needs is also performed from the personal frame of each designer. Other teams struggled to balance solutions and needs from the outset. The initial frames held by the team members contained strong enough goals, criteria and bounds that several types of solutions presented themselves automatically. These teams found themselves working backward from solutions to customer needs "I think it would be more useful to come up with solutions and then classify solutions [rather than needs]."

"In the beginning we started with solutions rather than actual customer needs and we are beginning to refine our work in terms of customer needs statements."

"We kind of worked backwards from our concepts, to which needs they addressed."

When done with attention to understanding real user needs, this reverse design process, can prove an effective way of moving the team forward.

Ideating possible solutions, and a purge of solution ideas at the outset of a project, can be a very effective way of revealing the different aspects team members see as important. In this sense, generating concepts can be a very useful activity with the explicit assumption that they do not need to be adopted but have value in making hidden frames explicit. These observations around ideation support Whelton and Ballard's assertion (Whelton and Ballard 2002), that project definition is an adaptive process that incorporates project change through the co-evolution of problem formulation and solution generation.

The framing cycle The framing cycle The framing cycle The framing cycle

In the previous section I presented findings about the role of framing activities throughout the early stages of the product development process including development of the initial proposal, creating and refining the mission statement, conducting user research, digesting the data collected, and creating categories of ideas for concept generation. How do these observations shed light on the process of negotiating shared frames within design teams?

The collective observations and understanding of the additional roles of these common design activities allowed us to develop a model for how individual frames are shared and a common team frame is negotiated.

This model is a Framing Cycle with four phases illustrated in Figure 5.1. Let's look at each phase in turn. Teams that made individual frame conflict salient used a combination of user data, discussion and listening to negotiate a shared frame. Dedication of the team to user-centered design gives the team a common anchor against which to tether constantly evolving individual frames, thus enabling the eventual arrival at a shared frame. Team members on the 'Healthy Meals for Schools' project, for example, did not hold strong frames at the onset of the project and were able to build a shared frame directly from user data without significant conflict.

Other teams did not gather sufficient user data or care enough about success in the project to find and address conflicts between individual frames. In the case of the 'In Touch in the Developing World' team, the team struggled to find potential users to interview and so never reached the stage of frame conflict. Another team disagreed about the values of the team members, which led to difficulties in negotiating a shared frame despite frame conflicts becoming apparent.

It was useful for teams to perform a full iteration of the framing cycle early in the project.

The sooner the team was able to "get on the same page," as many students described it, the sooner it was able to focus on addressing the needs of its users without differences in understanding and assumptions getting in the way.

Discussion Discussion Discussion

The discussion is organized around two major findings. First, while only 8% of the total lecture time is devoted to working in teams, team-related lessons learned account for fully 35% of the total lessons learned. The design coaches also highlight team-related learning as critical. Second, of the process-related lessons learned, 14% concerned Customer and User

Needs, which was at least twice the frequency of mention of any other process-related category.

This discussion is organized around four themes: different views of design, a hierarchical model of design metaphor, universal metaphors and specific implications.

Different views of design Different views of design Different views of design Different views of design I found that different authors emphasize different approaches to framing the design process.

These different views are reflected in the metaphors they use for design and the design process itself. Textbooks adopting more systematic approaches to engineering design typically employ both the Design Is Search and Design Is Decomposition metaphors with different emphases on each. I stress once again that the Design Is Search metaphor was pervasive in almost all sources analyzed.

The pervasiveness of the Search Metaphor for engineering design is an interesting contrast to the more people-centered approaches as put forward by researchers such as Bucciarelli,

Rittel and Schön. Both Bucciarelli and Rittel choose metaphors that emphasize the social aspects of designing using "Design Is fundamentally A Social Process" (Bucciarelli 1988 and and Design Is An Argumentative Process (Rittel 1984) respectively. Schön employs the metaphor of Design Is A Reflective Conversation, or Design Is Problem-Setting (Schön 1983), which emphasizes the two-way and developing nature of designing. Still others have suggested alternative metaphors such as The Design Process Is A Story to emphasize a use of narrative in interaction design (Broden et al. 2004). In this way, our understanding of design is hierarchical and is reflected in the metaphors we use. At the highest level is our view of design itself. Beneath that, our understanding of design's core concepts changes according to the design metaphor currently in use.

As we shall see in the second study in this chapter, this use of metaphor in our understanding of design contrasts with the use of analogy in design which is used primarily as a design tool, in particular during the concept generation phase by making a connection with an existing product or system (Hey, Linsey, et al. 2007 and.

Team lessons Team lessons Team lessons Team lessons

It is not surprising that the breakdown of lessons learned does not match the breakdown of lecture time in the class. Learning about working in multidisciplinary teams is best done by actually working in multidisciplinary teams. And although little lecture time was spent on teams and team dynamics the teaching team did conduct a mid-semester team review in which students were asked to evaluate their team's performance and provide individual reviews of their peers on the team. Let's examine some of the specific things that the students learned.

Of the team-related categories of lessons learned summarized in Table 4.3, the items in the top two categories -Roles, Responsibilities and Skills (22% of the lessons learned) and Team Diversity (20%) -are highly related to working on a multidisciplinary team. Clearly, a multidisciplinary team experience provides valuable lessons that a uni-disciplinary experience does not. A number of students cite this as a primary reason to take the class in the first place. For many, this is the first multidisciplinary project team experience they have had. While many students work on group projects in other classes, few are multidisciplinary, and even fewer require the students to conduct their work and make decisions as a team to the degree that new product development projects do.

Many of the lessons learned refer to the challenges and benefits of working with significantly different disciplines, citing the different motivations, thinking and communication styles of different disciplines as the primary challenges: "It's great to have people who are good at different things;" "People with different backgrounds sometimes speak different languages;"

"Variety of background helps with division of labor, but leads to more misperceptions and greater tensions."

The harmony, difficulties, synergy and dysfunction that arise from working in teams impact the students' experiences throughout the entire product development process. Often, making their team work is the biggest challenge the students encounter, which may lead to the emphasis on team-related lessons learned.

Communication was strongly represented in both the student lessons (e.g., "The way each person communicates his thoughts has to do with his background," and "Don't assume everyone agrees just because they don't speak up") and the design coaches' comments, often as a solution to dealing with the diversity of the multidisciplinary team. Team members in this class not only have to learn to communicate across disciplinary bounds, but must deal with the challenges of not being co-located. The California College of the Arts campus is located in San Francisco, while the other students are all in Berkeley. Even the small distance between the cities creates a significant challenge for the students in scheduling time together and forbids the chance meetings that might happen were they in the same vicinity.

The students also commented on the different choices for communications technology -email, phone, instant messaging -that are chosen and the difficulties in choosing a common mechanism. These issues are not much different than those experienced in industry. See, for example, Allen's (2007) work describing the effects of distance on communications.

Leadership, a common focus for entrepreneurship and innovation programs, is the least represented of the team-related lessons learned categories, accounting for just 2% of the total lessons learned. Leadership tends to show up more in comments about roles and responsibilities, as the students allow the leadership role on their teams to rotate (e.g., "In the absence of an assigned/imposed leader, every team member has in one way or other assumed a leadership role," and "Successful teams don't always have a clear leader or hierarchy."), though this is by no means always the case (e.g. "Assign roles and project leader. No rotation of roles!").

The design teams often split the leadership role into a product champion role and a project management role, acknowledging that the roles might best be played by different people. The project champion is often, although not always, the person who proposed the project. The project management role is focused on keeping the team on schedule, making sure that deliverables are complete, etc. There is some fear among the students of taking on explicit leadership roles that might be perceived as hierarchical in some way, as they are working with their peers. Thus, they tend to use conversation, influence and consensus-building to reach decisions rather than allow one individual to drive them. Not all teams are successful with this approach; some receive facilitative leadership from their coaches at crucial points in the process. Our design coaches told us that this is reflective of a more general trend in industry in which product development, design or innovation teams operate more on the basis of interpersonal influence than on the basis of strict hierarchical control. Leadership roles are often shared among team members.

Customer and user needs lessons Customer and user needs lessons Customer and user needs lessons Customer and user needs lessons Tables 4.2 and 4.4 show that the greatest proportion of NPD process-related lessons learned was in the area of Customer and User Needs. Several factors may contribute to this result.

Perhaps the user needs category is a broader "bucket" than others, thereby encompassing a wider range of experiences and thus lessons learned. Perhaps students were biased to include those lessons, as the overriding philosophy of the course was customer-driven as opposed to technology-driven design, and the class placed significant emphasis on the product definition phases of the process. On the other hand, 15% of lecture time was spent on Customer and User Needs, which tracks with the lessons learned in this category representing 14% of all lessons learned. Examination of the data, however, suggests that this was a category of lessons that were learned by making mistakes (e.g., "Analysis of customer responses and inference of potential product from these needs is time consuming and should be done by the entire team!" and "Spend more time developing your user survey/questions.

You might have only ONE chance.") or lessons that stood out as particularly positive or useful (e.g., "Watching people is fun as well as informative; you find out some things you overlooked."). In other words, the lessons learned were experience-based -positive and negative, and not something they could have learned from the lectures.

While no causal connections can be made from the post-hoc data analysis, there are sound reasons to suggest that the high number of lessons learned relating to user needs reflects both the importance of that phase within the NPD process and its impact on students' experiences. First, as I discuss further below, effective need-finding requires skills not traditionally associated with the disciplines of engineering, business, and information systems management. Effective need-finding requires designers to empathize with their users (Leonard and Rayport 1997), drawing on their listening, observation and understanding skills as well as their intuition. Need-finding is a "fuzzy," non-linear, and inexact process, unlike the more analytical, linear processes often taught within these disciplines. Other phases of the NPD process that draw on more traditional skills may provide students with fewer salient learning experiences.

Second, requiring students to test their products with real users reveals to them the importance of effectively performing the need-finding stage. When a technically proficient design does not please users in the prototyping and testing phases, students may relate this failure to a gap in their understanding of user needs. It is possible, as a result of these experiences, that students associated lessons learned through the prototyping and testing phase with identifying customer and user needs, thus in some ways falsely inflating that category relative to the prototyping and testing category. This may help explain why Prototyping and Testing, while 16% of lecture time, only accounted for 5% of lessons learned.

The emphasis on customer and user needs is reflected in the feedback from the design coaches as well.

I also analyzed the interrelationships between the subcategories within Customer and User

Needs. The interrelationships suggest three interesting aspects of understanding customer and user needs for these student teams: the adoption of new skills, the need for framing and reframing based on user needs and the difficult task of managing and analyzing needs once collected. I discuss each topic below.

New skills New skills New skills New skills

There were many interrelated lessons learned relating to the skills required to do needfinding, particularly in the subcategories of Listening, Observation and Context (Table 4.5).

Some students learned about the importance of effective observation skills (e.g., "Observation is key for identifying user needs."), others about the need for listening skills ("Listen intently to consumers. Their needs should drive every step regardless of the developer's original intent."), and yet others about the need to observe in the context of a product's use (e.g "Direct observation is essential. Experience use in the customer environment.") As the examples show, many of these lessons overlapped. Current design researchers and practitioners also emphasize the importance of these skills in uncovering users' latent needs:

"Today, the message is to observe customers working in context to find out what those customers need, not just what they say they need" (Patnaik 2004). The inter-relatedness of these subcategories indicates both their importance to an effective product development experience and how new these skills are to many students taking the course.

Frames, perspectives and sharing Frames, perspectives and sharing Frames, perspectives and sharing Frames, perspectives and sharing

Together with the subcategories relating to new skills, the subcategories of Perspectives and Sharing raised issues of framing the situation and negotiating frames within the teams. As discussed in Chapter 02, framing is how designers and users structure their experience, deciding what are and are not the important elements of a situation, the boundaries of a situation and the criteria for success. Many lessons learned related to the importance of relinquishing the frames and viewpoints that students originally held and replacing them with the user's perspective (e.g., "Customer needs can surprise you and change everything;

Understanding issues, step into the shoes of your customer."). Related lessons pertained to biases that product developers themselves bring to user research, often obscuring the user's perspective (e.g., "Customer research may be biased by [the researcher's] hidden agenda.").

In this and similar cases, the frames that the developers themselves bring to the situation, may consciously or sub-consciously lead to hidden agendas or biased data collection.

Students identified the resulting importance of developing shared frames as a team. They learned the importance of conversation to create shared understanding (e.g., "Before surveying customers the team should survey itself to ensure a consistent understanding of responses; Analysis of customer responses and inference of potential product[s] from these needs is time consuming and should be done by the entire team!"). And, they learned of techniques such as personas and grounding insights in real user data to assist in the negotiation of different frames within the design team (Hey, Joyce, and Beckman 2007) (e.g., "Being in touch with the end user helps keep things in perspective -Make sure words are always attached to a face.").

Identifying and managing needs Identifying and managing needs Identifying and managing needs Identifying and managing needs Finally, students recognized that figuring out what to do with the customer and user needs once they have been captured is non-trivial. These lessons learned show up in the highly interrelated subcategories of Accuracy, Scope, Latent Needs and Prioritization (Table 4.5), with many lessons fitting into two of the subcategories. Students emphasized the importance of finding the 'right' user needs, or those that resonated most with the users (e.g., "It's important to get true customer needs and do a good job early on so that you pick the right direction in the end."). However, there was also a tension between finding and prioritizing the 'right' user needs to address and limiting the scope of users from which to draw insights.

Several lessons learned emphasized the notion that "Initial customer needs assessment has to be broad with input of several sources," while others favored a narrower scope: "There are many types of users, users are different and you can't satisfy them all," or "You can't please everyone." Though students found it valuable to study a diverse range of users, interactions and scenarios, there was also a feeling of being 'bogged down' in the amount and variety of data that resulted, often revealing conflicting needs. In short, they found that managing divergence and convergence is a difficult task.

Understanding, managing and prioritizing needs once they were identified also seemed problematic. There was an emphasis on the importance of identifying latent, hidden or implicit needs (e.g., "Locating the 'base' need is very helpful; gets thinking outside the box;"

"Ask why -find out what's behind customers certain behavior;" "We are not only designing a new physical product, but a part of people's life;" "Users' latent needs are hard to define but it's extremely useful.") However, deciding where to focus appeared difficult partly due to the different 'levels' of user needs (e.g., "Many times customer needs are all over the map, making it difficult to judge which needs to focus on;" "User needs/wants are often contradictory;" "Hard to get at what truly matters to users (need prioritization).").

Together, the lessons learned in these four subcategories typify what is hard about framing the design situation around user needs and what is so important about doing it well. It is not easy to identify hidden needs that a customer cannot articulate themselves; designers must learn effective observation, listening, and empathy skills. Once needs are identified, it is then difficult to manage and prioritize these needs for the range of users studied. Perhaps the most important underlying lesson the students learned is the highly iterative nature of the need-finding and product development processes. To effectively identify, analyze and prioritize needs, the students had to revisit conversations and other forms of customer needs multiple times. The design coaches also highlight the importance of iteration in getting at core customer and user needs.

Takeaways Takeaways Takeaways Takeaways

I presented an analysis of over 2,300 lessons learned from over 350 students collected from six years of a multidisciplinary new product development class and comments from the design coaches that support that class. It was found that team-related lessons learned are nearly as significant for the students as the lessons learned associated with the NPD process.

Clearly, team and process development complement each other, yet many of the textbooks on new product development, such as the one used in this class, focus almost exclusively on the NPD process with little discussion on what makes an effective team. In fact, it is not unusual for design textbooks and design classes to have virtually no formal content on teamwork. Yet, team issues are hard to learn, as our data from both the students and design coaches suggest, and are clearly critical to NPD success.

These results also suggest, perhaps not surprisingly, that some things are best taught through experience rather than through formal lectures. Team dynamics is one of those topics. Only two lectures, or 8% of the total lecture time in the course, were spent on teamrelated topics, yet 35% of the lessons the students learned were on these topics. Of course, I might argue that more lecture time be devoted to team-related topics given that they are so important to the students. There is no doubt that there are other tools and techniques that might be formally taught to help the students in their teamwork. As for many schools, we are left with the question of how and where team-related topics should be taught. To what extent should a class focused on the new product development process teach teamwork? To what extent can students learn teamwork in a unidisciplinary class (e.g., within the business or the engineering school) or in a lecture-based class? Given the importance of teamwork in industry, and the fact that the students emphasize learning about team skills, this is a question with which many institutions must grapple.

A general theme emerging from the process-related lessons learned is that need-finding is neither formulaic nor entirely methodological. Instead, need-finding is better represented by Schön's metaphor of a reflective conversation (Schön 1983) and Horst Rittel's view of design as an argumentative process (Rittel 1984). Direct, spontaneous interactions with users, within design teams and around prototypes make these early stages of design appear as a form of improvisation (see for example, Weick 1993). The 'back and forth' between developers and users, and within the teams themselves, was clearly evident as the teams negotiated need-finding and iterated toward final prototypes. In addition, there was also the realization that the designer's own viewpoint and expertise remain valuable within the user-centered design process, as eloquently voiced in this lesson from a student:

"While asking the customer what they want sounds so simple and logical, someone still needs to interpret. Even following the best process around, if there is not insight/empathy/ intuition -it's all for naught."

Deeper analysis of these lessons learned identified the importance of new skills for product developers in empathizing with users, including observation, listening and the importance of context. I suggest that greater emphasis be given to the teaching and practice of such skills, traditionally associated with the social sciences and qualitative research. Further, the lessons pointed to the importance of practicing and applying these skills within the context of the design process, for although the instructors of the class cover the basics during class lectures, application still provided many learning experiences. Tools like interviews, observations, and real-world interactions rarely follow predictable scripts; there are simply too many variables and possible outcomes to sufficiently prepare students in the classroom alone. It may be that if part of the benefit of working in multidisciplinary teams is learning from teammates, then incorporating team members with these skills, such as anthropologists and other social scientists, may prove beneficial to teamwork and overall team performance.

Finally, analysis of the lessons learned indicates a need for guidance while understanding, analyzing and prioritizing customer and user needs. While it is clear that teams must engage in a messy and iterative process of gathering and interpreting needs, teams would also benefit from assistance with the framing and re-framing of customer needs. As the class employed both a well respected NPD textbook and current readings this need it is evident that effective coverage is lacking.

The "lessons learned" exercise allowed a better understanding of what the students are learning, and how the class might be fine-tuned in future years. I believe the students also performing NPD in industry? Are these issues specific to an educational setting or do these issues also apply to NPD in industry?

To address questions like these, a longitudinal study was performed by following up with alumni of the UC Berkeley NPD class (Cobb et al. 2008 -working paper). 14 I will briefly describe the approach to this study and some selected results to inform our understanding of the applicability of the original lessons learned study more broadly.

Approach Approach Approach Approach

In the study we reached out to all the alumni we could contact who had taken the class since 1996. Collecting from department alumni databases and faculty records we estimated 282 working email addresses for NPD alumni. These alumni were contacted with a survey. We received 132 responses to the survey, a response rate of 46.8%. As our interest was NPD in an industry setting 10 participants were ineligible to complete the survey as they were still in full-time education. Full numbers of study participants are in Table 4.6.

As it turns out, the most complete records of alumni contact addresses were held by the business school. 15 As a result, of the 282 alumni contacted 186 were business, 88 were from engineering disciplines and only 8 were from industrial design or information management (SIMS) (the industrial design numbers are particularly low partly as a number of these students had taken part in a previous study). The survey questions covered the following topics: satisfaction with the NPD course; ranking of importance of NPD topics in their current job; how user research, concept generation, concept selection and team formation is performed in their current company; tangible takeaways and specific lessons from the class; suggestions for improving the class; the value of the project experience in the class; whether they attempted to continue their project after the class was complete and why; how the class' value compares to others they took in graduate school; contextual information about the current role, industry and job responsibilities. The full survey is included in the Appendix.

The survey also asked alumni if they were willing to participate in a follow-up interview. 30 alumni agreed to be interviewed and 19 phone interviews were conducted by the three researchers. The interviews were conducted after the initial survey analysis and therefore questions were asked that both helped further understand the aggregate survey responses and that probed further into the individual responses each alumnus gave.

I will discuss results from specific sections of the survey most relevant to the discussion of NPD learning and importance of topics in industry.

Results

Results Results Results

The survey analysis was performed by three researchers. We performed simple compilations of numerical results but also broke down the responses to questions by industry, current job type and discipline (Engineering related, MBA or industrial design) when they took the class.

Similar to the analysis of lessons learned, responses to open-ended questions were first analyzed by a single researcher and coded with an evolving set of codes. This initial sorting was then reviewed by the other two researchers and categories and codes were updated.

Discrepancies and difficulties in applying codes were discussed and resolved among the research team. The topics in this question were chosen to allow comparison to the lessons learned study that evaluated directly at the end of the project experience. With the lessons learned study I evaluated the importance of each topic inferred from the frequency of mention of lessons from each category. However, in the alumni survey we asked a more direct evaluation of importance. Because of the bias towards responses from business school alumni it is most instructive to view the importance of topics as rated by each discipline -Engineering, Business (MBA) and Information management and industrial design (SIMS). This data is shown in Figure 4.3 with the topics ordered according to importance from the lessons learned study.

In this section I identify the most frequent metaphorical concepts employed in the design texts and the most frequently used metaphors for each concept found.

Metaphorical concepts identified Metaphorical concepts identified Metaphorical concepts identified Metaphorical concepts identified I grouped the metaphorical concepts referred to in the design textbooks into three categories sorted by frequency of mention: Universal, Often and Occasional. Design concepts universally used included references to design itself and the design process, ideas, concepts, problems and solutions. Concepts seen often in our analysis include user needs and design tools or methods. Concepts mentioned occasionally include design conflicts or trade-offs, design principles, and references to creativity. All of these concepts are the Target domains for the subsequent analysis; they are the domains that we are trying to understand. The universal and often mentioned concepts, and their frequency of occurrence, are shown in Table 7.3. Metaphor instances and mappings Metaphor instances and mappings Metaphor instances and mappings Metaphor instances and mappings I followed a process of grouping each of these affordances in the instances coded to help determine the metaphors in use for each target domain. Below I present the results of the analysis in the form of a metaphor in use, together with the affordances that led to the identification of the metaphor. I begin with the universal design concepts, Ideas, Problems and Solutions. For each affordance listed below at least one instance of it in use was extracted. In some cases such as "Ideas can be generated," examples were so numerous at some points they were present in almost every sentence.

The analysis shows that student design teams employ both analogies and metaphors in the design process (Figure 7.5). Table 7.4 shows that over 65% of the design teams, in the studies, used metaphors to frame their problems and about half of the design teams took advantage of analogies to generate solutions. Students who took part in the concept generation experiment were previously exposed to using analogies for idea generation in their engineering design methods class. While analogy use to generate solutions appeared spontaneous, almost no metaphors were mentioned in concept generation. Students who had been exposed to the technique of design-by-analogy spontaneously used it when asked to generate design solutions. This result replicates prior findings (Linsey, Laux, Clauss, et al. 2007), but does so within the real-world knowledge domain of engineering.

Though there was no formal teaching of metaphor use in design, 8 out of 12 design teams highlighted a metaphor in the problem framing stage as an important factor in their project.

For example, one team, developing a software product for social networking, searched for a suitable comparative business and used photo-sharing: "we saw it as organizing your collection of pictures, which is very tedious to do but once you have it nice to have. So that's what we thought we were trying to do with networking … it's kind of annoying to do networking all the time but it's nice to have a social network in the end." Extending the photo-sharing comparison the team explained "we were the Flickr of social networking -And it just helped us frame the whole process." • "Staple remover design" • "rotating blade shells peanut (analogy to potato peeler)" • "Similar function to putting your hand in a bicycle chain, except your hand is replaced by peanuts" • "maybe like two pencil sharpeners that are put opening to opening" • "the peanuts can be collected with a device that attaches to a bike and acts like a golf ball picker-upper-thingy." • "A rolling type of mechanism, much like a Roots-Style supercharger, with rubberized "fingers" or slots,… the peanuts are fed by gravity into the roller, hopefully the shells are crack." • "A rolling mechanism like a ball bearing grinding machine. Two large round plates with spiral grooves cut into them that spin at a fixed distance from each other and in opposing rotational directions. " • "Use a device with two pliers like shell crackers opposing each other." • "Develop a large clamping platform with a bottom stationary plate and an opening/closing top plate (like a Foreman Grill ™)." Further examples include a team that explored developing a NASCAR style fast food drivethrough experience, and a team developing a device to remove blood clots that viewed the situation as akin to plumbing -they were creating pipes.

Comparison of metaphor and analogy u Comparison of metaphor and analogy u Comparison of metaphor and analogy u Comparison of metaphor and analogy use se se se

As Table 7.4 shows, metaphors were most frequently used to frame the design situation whereas analogies were most common for generating solutions to the design problems.

Although these data are not sufficient to prove this trend, the result is compelling and warrants further investigation. The data supports Casakin's results that students had an easier time employing metaphors to assist in framing their problem as opposed to using metaphors to generate solutions (Casakin 2006). The data from the new product development interviews illustrated use of metaphor in the early problem framing stages of the design process. For example, the 'Flickr of social networking,' the education restaurant metaphor, and the manufacturing spellchecker metaphor allowed the teams to see their design situation in a different way. These results are in contrast to the results of the analogy study that showed how analogy contributed directly to the development of new solution concepts rather than providing an understanding of the design situation.

The prevalence of metaphor in the early stages of the design process may stem from the teams' search to understand a complex human design situation. A metaphor helps bring structure to the design situation and acts as a meaningful communication tool to the rest of the team. The metaphor helps the design teams figure out a story that makes their design project make sense. In contrast, the concept generation phase is often concerned with more technical aspects of design problem solving where the emphasis is on finding a technical solution that will work and is innovative rather than a story to help make sense of the situation.

Figure 4.3 Importance of NPD topics 16 by discipline

An overall slope of the lines can be seen from top-left to bottom-right implying that the general structure of importance is similar to the original study. In particular, working in multidisciplinary teams, customer and user needs and meetings and scheduling remain important, while, at the other end, design for X (e.g. design for the environment, universal 16 Topic names have been abbreviated for clarity of reading design, manufacture and such) remains the least important in current alumni work. The peak at project management for all three disciplines suggests that this becomes more important in industry than in the class setting.

The standard deviation of the responses informs us which topics are viewed commonly across disciplines and which are more discipline specific. The discipline specific topics (σ ≥ 0.5) are design for X and prototyping and testing. In particular these topics were valued less by business alumni. The most discipline independent topics, somewhat unsurprisingly, are meetings and scheduling and project management (σ < 0.2). The differences across disciplines I believe largely reflects the emphasis engineers place on design and manufacturing with higher importance given to prototyping and testing and design for X than business alumni.

However, the highest rating for prototyping and testing is given by information graduates and industrial designers perhaps reflecting the importance of agile development methods in the software industry.

In general though, the alumni data suggest that working in a multidisciplinary team and dealing with customer and user needs remains important in industry although other topics, particularly management related, gain in importance.

Interviews Interviews Interviews Interviews

Interviews with the alumni provided extra richness on how their experiences in industry compared with their experience in the product development class. In particular, recurrent themes included the continued importance of working on multidisciplinary or crossfunctional teams, recognizing the importance of a user-centered process but difficulty in applying it in context (in particular between large and small firms), and learning general rather than specific skills. I'll discuss each of these briefly in turn.

The majority of interviewees emphasized the continued importance of working on multidisciplinary teams. For example:

"The multidisciplinary aspect of it is absolutely critical."

"[A lot of what I do now is] thinking beyond the discrete steps -looking more holistically -really it's getting people in front of one another -recognizing we're not just a bunch of individuals."

"Working on a cross-functional team is so important. I know that today more than ever -the vast majority of my work is on a cross-functional team. In all my classes at Haas that class was the closest to reality."

"Specifically about product development, I've done many product or service development projects -I see them as very similar, it may be a web developer instead of an engineer or a graphic designer or the brand developer, and that's where you, as leader of the team, can come up and shine. You already know how the different functional people speak and think. So to me one of the key learnings was that, coming from a particular discipline I have a very skewed view of the project. But the important thing here is to learn to listen to other disciplines and learn how to incorporate everything together."

"The course was one of the first places you realize -'Holy cow! Not everyone's like me."

In these excerpts we are able to appreciate the continued appreciation of an early multidisciplinary experience and its relevance in the workplace. In particular, there is an emphasis on gaining an appreciation that not everyone on your team is like or thinks like you and how a successful team can turn this into an advantage rather than a barrier.

Another theme was appreciating the value of the process, particularly with respect to performing user research. But, across the diverse areas alumni are working they often met with some resistance to the structured process from the class and the 'novelty' of direct contact with users. As a result there were calls for learning not just how to go through the product development process but how to persuade the 'C-suite' managers of the value of its value.

"I suppose it prepared me very well within a structured environment because it's…very distinct, very defined. Within the chaos of a startup…a lot of that structure loses some of its meaning and value."

"At least in my case, everyone came with their own experience and background. I was trying to introduce a user-centered process. It actually seems pretty novel for when most people hear about it. They think, "Oh, you're going to talk with customers and follow them around in their house for a day. Hmm, I don't quite get that."

"One of the key differences is when we were going through the process. Because we were all in the class we all kind of learned about different pieces of the process and we were all really invested in learning and applying the methodology. I've found that in industry it's a very 'new' process that companies/some people may not be use to using, to that effect they may latch on less to the notion of how you're going to go about the work. "

"I think the biggest difference is that in the artifice of the course everybody's being directed to understand its value artificially because you're in a classroom environment. No one has that mandate because you don't have forced mandate. You may understand the process and value and need to go through it however those above you or your peers may not have that perception or understanding."

Another theme concerned the learning of more general rather than specific design skills.

This was reflected in survey responses where more people said the class has been useful to them since leaving school yet they do not use specific lessons from the class in their day to day jobs. This may also reflect the Design for X specific skills being rated as the least important in their current work. Comments included:

" I think it's an overarching picture that allows you to shape your mindset, but not necessarily direct skills."

"I mean the best classes aren't classes that give you a specific tool, rather classes that tell you that OK, the world is so heterogeneous so that we're going to teach you how to think so you can apply the knowledge over multiple scenarios."

One alumnus memorably summed up the situation in this way:

"It's like I may know this is my favorite restaurant but I can't think of anything that's on the menu" Data collection at MIT was primarily performed by a research assistant locally following a prepared data collection protocol (see Appendix for more details). In addition, myself and Caneel Joyce were present at the end of the class to perform team interviews and videotape the final presentations.

Even with this multitude of data, finding framing is challenging. Frames are cognitive, often implicit, and reside in the minds of individuals. For teams to negotiate a shared frame, an individual's frame must be shared explicitly or otherwise suggested through interactions and behaviors. Furthermore, it is possible for a team to ignore the frame of an individual member and continue its activities without that member's buy in to the project direction.

Thus, in our observations we looked for activities and interactions that (1) revealed an individual's implicit frame to others, (2) made discrepancies between individuals' frames visible or salient, or (3) engaged the team in explicitly negotiating among individual frames and constructing a shared frame. Each of these activities concerned a change in one or more of the key frame constituents: overall goals, selection of important or unimportant features, setting boundaries to the situation and selecting, though often unconsciously, evaluation criteria.

The multi-method perspective provides rich data for theory-development, enabling the observation of team-level framing processes while understanding fine-grained differences between individuals' frames.

To find framing activities we took a flexible approach to our data analysis. Each researcher made a careful note of key events witnessed in team observations either in meetings or class labs. We shared key quotes and stories from these observations and extracted telling phrases from the survey responses. 19 At each stage the shared team documents were used to supplement our understanding, yet the public face was closely compared to the interview responses that provided a more nuanced and detailed view of their development. Often a statement from a team interview gave the opposite impression to that given by a document.

For example, the unified team face given by a team's presentation often belied the uncertainty of the late night contentious meeting that resulted in it.

Goals

Stakeholders and selection of primary and secondary markets weight as a key concern for users they are simultaneously making the implicit assumption of a product that will be carried (like a bike lock) and establishing weight as a criteria for which they can evaluate potential concepts. This finding supports Mohammed's assertion that: "Groups composed of individuals with a high commitment to their constituency position will achieve less cognitive consensus than will groups composed of individuals with a low commitment to their constituency position," (Mohammed 2001). The project champion, having often invested personal time and mental energy into the project, has a higher commitment to the initial project proposal. She brings with her a different individual frame than other group members. Teams that start with a broader initial mission based off common values, such as an environmentally conscious proposal, typically find the transition easier from a group of individuals with different perspectives to a team with a common vision. For example, one team began with the broad goal to develop a product to help reduce childhood obesity. Without any specific commitment to an initial approach early on, the team was able to learn about and frame the situation together. Higher commitment to an initial approach may lead to greater emphasis on a team developing what the designers think is important rather than what users value. Another team began with the strongly solution-focused goal of creating a treadmill that was also possible to work at -you could lose weight while you worked. The high commitment of the team member who proposed this project meant she had high resistance to change. Only in the face of data presented by the whole team and with intervention from faculty, did she become open to framing the project towards the needs of its possible users.

Starting with a need based on a product also leads teams to do 'product-focused' research rather than listening to the people and trying to understand what really matters to them, for example, asking questions about the use of a particular product rather than learning what's important to the participants. This approach closes down the range of opportunities at the outset. Product-focused research also surfaces a deeper ethical issue of choosing which target market to address. If many types of people use a device for different reasons how can a team decide who has the more pressing needs to address?

2. Mission statements: process rather than artifact 2. Mission statements: process rather than artifact 2. Mission statements: process rather than artifact 2. Mission statements: process rather than artifact

The process of creating and iterating the mission statement, The process of creating and iterating the mission statement, The process of creating and iterating the mission statement, The process of creating and iterating the mission statement, rather than the artifact itself, rather than the artifact itself, rather than the artifact itself, rather than the artifact itself, provides greatest value to design teams. provides greatest value to design teams. provides greatest value to design teams. provides greatest value to design teams. As two team members suggest, the iteration process was more beneficial than the artifact itself:

"To resolve a discussion we never said 'let's check the mission statement'. It was something that, after the discussion, we just kind of kept the core project goals in mind. The core concept kept us on track." "I feel I viscerally know what our mission is and don't need to refer to it, and that we all agree. But we do need to revise it."

Discussion of the goals of the project elicits team member opinions about those goals thus helping reveal their frames. When team members take the time to discuss and select a shared goal they become open to adapting their frames, creating a common reference for both discussion and evaluation of possible project directions.

Even with a semi-formal agreement within the team, however, it was not always clear to all members what decision had been made and whether all team members fully bought in to the new frame:

"Did we agree that we're going to focus on [x]" "Yeah"

"We're on the same page."

"What page?" And:

"We had a really hard time deciding on an area to focus on. We had a lot of discussion and as a group we thought we had reached a decision and then one member decided that we should change the focus the next day. The rest of the group basically went along with the idea since we needed to move on."

And:

"Concept idea convergence is difficult, especially when the overall mission & goals are not well defined or fully accepted by all the team members."

"One member of the team doesn't seem to 'get it', meaning the purpose and emerging design of our product."

In these examples, some members of the teams reframed their project goals, while others had yet to do so. The differences in individual frames clearly caused confusion as to how to proceed. In some cases it was possible for teams to agree to disagree and come to a shared frame by seeing one another's perspective:

"In at least one case we had all but one person of the team agreeing on something. Although the last person did not agree, he understood where other people were coming from and we tried to understand his viewpoint.

Eventually we had to settle on the majority, but he was very graceful about working with the team even though he obviously felt strongly about his idea."

Strong and open communication facilitated this result. In one group, for example, three members of a team were enthusiastic about the direction their project had taken, a more appropriate means for business professionals to take their own lunch to work. Yet, the proposer of the project said after the project was complete that:

"Although my team like the idea I will scrap it after the project is over and make it how I think it should be done."

While you may expect this attitude to cause a dysfunctional team, in fact, the team member was very open with his opinion. This led the team to be able to move forward despite the differences in opinion. In other groups, lack of a shared frame without open communication resulted in tensions and conflicting ideas without effort to 'see where they were coming from'.

The situations above support another of Mohammed's (2001) propositions that: "Groups whose members inquire concerning the reasons underlying others' decisions preferences, accept others' viewpoints as legitimate, and incorporate others' perspectives into their own interpretation of the issues will develop greater cognitive consensus than will groups whose members do not engage in these activities."

Mission statements that were written at the level of agreed upon user needs or shared values Mission statements that were written at the level of agreed upon user needs or shared values Mission statements that were written at the level of agreed upon user needs or shared values Mission statements that were written at the level of agreed upon user needs or shared values served as guiding visions for the teams, and required less iteration throughout the project served as guiding visions for the teams, and required less iteration throughout the project served as guiding visions for the teams, and required less iteration throughout the project served as guiding visions for the teams, and required less iteration throughout the project.

The 'Healthy Meals for Schools' team, for example, started with each member writing his or her own statement and found that they were remarkably similar and forged a joint statement that remained the same throughout the project. The team attributed this coherence to the mission acting as a reflection of the team's values of providing a socially responsible solution, rather than tying them to a particular solution direction or even need to address.

When the overall project vision was clear, as in this case, conflict regarding the direction of the project shifted to a lower level of abstraction (e.g., choosing categories of solutions, selecting means of achieving the team's goal). Having a strongly shared higher-level goal that coincides with team members' core values provides clear criteria to evaluate decisions and suggestions. Shared 'higher level' mission statements also resulted in, as an instructor put it, "less mission statement churn." There were fewer iterations seen in the mission statements than in past years when initial mission statements were narrower. This exemplifies the difficulty, highlighted by Stumpf and McDonnell (2002), of identifying "levels of frames." In this case the team shared the same high level frame as defined by the members' shared values, yet differed on more pragmatic aspects of the project. "Can you define 'to be interested'?"

Research approach Research approach Research approach Research approach

This second framing study took as its base a substantially greater range of teams than led to the identification of the framing cycle. In total 57 teams were tracked in detail and interviews performed with 36 teams. The goal in each case was to understand the story of the team as the team members saw it and understand the decisions that defined its path.

Our research approach was designed to complement and build on prior work. Prior studies are based on a relatively small, though, rigorously analyzed, number of design projects.

Other than several industry design team case studies, the teams typically studied in the past are uni-disciplinary rather than multidisciplinary. That is, participants were typically teams of engineers. The scenarios studied were also highly compressed design scenarios taking place over the course of a few days or a few hours. Finally, while the prior work has illuminated much about team framing and shared understanding, there is little in the way of concrete advice offered for design teams.

To support these studies then, our research approach has been based on a number of important factors. We studied a large number of design teams -over 50 projects were tracked in detail. To do this we studied graduate NPD teams that also enabled us sufficient access to data. Multidisciplinary teams were composed of engineering, business, industrial design and information systems backgrounds. Rather than a few days, projects were carried out over the course of 13 weeks. This enabled us to learn from the full context of design team activities including user research, incubation, iteration and extended team dynamics.

As discussed in Chapter 03, the design class context introduces some peculiarities relative to design projects in industry. Teams work in a more flexible, ad-hoc environment without existing organizational infrastructure and are free to select their own team leaders or agree to have no official leader. Students also have the opportunity to select their initial project focus and the latitude to reframe their project away from the initial focus as user research

dictates. Oftentimes such modification goes beyond what would be possible under industry, and brand, constraints; of flexibility in industry projects a senior human factors specialist at IDEO once related to me her frustration at having , "experience working on an uninteresting problem right next to an interesting problem and not having the power to turn the tanker…"

In the design class we allow our teams to turn the tanker. Teams also benefit from the advice and guidance of a design coach and faculty. These differences are highlighted to better understand the context in which the projects operate. However, as the class and design teams are modeled after industry practice, I believe that these results also apply to industry design teams, a belief partially validated by recent longitudinal studies of graduates who have gone on to work in industry (Cobb et al. 2007). This is also addressed in the case study at the end of this chapter.

Prior approaches to measuring team framing have included survey-based approaches where individual team members respond to a series of questions developed about their task or context including the relatedness of relevant concepts. Shared understanding is inferred based on the degree of overlap of their responses (see Mohammed et al. 2000). A related technique is Concept mapping, where participants are asked to map concepts to different aspects of their task domain (e.g., Marks et al. 2002). These techniques have the advantage of providing a quantitative measure of overlap between individual mental models. However, most prior studies have involved command and control tasks in simulations where the relevant concepts and content of frames can be specified in advance (for example, by experts in the domain) and used to create the measurement instruments. We followed the advice of Badke-Schaub et al. (2007), "Given the uncertainty and dynamic nature of the creative process, it is unlikely that the content of mental models could be easily specified a priori and supplied to participants as has been done in performance-focused team samples. Therefore, it seems more useful to elicit the content of mental models from expert designers using qualitative techniques at appropriate times during the process." In other words, as researchers, we cannot know in advance what will prove to be an effective framing of the design situation. The content and context of the frames are continually changing throughout the process as the team makes important decisions based on the results of their user research.

Consequently, to overcome the limited ability of highly structured experimental approaches (Marshall 2007) a more integrative approach was adopted tying together observations, interviews -framing in their own words -with design artifacts -the content of frames as presented. We were investigating a combination of both task and context framing -framing regarding the needs, constraints, opportunities, boundaries and target market being addressed. The qualitative observational approach allowed us to better follow the socially negotiated character of design team framing that is not a "straightforward aggregate of the individual cognitions of its members" (Marshall 2007).

This approach provides an important additional view into design team framing activities due to the research context -many, multidisciplinary, 13 week design projects -and the integrative approach to data collection (in contrast to, for example, the controlled setting and quantitative measurement approach by Bierhals et al. (2007)). This approach therefore has the potential to understand design team framing in a more holistic way than prior studies and provide insight into the effects of longer term activities such as gathering and digesting user research. Traditional analysis of design team documents including design journals, presentation decks, concept selection documents and concept sketches provide only a partial understanding of design team activities. These information sources therefore were supplemented by team interviews. Group interviews were found to be effective at eliciting differences in opinion at

The Design Path framework The Design Path framework The Design Path framework The Design Path framework

In this section we present a framework that has helped us better understand the twists and turns of design teams. A good framework must be accurate, clarifying and actionable. This means the framework should reasonably represent the world, or selected aspects of the world, it should make things clearer, and, to be of use for a designer, it should point the way to action. We believe this framework meets these criteria through: (1) being constructed from a study of 57 design projects and interviews; (2) teasing apart the often conflated dimensions of framing and shared understanding; and, (3) by visualizing these dimensions and opening the way to interventions and awareness to help address problems.

The Design Path framework is shown in Figure 6.1.

Figure 6.1 The Design Path framework

Design path dimensions Design path dimensions Design path dimensions Design path dimensions

The framework is built out of two axes. The horizontal axis is the framing between the design team and its eventual users. The vertical axis is how much the team is on the same page internally, or its level of cognitive consensus. There are no strong reasons why the axes are chosen as horizontal or vertical. For clarity we will present the framework through-out in the same orientation. Let's take a look at each axis in a little more depth.

Framing between designers and users Framing between designers and users Framing between designers and users Framing between designers and users

The horizontal framing dimension is a measure of whether the designers' framing of the situation is matched with how users see the world; is the problem to be solved one that has value for users?

The selection of this horizontal axis is based on the observation that a large number of design teams alter their initial project proposal as the project progresses. This reframing may occur for several reasons: the original need is found to be impractical due to technical, business, time or expertise constraints or unimportant for the target group; or the target group itself is changed. With each reframing, a change of position along the framing axis, the team ideally moves towards a framing of the problem that better reflects what the target market really needs.

To create a successful product those needs must also be poorly met by existing products. Kim and Mauborgne (2005) give the example of Yellowtail wine's identification of an opportunity in the U.S. wine market. The U.S. wine industry had been focusing on "how to create a more sophisticated wine for special occasions." Yellowtail found an opportunity that better matched how its target customers think by reframing the challenge "to a new one: how to make a fun and easy-to-enjoy wine for every day," (Kim and Mauborgne 2005 112 Accuracy in this context also can only be evaluated through testing with users which, in the case of some projects, is sometimes only possible towards the end of the project. The design teams themselves however, often clearly revealed in interviews whether they had a matched frame with their users when they described the results of their testing activities. For example, to protect children from finding chemicals and medicines in house cabinets, one design team we studied developed a 'play station' to occupy children while their parents were busy. But when they tested it with parents they found, "The parents just didn't get it. We said it was a safety device, so they didn't understand how it could also be a toy." The team had failed to match their users' frame.

As teams move from left to right they learn more about their users building empathy for their situation (from em -in, and pathos -feeling) and an understanding of the customer need. The team begins to see the world through the eyes of the people it is designing for (e.g., Seybold 2001; Leonard and Rayport 1997). At a more fundamental level, as teams move from left to right, the designers get closer to making, as Malinowski famously put it, "the psychological transference whereby they becomes we," (Stocking 1983).

To better illustrate this reframing that occurs, Table 6.1 presents a number of mini-stories illustrating the initial framing of the project by the team, an insight from user research that led them to change it, and the final framing for the project.

Shared understanding Shared understanding Shared understanding Shared understanding

The vertical axis of the framework is a measure of a team's agreements on the framing of the situation, in words that design teams themselves use, how much they are on the same page.

This axis mimics Mohammed's continuum of cognitive consensus discussed in Chapter 02 (Mohammed 2001) and sharedness as described in Badke-Schaub et al. (2007).

In practice, team members can be on a different page from each other for a number of reasons. They can be in disagreement about the target market they are designing for, about the needs they are trying to meet, and how the team should address the need. It is also common for design teams to believe they are on the same page when in fact many differences of opinion lie beneath the surface. The framing cycle implies that if these undercurrent differences are not moved into the open before the team must make critical project decisions then the resulting conflicts may seriously hinder progress.

As with the framing axis, the measure of the team's agreement can be expressed in multiple similar ways. It can be understood as a shared understanding of what the project is about, or it could be defined through a metric like that of semantic coherence (Song et al. 2003). As a team develops a shared understanding and language it also begins to develop its own team culture -an agreement on shared public meaning. Teams transition from a team of individuals pushing different perspectives to a unified, directed team. As with the framing axis, the team makes a transference whereby I becomes We, as team members and their different perspectives are acknowledged and understood. Teams themselves also use alternative metaphors to 'being on the same page' including cohesiveness, developing a bond or gelling, standing together, or aligning. experience. Yet teams are taught to follow the same basic process and adapt it to their situations. As a result, teams follow the same basic stages of research, needs analysis, concept generation, selection, testing and iteration but do these on very different subjects and at different times.

In determining the position and movements of the design teams, we turned primarily to the interviews, survey responses, design documents and journals. In many cases, only with retrospective knowledge of the project were we able to confidently place a team in the framework. For example, it is only after user testing that teams were able to determine if their frame was matched with their users. Following each team's story we looked for actions supported by quotes, stories and observations to determine their movements.

With blank frameworks two researchers separately plotted the path of each team as they saw it supporting each location and movement with quotes and observations. Thus each position was typically supported by two or more data points from observations, team documents, interviews, survey responses, or project journals. The paths were compared and differences in interpretations discussed. It was ensured that the data collected made the final decision.

Using this method paths are not precise measurements but illustrative of the general state of the team at different stages in the design process. The transitions are the broad movements of each team.

When the different paths design teams take through the process were mapped onto the framework, three recurring situations were found which I termed: Back Roads, Backtrack and Direct. In this section, by means of a prototypical case study for each, I'll discuss these three patterns, their traits, distinctions and typical outcomes for the design teams. I highlight in each team's case a quote or observation that supports each position on the framework (The Backtrack and Direct cases each have two possible starting points shown).

More details on the protocol used to assist with classifying the different paths and positioning the teams on the framework are included in the Appendix. The Back Roads design path ( Figure 6.2) is usually characterized first with the team beginning on the same page but within its own frame; the team often has a strong idea of what it thinks its users want and the team members are enthusiastic behind that vision.

Figure 6.2 The Back Roads design path

As the teams perform user research they begin to gain a better understanding what their market wants. Yet, at the same time the team members learn different things from speaking with different potential users. The team members formulate individual opinions that differ from one another. Often, members attach themselves to the needs of the users they spoke with. The team can go through a difficult period of uncertainty as each member believes the team is confused and they struggle to integrate all they have learned. Yet, as the team takes time to share using rich methods and tools and sift through its research team members begin to understand each others' perspective and the different needs each member identified. The teams consolidate their ideas and frame the situation around one or several core needs of their users rather than the designers' original visions. They deliver, or at least attempt to deliver, a product their users really want. healthy instant noodle." The idea is easy to visualize and seemingly easy to implement -the team began largely on the same page: "coming into class with this very clear idea, this experience that I completely related to and what I wanted in this product" (position 1-see Figure 6.2). Yet this is a product the team wants based on the team members' own experiences which they can not be sure is shared by their potential target customers. The team performed deep and effective user research to get at some of the deeper reasons and attitudes behind eating instant noodles. Team members collected a lot of data and stories causing them to relate to different needs and users reducing the initial team cohesion. The team began to feel as if it were "totally out in the middle of nowhere … so far away from instant or … so far away from noodles" (2).

After gathering and analyzing customer needs, project deadlines require the teams to present a project focus. The team first chose a framing based on a mix of what they had heard, one that highlighted the traditional and authentic noodle experience. However, their design coaches slammed them saying "you can't just bandy about the terms traditional and authentic." The team reexamined what it had heard and refocused on the common core need:

"that really forced us to…reexamine, go back and do like six more prototypes and really focus, zero in on how do we get the culture, how do we get to authentic and tradition and we wanted to get at it through fresh…Food that conveys freshness and health through a traditional recipe" (3). The reframing was right for the team's users and the members could relate to it from what they had experienced and heard in their research. With this core need as a focus they developed a product, integrating fresh vegetables and a novel, transparent packaging design emphasizing freshness that their users loved (4). Teams in this situation often enter the project with an attitude seeking to confirm what they see as the problem, rather than learn how the users view the world. As a result, they often collect only shallow data from user research based around the initial product frame without any major insights. When seeking to confirm a need for a product you hope to build it is easier to both ask leading questions and shallower questions that do not get at users' deeper needs, for example, asking, "How would you like it if you could exercise while you work?"

Rather than, "How do you feel about exercise?" When pressed by coaches or faculty to broaden their research they may take new directions and try to expand their horizons but too often too late. Teams will often have learned more about their target market's real needs but not have time, or the motivation, to follow up a completely new path. Pressed by a decision point the team is trapped by its research. To make a decision the team backtracks to its original framing of what the consumer wants. Depending on how the team did its research this decision to backtrack can often cause conflict.

Airport seating case Airport seating case Airport seating case Airport seating case

The Airport Seating team began with the central experience of one member, a frequent flier, struggling to find a comfortable seat while waiting for a plane. He had an insight that if you could also comfortably sit on your luggage then seating would never be at a premium at airports. While the project was pitched more generally as seating at airports, this idea lay beneath the suggestion: "we were already thinking of luggage you can sit on" (1).

The team's initial research accordingly revolved around chairs and seating. Team members observed people of all ages sitting on the floors at airports, families, business people, students and more. The team was urged to dig deeper and try to understand the broader needs people have at airports and the team did this, reframing at a higher level: " [Our] mission statement changed to problems associated with waiting while you are traveling in an airport" (2).

The team used these broader needs to develop concepts ranging from renting chairs to using a pager system that radically changed how people board flights. With its broad user research across all market groups and very diverse ideas, the team struggled to select a concept or even a focus. The team struggled with the level of abstraction of the solution -a focused product such as the design of a chair, or an attempt to define a new airport experience based around the travelers rather than the airlines. Individuals sided with the users they had spoken with leading the team to lose its cohesion internally (3). As time pressure drew on they had a "marathon" meeting to make the decision as to which framing to adopt. The team was divided as each member had spoken with different people and seen different things. Yet, the bulk of their research was based around seating; at this late stage it was difficult to switch focus towards needs and solutions they had less research to support. The team backtracked to the original proposal idea, the luggage chair (4). The team was largely able to unify behind this decision -in some senses it was the easy way out, sticking with something they knew -but ultimately the process was not based as much on a deep understanding of their market as the original intuition of the design team itself. Characteristics of these teams include doing their research together. When the teams perform their user research together team members share experiences with users. As they learn about their real needs more than one team member can appreciate and stand behind the needs they observed. However, doing research together can lead to missing some educational side trips or back roads. If they do not perform research together, these teams will often share their research richly with the rest of the team. They will use photos, video, stories, quotes and transcripts to communicate what they experienced in the field. This rich sharing helps the entire team to relate with the user and the perspectives of the team members. Often, these projects are explicitly designing for a target market more difficult to access or very different from the design team; for example, in these cases, the design teams are students and working professionals, but their target markets may include the elderly, doctors, children and so on. The effect of the different target market is to require the team to step out and learn from its users as it begins with little prior knowledge.

Figure 6.4 The Direct design path

CAD (Computer CAD (Computer CAD (Computer CAD (Computer----Aided Design) Estimation Case Aided Design) Estimation Case Aided Design) Estimation Case Aided Design) Estimation Case

The CAD Estimation team came together with a strong original focus based on academic research, a tool to give designers information about manufacturing problems during the creation of CAD models. The original mission statement clearly stated the technical problem they had to solve (1). The focus also became the team's name.

The team needed access to professional practicing engineers and designers to understand what it needed. It took time to arrange meetings as access was limited. For each interview, the team took full advantage and all team members were present. The team took detailed transcripts of the interviews and took time to discuss each interview in depth including their own opinions and surprises. The team found that customers were cold to their original product idea and found itself pushing harder to find a need that was not there. One member explained: "We even tried to steer some of the initial interviews to get that result … because that was the whole reason we were doing this: To almost legitimize the initial idea." As another member later put it: "[In] research you try to find a hard problem, not something that people want maybe… Cost is something [our users] can relate to a lot easier than how easy a product is to manufacture. Once we found that we stepped back and found another goal." Learning from their research the team reframed from ease of manufacture to early cost estimation.

Yet, the Direct path does not imply an easy transition. As one group member recounted about the reframing, "we all kinda' had the wind knocked out of us as a group -when we had to just change gears" (2). But it was the team that was knocked out rather than individuals on the team. Though they found out that their initial product was a mismatch with their target market's frame, they at least were all working from the same information. They struggled together. When the transition was complete and the team accepted they had found a frame matched with their users, the technical aspects were readily overcome because the team had a clear shared understanding of what was needed (3).

Frequency Frequency Frequency Frequency

We observed all the three design paths occurring frequently over all the design teams studied. Table 6.2 shows the frequency of each path, the average per year and the standard deviation of the frequencies over the four years of data collection. The high standard deviation of Back Roads and Direct reveals that different years of the class had slightly different patterns. I believe this may be due to factors such as whether projects have a target market different from the students and one year where projects were given a focus of social responsibility. However, I have been unable to find significant correlations for possible causes suggesting an area ripe for future research. The paths of seven teams are not included as the teams treated the project almost as a technical problem-solving challenge. These teams did not move significantly on the axes as they did not learn anything significant from their research to change their original vision.

Quadrants and movements Quadrants and movements Quadrants and movements Quadrants and movements

As we see from the three design paths most design teams begin their projects on the left two Similarly, discussions over a mission statement, who should be research participants and what research questions are important will tend to move a team upwards.

In general, performing good user research will move teams to the right along the framework as they better understand the needs of their users. Performing user research as individuals however, will tend to move teams down and right as, although they learn about the users, team members learn different things, attach themselves to different needs and their individual frames diverge. In contrast, performing user research in pairs or as a team will tend to move teams up and to the right, though in gathering data there is also the possibility for added confusion.

It is also possible for teams to move from right to left on the framework as we saw in the is problematic when group members still hold different frames regarding an innovation, and more so, when they are unaware of how they differ (Sproull and Hofmeister 1986).

Prior studies have also shown that projects will be more successful when they have successfully framed the situation around real user needs (e.g. Zirger and Maidique 1990;Rothwell 1972). This observation does not hold in all contexts as many breakthrough products originally meet with strong resistance by customers and investors. The value of the radio, for example, was lost on an investor who retorted ' [it] has no imaginable commercial value. Who would pay for a message sent to no one in particular?" (TerraMedia 2008). Yet even then, radio took many years to be adopted and recent authors have argued that the most successful breakthrough products should be "boring" (Wai and Mortensen 2007).

Therefore, within the scope of the majority of design projects we can expect successful teams to end a project on the right of the framework.

It is also entirely possible for design teams to slip up by performing poor research, not generating useful concepts or simply not putting in the work to understand their market and work as a team. These cases occur more commonly in a student design team setting, and typically lead to a team that does not move significantly through the framework. It does not learn about its target users, nor does it communicate enough as a team to either uncover disagreements or to settle them. Essentially, teams that do not follow the user-centered design process are more likely to finish on the left side of the framework. Data were collected through three semi-structured interviews using a Criterion sampling approach (Patton 2002 243). In this case we were interested in the experiences of those with the greatest impact on the early stages of the company. To meet this criterion I interviewed the primary founders of the company, Alan Brownell, Peter Taylor and Tim Freeman, over a period of two months. Collectively, these three founders held the greatest sway in influencing the direction of the company. Interviews were conducted at their current offices. Only the initiator, Alan Brownell, still remains at the company. The interview with Tim Freeman was recorded and transcribed. Of the other two interviews, one was conducted in an environment not conducive to recording, and in the other the participant preferred not to be recorded.

Quotes other than from Tim Freeman are therefore from notes taken during the interviews.

While the company still exists the interviews concerned the time from the earliest days of the company. The interviews then provide a retrospective account of the Powder Net story.

Analysis of the interviews was conducted by me with a second researcher. 21

With an understanding of the context of the case study I will now tell the Powder Net story as pieced together from the information provided by the founders together with data from secondary sources such as press coverage. As far as possible I have tried to tell the story in the interviewees own words.

The Powder Net story The Powder Net story The Powder Net story The Powder Net story

The beginning

The beginning

The beginning The beginning

The vision for powder-sized wireless sensors was conceived around the mid-90s. Sensor But creating tiny sensors and keeping them powered is no small challenge. Communication is a large drain on the power. To communicate the tiny sensors must regularly send and receive signals from their peers. Optical communications seemed an early promising route as they are low power. But that would take time, and one of the most difficult parts, the communication algorithms would also need to be tested. So Alan's research lab put together a small wireless radio board that would allow the team to begin prototyping the communications piece.

The original board was created by a graduate student and it evolved through several

iterations. An operating system was developed by a computer science team. The board was built in a modular fashion making it great for prototyping and relatively easy to get started with. Because of the interest (and funding available) for defense applications, other research teams began working in the area and it wasn't long before requests were coming in from other researchers to buy the little radio boards. Tim explains, "Alan was looking at network communications and because the optical stuff was so much harder he set some guys to put together a little radio board that he could use to start testing some communication algorithms, because he knew that would be a hard piece. So they built this little radio board and they went through a few generations of this radio board…He started selling that vision and got a lot of excitement in the defense community which basically then goes out to all of the other universities because that's where they find their funding, and they all come up with new ideas and so he spawned this whole movement of Professors doing research around wireless mesh communications."

"And Alan was on the technical advisory board of another company and he wanted someone to be building these boards for all these other researchers around the world. He encouraged them to do it and they started selling these little boards at a hundred bucks a pop and they pretty quickly turned that into a million or multi-million dollar a year business selling these little boards that a grad student had designed."

Forming the team Forming the team Forming the team Forming the team At this stage, there was research work in the area and a business selling the radio boards but Alan was regularly encouraged to start something to help make his vision of smart dust happen. He recruited a team of people he knew well, whom he could trust, and several key graduate students to continue developing the technology.

Tim Freeman became involved when Alan asked him to help out two consultants who were being paid to write a business plan for the company. Although Tim was skeptical at first, after being "burned" in a previous technology venture, the experience of selling the benefits of the technology to help compose a business plan convinced him to join the team. hadn't thought about it enough, or couldn't find anything where the story was defensible, and so they punt and don't make a commitment around a specific application. So all this seemed a little bit fuzzy to me… I didn't necessarily buy that that idea would turn into a business."

Peter saw his role as "kind of the balance point in the middle," of Alan and Tim.

In the early stages of the company, they were trying to figure out if they should bootstrap, making enough money through operations to fund continued development, or seek venture funding. Peter and Tim explained, Peter: "We pursued a number of small government contracts, whatever we could get. The survival of the company was foremost. So we got a few hundred k here and there that kept us going."

Tim: "And we probably could have kept going on that path and succeeded, but everybody in the company wanted it to be a big commercial success -which was inconsistent with bootstrapping and doing research -to actually deliver things that would be scalable in the real world. And we didn't have a way to do that with the research programs we were being funded on."

Early in their development Powder Net had lost one of their key engineers -the graduate student whose PhD had helped develop the original technology. The parting was difficult as the company was still getting off the ground. But the company successfully secured $7M in funding from several venture capitalists allowing them to pursue their vision.

Finding their f Finding their f Finding their f Finding their feet eet eet eet

The team was still trying to find the 'defensible story' and a target market that was right for their technology.

Peter: "In some senses we had three different visions, defense, industrial automation and transportation. I mean there was some common wisdom -it was true that this was a brilliant technology -but no one could figure out what to do with it. We agreed on most things, but it was a big, messy process.

At the beginning we had a number of projects we started with potential clients where they would tell us what they wanted and we'd try to figure out if we could do it, but we didn't ever really deliver on them for whatever reason. There were a number of false starts. And I think that's good for the company."

The team grappled with the dual challenge of finding a suitable market, and figuring out what the key value proposition of their technology could be. Tim explained, "I don't know if the decision ever really got made it was just a sort of evolution over time and very early days it was sort of a look at all these applications we're going to support all these applications…And then eventually it evolved … think about it like we're going to support quasi-static large scale wireless networks versus totally dynamic moving around things.

We're going to focus on battery operating networks, that sort of thing. So not markets specifically but technology and then it evolved … and we would actually start talking to customers in each of the markets and try to get a sense of who was interested and trying to get people interested and we would start getting … interest in certain areas and then we would elevate those things in our plan and eventually we'd end up with three different segments and we ended up breaking those segments down quite a bit more from that and end up focusing on specific applications…Ultimately what we settled on was industrial automation, building automation and defense and security."

The challenge of finding a suitable target market was confounded by the difficulty of deciding the level of abstraction of the product; as Alan put it, "where in the food chain we wanted to be." The company could choose to sell the hardware itself leaving others to write software for it; they could sell the hardware running their own software; they could be at the data management and aggregation level; or selling a whole integrated solution. With so much uncertainty in the needs of clients, and potential target markets the decision was difficult.

At the same time, despite the stated value of having tiny, powder-sized, sensors, it became clear that potential clients' concerns were not with size. Alan: "For real applications what people needed were systems with high-reliability and a long lifetime." While this realization was gradual it wasn't until a 2005 survey of barriers to adoption of wireless networking technologies by a business intelligence firm that they were able to point to some data that showed this. Results from the survey are shown in Figure 6.5.

Figure 6.5 Survey of barriers to adoption for wireless networking technologies (Hatler and Chi,

2005)

The survey pointed to reliability, consistent standards, ease of use, low power consumption (tied to a longer lifetime), and reduced development cycles all as greater concerns than the size of the sensor nodes.

This shift from an emphasis on small took time:

Peter: "After a while we realized that once you've got this small (sugar cube)

going to this small (sugar grain) is not so important. It was gradual, we were all bought into it to different extents."

This clash was partly borne out of the differences in needs between research and real-world applications. Tim and Alan reflected, Tim: "I think one of the challenges is in the academic community you're in the business of getting people excited, and in the business community you're in the business of meeting expectations. And so I think there's inherently, sometimes, with revolutionary technologies like we had, it can be tough to translate one into the other."

Alan: "people in academia can easily fool themselves into solving problems that people don't have."

The team was also developing a deep understanding of the different technological trade-offs that had to be made in a product and how that affected the value they could provide. For example, the team knew that sensor lifetime was a concern of potential clients but powering the sensors was still a bottleneck. Wireless sensors were typically powered by one of three batteries: AA; C cell; or D cell. So the lifetimes of the sensors increase in discrete sizes ~ three years, five years, or ten years. When potential clients expressed a need for the sensors to last, this also really confirmed that size wasn't a key issue. In other words, with the power constraints of battery sizes there wasn't going to be truly powder-sized sensors as conceived in the original vision any time soon.

Peter: "Longevity is all about size. We decided to optimize for power. Some of the early attempts tried disc batteries, but it wasn't long before people thought, if you can put a couple of AAs in there why not? It's not that much different."

But Powder Net did have a head start on long life sensors.

Alan: "By trying to make the sensors really small we had to make them very low power. We created a number of low power firsts such as the lowest power radio. In this way, our drive to make the sensors small meant we also had an Alan to take the CTO position. Two years later they hired a VP of Sales who, according to Tim, "was a very strong character in the company. She got us very focused on a specific customer and that basically drove the rest of the story for the next two and a half years."

The client, a large technology and engineering firm, believed in the technology and the team and pulled them along to the major inaugural product launch in 2008.

Alan: "They pretty much told us what they needed, and we worked to make it happen. They didn't care about battery size and cost because they were selling a $1000 product and the battery costs just a fraction of that."

Tim saw that the value they settled on, making information about industrial and building automation available which wasn't previously accessible was a defensible story that business development could go out and sell. Figure 6.6.

Powder Net's path follows the Back Roads path identified in the student design teams. Its path can be understood from the comments of the three founders at the numbered positions on the diagram. Peter: "At first it was all about size -the original concept was these dust-sized sensors, so small they could float in the wind." Tim: "These things are going to be free, and we're going to dump them out of the back of an airplane and sprinkle them across the world, and there'll be ubiquitous information. It is a really compelling vision." of their technology. Later, with a greater understanding of the needs of their clients and possible applications the team was largely able to resolve the differences in perspective and the team got on the same page about their product.

The Powder Net story also mirrors several key framing issues experienced by the student design teams. I will discuss these in turn below.

Attachment to the initial product visio Attachment to the initial product visio Attachment to the initial product visio Attachment to the initial product vision n n n Perhaps the defining characteristic of the Powder Net story is its birth from the original, exciting research vision of tiny, cheap, ubiquitous wireless sensors. The company's struggle to move away from this vision as the value proposition and reframe their product with their client's needs is strongly influenced by this beginning. As we learned, the shift was gradual. On the one hand the powerful metaphor originally helped the team aggregate and comprehend all the data, vision, and ideas that were the foundation of Powder Net's product.

Powder was always a great selling point, story and vision for the technology. Powder evokes small, cheap and ubiquitous.

Yet the metaphor also raised tensions that were difficult to avoid. The struggle was because of the excitement and expectation powder provided. Peter explained, "We'd set these expectations and create the vision and then people actually see it and they're like 'Hmmm, that's pretty big. It's like a pager. That's like a dirt clod, it's not the size of a piece of powder."

The excitement and press the metaphor helped draw also made it more difficult to explain benefits other than the small size of the sensors.

Alan, like Tim, saw how the difficulty also stemmed from the different needs of academia and business, "the easiest way to move technology from the university is to find a killer app. But if the story is different -less dramatic -it is much harder to do that." With the company name tied to the product reframing the value is made that much more difficult.

Conclusion Conclusion Conclusion Conclusion

In sum, the Powder Net case illustrates the greater understanding provided by the Design Path framework and a joint consideration of the framing of the design situation and shared understanding of the design team. The framework can clearly be seen to apply to this industry case.

All of these issues -a strong initial vision, a powerful metaphor, the company name -make it more difficult to adopt an open attitude of learning about the needs of your customers.

Instead, the temptation is to confirm the initial product vision. While in a student design setting it may only lead to a bad grade, in industry an attitude of confirming rather than learning will lead to failure. Each of these issues were also issues that we saw student design teams grapple with: attachment to an initial product vision; different atmospheres of communication allowing productive, or unproductive conflict; a powerful metaphor as a framing tool with both benefits and disadvantages; and the seemingly innocuous tie to a team name that is made more consequential when it is a company name.

I will close with the words of Tim describing the difficulties of evaluating the design path without the benefit of hindsight and the benefit of diverse perspectives to keep challenging the NPD team,

To look at it realistically we never hit on a market that went through the roof which is what we were all hoping for and expecting. And so were we on the right path? Well the only way we would have said yes is if we were going through the roof. And we weren't. We're on the best path I think we found.

We were always on the path that the company decided on for whatever reason. And did that path bring us into rapid growth? No. so maybe that means we're inherently not on the right path or maybe it means we're on the best path. It's hard to say but we were never sort of dumb and happy thinking we were on the right path. There was always tension and there was always disagreement. We were always trying to get onto a better path. That's the optimistic way to look at it.

Introduc Introduc Introduc Introduction tion tion tion

Framing helps us make sense of a situation. In this chapter I present two studies aimed at understanding the role of an important framing tool: metaphor. Metaphor is often seen solely as the domain of artists, writers and speechmakers yet I want to illustrate in this chapter two important ways metaphor influences design and New Product Development (NPD).

Metaphor plays at least two important roles in design. First, and least appreciated of the two, metaphor plays an important role in our understanding of design itself and many of design's most important concepts. This is because metaphors excel at helping us understand unfamiliar or abstract concepts by comparing them to things with which we are more familiar, and as such are helpful in understanding and communicating about the entire process. Second, metaphor can be used as an effective design tool for framing a design situation in a new way to pave the way for novel insights and as such is valuable to a design team working on a particular solution.

In this chapter then, I will first review prior research on metaphor use in design before presenting a study of the metaphors in use in widely used design textbooks . I then discuss some of the implications of these metaphors and compare them with the actual NPD experience. I also provide a short analysis of the Design Path metaphor introduced in the previous chapter. I then present a study of metaphor use within the design process from graduate NPD projects. In particular, I compare the use of metaphor's close sister, analogy, and how they are employed differently in the design process.

Background Background Background Background

Metaphors have been studied and are regularly, though not always consciously, employed in several areas of design.

Software and interface desig Software and interface desig Software and interface desig Software and interface design n n n Metaphors find their most active application in the area of user interface design because designers need to make the abstract, intangible and seemingly magical operations of computing understandable to users. Metaphors are common in programming precisely because of its abstract nature.

Because metaphor use is so pervasive in computing it is tempting to employ it whenever possible. However, as several authors have noted (Cooper 1995;Lawler 1999;Mohnkern 1997), while metaphors speed up our initial understanding of a new piece of software by referring to commonly understood physical actions, for example, cut and paste, they also hinder our ability to go further and use the full power of computing available to us. Cooper (1995) gives as an example, the failed suites of software that created a virtual mall to recreate the shopping experience; as one quickly finds out, traversing the distance between shops in a software program quickly becomes tedious when it is possible to head there with one click of a mouse.

Metaphors for communication Metaphors for communication Metaphors for communication Metaphors for communication

Metaphors are also commonplace within the design process as a design team works on a challenge and strives to develop a shared vision of what it is designing. Stubblefield (1998) discusses the development of a Design for Machinability Advisor. The software program was originally envisaged as a "spelling checker" for machinability problems. The spellchecker metaphor persisted as the design progressed, enabling both effective communication and discussion about the features of the software and between different design groups. The shared metaphor provided a common understanding of the design via a commonly understood technology -a spellchecker. As the design progressed, however, it became clear that the spellchecker metaphor was not entirely appropriate for what the team intended to do. For example, a spellchecker finds mistakes in a document, yet the team realized the advisor was far more useful if it would also offer advice as the design was being created. The spellchecker metaphor placed a harmful emphasis on finding problems rather than preventing them. Eventually the team moved forward by employing a dual approach -using both spellchecker and advisor metaphors. Metaphors, then, also have a social context in which they operate and can both support and hinder communication and cooperation within design teams.

Metaphors are also touted as providing a strong common goal for design teams as they struggle to overcome a technical challenge or develop a new product. Nonaka (1991) illustrates how the goal of making a photo copier like a beer can -cheap to produce, lightweight and reliable -pushed the design team to develop a new type of copier with the fragile parts in the replaceable print cartridges. The Beer Can Copier metaphor provided the team with a shared goal and a common ground for communication. In 1981, Apple Computer

Inc., created advertisements that employed the metaphor for a new Apple computer as a "bicycle for the mind" (Hertzfeld 1981 (Quittner 2002). Lundholm (2003) provides several examples including the evocative animal qualities in the Jaguar brand, and the Black and Decker electric sander that employed the metaphor of a computer mouse, a "form that is nonthreatening, fun, and a bit lovable."

Designers and marketers also evoke feeling or deeper meaning through a metaphor. For example, the Motorola Pebl phone (Motorola 2008), builds off a pebble metaphor with its "Iconic oval-shaped design with elegant silver finish…" The pebble metaphor evokes an accessory of natural beauty with a shape, weight and texture that feels good in the hand.

Framing a problem Framing a problem Framing a problem Framing a problem As I shall return to later in this chapter it has also been suggested that metaphor can play a crucial role in the framing of the design situation by a design team (Schön 1979 and1983). Schön (1979) discusses an urban planning problem where the framing of a slum as either a 'blighted area' that needs to be cured, or as a 'natural community' that should be preserved, significantly changes the design situation itself. In another example in the same paper, Schön discusses a design team trying to improve the design of a paintbrush. At first, the team considers the paintbrush as a form of 'spreader' for the paint. A different perspective on the problem was provided by a team member who saw that the space in between the bristles of the brush held the paint and the paintbrush could also be seen as a pump for the paint.

When the team reframed its problem in this way the metaphor highlighted new solution directions. Metaphor use in this way is supported by Casakin (2006) who found that architecture students found it easier to use metaphors in the early, problem framing, stages of design than later.

In another example, shown in Figure 7. While these are individual cases Madsen (1989 and Cradle to Cradle, emphasizes a birth-death-birth model of products to avoid the cradle-tograve mentality. The rebirth notion encourages elimination of waste as a recognition that systems will be 'born again'. The authors also divide the world into two metabolisms -the biological metabolism of the cycles of nature, and the technical metabolism of the cycles of industry. Although, strictly speaking, there are no metabolisms, use of these two metabolisms as a metaphor focuses attention on both the biological components of products and how they will eventually be returned to the earth, and the technical components, and how they can be reused in future products. They also evoke a Cherry Tree metaphor for design to highlight the possibility of producing waste that nourishes. Each of these Boroditsky (2000) to determine the effects of our conceptual metaphors for time. Although not universal, much of the world holds a common metaphor for time; we conceptualize time in terms of space. This is why phrases such as, "We're getting closer to the hand-off," and "The launch date is nearly upon us," make perfect sense to us. We use a physical source domain, in this case "space", to talk about an abstract target domain, in this case "time". In Boroditsky's study, whether participants said the meeting was on Monday or

Friday depended upon whether they were primed to think about moving toward an object, or pulling an object towards them. This is because we have two common perspectives on time:

an ego-moving perspective, where we are metaphorically moving through a stationary landscape of time ("We're getting closer to the hand-off"); and a time-moving perspective,

where we remain stationary and events move past us ("The launch date is nearly upon us").

When primed with the ego-moving perspective participants were more likely to say the meeting was on Friday, and when primed with the time moving perspective they were more likely to reply Monday.

Metaphor use such as this is pervasive whenever we talk, or think, about abstract concepts.

As Lakoff and Johnson (1980 3) argue, "…metaphor is pervasive in everyday life, not just in language but in thought and action. Our ordinary conceptual system, in terms of which we both think and act, is fundamentally metaphorical in nature." The target domain is the domain we are trying to understand. The source domain is typically taken from our physical experience in the world, for example, we move about in space, we see, we appreciate size, we feel the weight of burdens and so on. (Kelley and Littman 2001). Gabora (2002) also observed that many common expressions for creativity derive from expressions relating to light, for example: she had a flash of inspiration; he's a bright spark; I saw the light; we had an illuminating discussion; and of course, the ubiquitous light bulb to symbolize an idea. Lakoff and Johnson (1999) argue that the metaphors we hold for abstract concepts provide us a richer way to understand them, allowing us to reason about them and make inferences using them. For instance, the common metaphor Time Is A Resource in effect allows us to make good use of it or even waste it. Without it time would not seem like something we could waste, and maybe we wouldn't feel guilty for that lazy morning in bed. Gentner and Gentner (1983) added weight to this hypothesis studying mental models for electricity and providing evidence that our mental models of a domain, for example understanding electricity as flowing water or a moving crowd, affect the inferences we make in that domain. Identifying the metaphors in use to understand a domain then is the first step in understanding how we reason about that domain. As yet, this analysis has not been performed for the design process itself.

Source Target

Metaphors and design paradigms Metaphors and design paradigms Metaphors and design paradigms Metaphors and design paradigms

Only a small number of researchers have explicitly made the link between metaphors and our understanding of the design process. In the cases I am aware of the link is through identifying the role metaphor plays in our most broad understanding of what design is. For example, Dorst (1997) compares two dominant 'paradigms' for design. The first is driven by the metaphors Design Is Search and Design Is Problem-Solving. These metaphors originate largely from the Design Science movement championed by Herbert Simon (e.g., Simon 1969 and. It is insightful to look at the example problems Simon discusses in the chapters, Thinking and Learning, and the Science of Design in The Sciences of the Artificial (Simon 1969): chess; word problems including the classic DONALD + GERALD = ROBERT; the magic square; the Himalayan Tea Ceremony puzzle; statics problems -for example, a ladder leaning against a wall; algebra; discovering general physics laws; given a sequence: Study 1: metaphors in conceptual design Study 1: metaphors in conceptual design Study 1: metaphors in conceptual design Study 1: metaphors in conceptual design Approach Approach Approach Approach

The most common means to learn about metaphors at work in a domain is to extract metaphors from natural language about that domain. Identifying these metaphors provides clues about our conceptual understanding of a domain. Despite this common approach I found no prior references that detailed a rigorous approach to metaphor identification from natural language. The closest is Michael Reddy's seminal paper on the Conduit Metaphor (1979) where he illustrates the process of collecting example phrases before identifying the metaphors at work. The Conduit Metaphor illustrates how the subtle, yet pervasive, metaphors Words Are Containers and Ideas Are Objects combine in our discourse about communication as when we say "It's hard to get that idea across to him," or "His words carry little meaning." I took a similar but more structured approach of surveying language in nine widely used English language engineering design textbooks. These textbooks were chosen based on their use by faculty in the engineering design community and to provide coverage in the United States, and Europe. The approach consisted broadly of three phases: Design textbooks are a fruitful source of study as they hold some of the greatest potential to influence design teaching and culture. The analysis was confined to chapters that dealt primarily with conceptual design, including concept generation, for two reasons. First, these chapters generally contain the highest density of discussion of the more abstract concepts in design and are thus a richer and more concentrated source of metaphors than other chapters on the design process. Second, I am interested in how the metaphors in use affect designers' capacities for creative design including problem framing and much of the creative phase of design is generally considered in this step. While creative activity can happen just as often outside of the conceptual phase, discussion of this creative activity occurs significantly less.

For example, later chapters show similar metaphors to those found in the analysis but the density of the instances within the text is much less, with more discussion of other concepts such as risk or testing. In the discussion I also draw from some widely used metaphors about design to support my conclusions. To obtain a better feel for the analysis, here is an example of a metaphor instance:

"Brainstorming is meant first of all to trigger off new ideas ideas ideas ideas, but it cannot be expected to produce ready-made solutions solutions solutions solutions because problems problems problems problems are generally too complex and too difficult to be solved by spontaneous ideas ideas ideas ideas alone." (Pahl and Beitz 1984 78) In the above phrase, the design concepts of 'ideas,' 'problems' and 'solutions,' as referred to metaphorically, are in bold. The metaphorical qualifiers to each of these concepts are highlighted in italics. In the analysis, I listed all the qualifying statements for each design concept. In the example above, "Ideas" can be triggered off, new, spontaneous and can solve problems; problems can be complex, and difficult; solutions can be produced and ready-made.

Two researchers collectively identified and coded nearly four hundred unique instances of sentences or phrases concerning design or key design concepts. A protocol was developed to enable the two researchers to reliably identify the same examples over identical sources. A test coding the same chapter from a randomly selected textbook yielded 88% agreement between the instances selected. The protocol was also used successfully by other researchers in a cross-cultural metaphor study (Hey, Linsey, et al. 2007 and.

Coding involved labeling each instance with the associated design concepts -the Target domain of any underlying metaphor (e.g. Ideas, Problems, Solutions). Once sufficient instances of each Target domain were identified, the researchers identified metaphors that provide coherence to each of the instances, for example, the separate instances of "overcome the barriers between the present situation and the goal" and "find a way to side-step the problem" can be made sense of through the metaphor Problems Are Obstacles.

Many design concepts are not abstract entities; they have a very real existence. So while we can refer to a Design Sketch As A Tool, the sketch itself is not abstract, it has a very real physical form. These tangible concepts, including sketches, matrices, decisions and such, were not included in the analysis or coding scheme as their roles are more clearly understood than the abstract concepts of design ideas, problems, solutions and such. In almost all cases each Target Domain was mapped to several different source domains depending upon the context of the statement, for example, Ideas are seen as both Food ("I need some time to digest what you said.") and Products ("This idea needs to be refined.") Several metaphors, including Ideas As Food and Ideas As Products, supported the metaphors identified previously in the literature (for example Lakoff andJohnson 1980 andKövecses 2002). Once metaphors were identified I analyzed the implications of the use of each metaphor in design.

Problem Metaphors Problem Metaphors Problem Metaphors Problem Metaphors

Problems Are Puzzles: They can be solved and resolved.

Problems Are Locations: They can be explored, be open-ended, approached, have boundaries, points of entry and we can define a problem space.

Problems Are Gaps: There can be gaps in a problem space, we can require a creative leap.

Problems Are Objects: They can be assembled, viewed from a different angle, divided, decomposed, be hard, big, well-structured or ill-structured, transformed, patterned, complex, broken down into sub-problems, refined, clarified, broken into parts, and stable.

Problems Are Formulas: They can be formulated, underdetermined, ill-defined and require an answer.

Problems Are Obstacles: They can be barriers between a present state and a goal, be side-stepped or hurdled.

Solution Metaphors Solution Metaphors Solution Metaphors Solution Metaphors

Solutions Are Living Entities: They can come to you, emerge, appear and have origins.

Solutions Are Children: They can be born and be embryonic.

Solutions Are Locations: They can be arrived at, approached, defended, attacked, in a direction, in a space, you can find a route to them.

Solutions Are Objects: They can be sought, discovered, absent, existing, overlooked, in fragments, divided into categories, integrated, found, provided by something, handed to someone, in your mind, purged from your mind, in parts, combined and manipulated.

Solutions Are Products: They can be produced, ready-made, useful, generated, rough or polished.

Solutions Are Resources: They can be yielded by a search space, meet a need, suggested by analogy, for a specific problem, of a problem, to a design problem, match a design problem, optimum.

Idea Metaphors Idea Metaphors Idea Metaphors Idea Metaphors

(The word 'Concepts' is used almost interchangeably with 'Ideas') Ideas Are Living Entities: They can emerge, come, cannot be forced, and they can be spontaneous.

Ideas Are Children: They can be embryonic or killed.

Ideas Are Explosives: They can be triggered off.

Ideas Are Liquid: They can flood and flow.

Ideas Are Locations: They can open new paths, lead to a solution, or be a range.

Ideas Are Objects: They can hit the bull's eye, be created, judged, generated, accepted, integrated into the process, scrutinized, associated, criticized, possessed, combined, hit, bounced, sorted, found, and amassed.

Ideas Are Products: They can be developed, modified, amended, changed, adapted, produced, fragile, improved, debugged, repaired, refined, useful and manifested.

Ideas Are Resources: They can be a match between a problem and a solution, and exploited.

Metaphors for design Metaphors for design Metaphors for design Metaphors for design

Overwhelmingly the most common metaphor identified for design derives from the Information Processing perspective of design (Simon 1969), that of Design Is Search.

Consider the following example phrases taken from different textbooks:

"It will prove particularly helpful in finding a first solution concept as a starting point for further variations. It must, however, be said that this approach carries the danger of causing designers to stick with known solutions instead of pursuing new paths." (Jones 1981 74) "Such an approach allows full exploration of the design space and reduces the chance of oversight in the types of solution concepts considered. It also acts as a map for those team members who are less experienced in design problem solving." (Ulrich and Eppinger 2005 120) This perspective frames the process of design itself as a problem of Search. In these examples a 'design space' is laid out in which we start at some unsatisfactory location and we wish to navigate towards a satisfactory location, a solution. Several variations of the design space metaphor were identified including Design Is Exploration, Design Is Selection (among paths in the design space) and Design Progress Is Reduction of the Search Space.

Other metaphors for design were also seemingly able to coexist with the Design Is Search metaphor. These included Design Is Decomposition and Design Is Problem-Solving. The

Design Is Decomposition metaphor takes a more physical view of the design situation where a problem can be decomposed into sub-problems or functions for which solutions can be found and a final solution can be synthesized from these 'solution fragments.' The Design Is

Problem-Solving metaphor, by contrast, is typically associated with a view of Problems Are Puzzles or Formulas for which a solution can be inside, be the key to unlock it, or be an answer. I also note that other authors (Koberg and Bagnall 1981), not in this study, have

proposed Design Is A Journey with the Designer Is A Traveller.

Design was also universally seen As A Process. The process typically contains steps, stagegates and iterates in a cycle.

Search

Design is

Universal metaphors Universal metaphors Universal metaphors Universal metaphors

While I observed that many metaphors are largely specific to an author's philosophical, and even personal, approach to design, such as Design Methods Are Maps, other metaphors appear largely universal and were shared by all authors. These include metaphors such as Ideas Are Food ("I need time to digest your ideas"), and Ideas Are Plants ("I have the seeds of an idea"). These metaphors appear largely familiar as they are reflected in common language. Compared to everyday language, however, design discourse has a more diverse range of metaphors for the same concepts, for example, Problems Are Gaps In A Solution

Space. I believe this reflects a more nuanced understanding of these concepts deriving from greater use and discussion.

Specific implications Specific implications Specific implications Specific implications

Lastly I examine some of the implications from specific metaphors identified in the study, as well as limitations of the study.

Ideas Are Tangible, Physical Objects Ideas Are Tangible, Physical Objects Ideas Are Tangible, Physical Objects Ideas Are Tangible, Physical Objects

Many metaphors for ideas refer to Ideas As Tangible, Physical Objects. Physical Objects have certain common affordances such as occupying a location, being possessions, originating somewhere, being modifiable and so on. This metaphor is reinforced by our experience of 'capturing' an idea on a Post-It or with a sketch. An interesting conflict, however, is that the nature of ideas is often very different from the nature of physical objects. I believe this mismatch is the cause of many difficulties and conflicts during the design process.

To see that ideas don't always behave as physical objects we need only consider that when you give an idea to someone else you still 'have' it. Ideas do not add up in the same way as objects. Michael Reddy's Conduit Metaphor discusses how words, in effect, act as containers for ideas. Following this metaphor when we capture an idea in writing, on a Post-It say, the idea is contained within those words; it is captured. Yet design team members can, and regularly do, interpret those words in different ways than intended. After handing someone an idea it can be dangerous to assume that they then also have the same idea. We construct an idea from the words; it is not transferred in the words. It can therefore be very misleading to treat Ideas As Tangible, Physical Objects, as in many ways they do not behave like them at all. The notion that Ideas Are Tangible, Physical Objects also underlies the system of Intellectual Property. If Ideas Are Objects then they can be possessed, protected, and even stolen.

Ideas Are Children Ideas Are Children Ideas Are Children Ideas Are Children

Ideas are also conceptualized As Living Entities, in some cases Children, as when we talk about an idea being born, growing, being nurtured or being your brainchild. Inventors are often known to refer to their invention as their 'baby.' No wonder the threat of an idea being stolen is a serious one, as when a team member attacks your idea. This common metaphor may also explain the tendency for designers to fixate on a single or small number of initial designs (Jansson and Smith 1991). The Ideas are Children metaphor could also be viewed as a specialized form of Ideas are Living Entities, which can evolve, grow, be nurtured, be killed, be dangerous, etc.

Finding solutions Finding solutions Finding solutions Finding solutions

Within the Design Is Search paradigm, Solutions are typically seen as both Objects and

Locations. It is these metaphors that enable us to find, discover and search for solutions.

These metaphors hide the assumptions that solutions already exist and simply need to be found; with enough searching in the right place you will find them. An alternative view is "The good idea is not discovered or undiscovered; it comes, it happens," (Pahl and Beitz 1984 75). Yet, it is rarely the case that solutions are found ready-made. These metaphors lead us away from the more collaborative notions that solutions can be constructed and evolve as you build an understanding of the design situation.

Incoherent metaphors Incoherent metaphors Incoherent metaphors Incoherent metaphors

The analysis also highlights the remarkable range of conceptualizations we hold for such a universal design concept as a Problem. When Problems can be seen as Puzzles, Formulas, Gaps, Barriers, Objects, and Locations it is not surprising there is continued debate and disagreement as to the nature of design problems. The analysis shows that our views of design problems stem not only from the circumstances of the design situation but also the overall philosophy of design held by the designer. When these philosophies diverge, debate

can be difficult at a more specific level as we find ourselves literally talking about different things.

Creative design Creative design Creative design Creative design I observed that references to creative design typically took several forms. For example, Ideas appear involuntarily or spontaneously, they are triggered or they emerge uncalled for. Our metaphorical understanding of this process sees the Ideas themselves as out of our control and moving of their own volition. Creative inspiration employs the metaphor Knowing Is

Seeing with Ideas Are Light Sources (Gabora 2002). In this way, Ideas are the illumination, the creative spark or the flash that light up a portion of the design space or illuminate a solution directly. Finally, the metaphor Problems Are Gaps or Obstacles leads understandably to the common notion of the 'creative leap." In the creative leap we move locations, and therefore states, via the common metaphor States Are Locations (Lakoff and Johnson 1999).

The 'out of our control' nature of metaphors for creative ideas, together with the spontaneity implied takes the emphasis off the hard work that is needed for creative design. Consider

Edison's mantra "Genius is 1% inspiration and 99% perspiration," or the advice of Bernie Roth at Stanford University that "Hard work is the best creativity method I know" (Roth 2007 Each of these facets so far seem to reasonably represent the NPD process as experienced by design teams studied for this thesis. Indeed, one of the founders of Powder Net in the previous chapter made heavy use of a design path as a metaphor for understanding their experience:

And so were we on the right path?…We're on the best path I think we found.

We were on the path that the company decided on for whatever reason and did that path bring us into rapid growth? No. so maybe that means we're inherently not on the right path or maybe it means we're on the best path.

It's hard to say but we were never sort of dumb and happy thinking we were on the right path. There was always tension and there was always disagreement. We were always trying to get onto a better path.

Yet, the design path metaphor also has the power to mislead. A journey along a path is primarily linear in that you cannot simply arrive at the other end without traveling through the middle. This facet does not easily account for creative leaps that may immediately lead to an alternative framing. Although the design process as experienced is inherently linear -even with iteration it remains one decision after another. The design path metaphor also hides any reference to users of a product or service including only the design team in the typical schema. Finally, the implied destination of a design path leads to the same flaws of the Design Is Search metaphor, that of an assumed ideal solution existing independently of the design team.

Design paths bear a close resemblance to a journey, a metaphor elaborated upon in depth by some design thinkers (Koberg and Bagnall 1981). The metaphor appears to resonate with a design team's experience. In addition, the metaphor points the way to the possibility of new tools and understanding including learning about possible destinations, common design paths (the beaten track), a clear acknowledgement of the possible different directions of team members, ways to locate yourselves and the possibility of means of guidance including a map to plan and chart progress.

While the metaphor holds promise it is important to reiterate that a metaphor both highlights and hides and never accurately represents reality. No metaphor is perfect and this is no exception, but a metaphor may still be useful.

Study 1: c Study 1: c Study 1: c Study 1: conclusion onclusion onclusion onclusion In this study I highlighted a less known, but important, facet of metaphor use in designthat of understanding design itself. I found important differences between typical metaphors espoused in design textbooks used to frame the design process and experience in actual NPD projects. I also proposed a hierarchical model for metaphors for design whereby the dominant design metaphor influences the choice of metaphor for the core concepts of ideas, problems and solutions. Finally, I presented some specific implications as well as discussing the useful aspects of the Design Path metaphor proposed in the previous chapter.

The following study looks within the design process to compare the use of analogy and metaphor and determine how each affects the framing process.

Definitions for de Definitions for de Definitions for de Definitions for design sign sign sign

Both metaphor and analogy involve comparing one situation with another. To help distinguish the two Gentner and Markman (1997) make a distinction between relational and structural, or appearance, similarity. For example, a job may have relational similarity with a prison but little similarity in appearance, whereas a zebra may have appearance similarity with prison bars, but no relational similarity. They propose that analogies typically require strong relational similarity but metaphors can span the spectrum of relational similarity to appearance similarity. The distinction is shown in a modified version of Gentner and

Markman's diagram in Figure 7.4. Steve Jobs' inspiration for the iMac computer as a sunflower is drawn more from appearance similarity then relational similarity. It is therefore a metaphor rather than an analogy. In contrast James Dyson's connection between the sucking of a vacuum and cyclonic separation is a relational, causal, similarity primarily (Dyson 1997). In this case then Dyson drew an analogy between the two, rather than using one as a metaphor for the other. The emphasis on relational similarity for analogy primarily maps the causal structure between the source product or system in one domain to the target design problem being solved. The causal structure includes a device's functional solutions, geometry or component configuration.

Both metaphors and similes can be visual as well as expressed in language. Typically metaphors are made as a direct comparison between two objects as when we say 'the flood of email'. A simile is a metaphor where the comparison has been made explicit, as in saying 'the amount of email is like a flood'. For example, seeing a cafeteria as an oasis not only helps understand the situation (as a descriptive metaphor) but may also lead to new solution directions as a prescriptive metaphor. The designer might consider how the feeling of an oasis could be better supported by the cafeteria, perhaps by providing places for rest or better closing it off from the outside world. In another example, a shower might be seen as a reset for the person taking the shower. They wash away the rest of the day and start renewed once they emerge. The metaphor, Shower Is A Reset, can be used to generate other solutions that could support people's feeling of starting anew even to the point of activating the shower with a button.

Metaphors are more effective than analogies at framing the early stages of a user-centered design process because they deal more effectively with the intangibles, and abstract nature of people's attitudes and needs. Metaphors are commonly used to map users' understanding, activities and reactions to a product. They help make sense of customer needs or physical attributes from the source of inspiration. Metaphors' exceptional communication ability provides meaning to a design situation; a cafeteria when seen as an oasis for its visitors becomes a different place entirely.

During concept generation, it is widely recognized that designers find it hard to ignore obvious constraints on their concepts before they have been fully developed. Various techniques such as brainstorming (Osborn 1953) encourage designers to defer judgment to allow ideas a chance to develop and be built upon before they are 'shot down. ' Adams (1986) proposes the concept of conceptual blocks and various methods to negotiate them. Several metaphors have also been proposed as a means of reducing the impact of obvious constraints on designers during concept generation. Altshuller (1999) proposes the metaphor of a magic wand to encourage problem-solvers to free their imaginations and worry about the constraints afterwards. Stanford University's John Arnold proposed designing on the planet Arktur IV as a metaphor to help problem-solvers leave their earthly constraints behind.

Each of these metaphors helps designers avoid early judgment by invoking the ideas of magic and other universes. Indeed, these metaphors are sometimes not far off reality as Arthur C.

Clarke observed "Any sufficiently advanced technology is indistinguishable from magic,"

(1962).

Analogy use in the design process Analogy use in the design process Analogy use in the design process Analogy use in the design process

In contrast to metaphors, prior studies most commonly link analogy with the concept generation or ideation phase of design to find solutions to the design problem rather than to frame or assist in understanding it. Analogies to nature and previous designs are common.

For example, a team with the design problem of creating a device to fold laundry may make direct analogies to other types of folding devices such as paper folding or metal folding.

Likewise, more distant analogies may be made to dousing a sail, rolling a cigarette, or collapsing a structure. Consistent with our distinction between analogy and metaphor, these examples each map causal structure between the target concept and the sources. Analogies also support concept selection. When designers are evaluating a set of concepts, they typically reference a design they have seen before in their evaluation. Designers thus use analogies to predict the performance of the design concept.

Another type of analogy employed in design is meta-analogy. Meta-analogies are formed from sets of individual analogies. A good example is the inventive principles employed in the TRIZ methodology (Altshuller 1999). These principles are high-level abstractions derived from many examples of individual analogies taken from innovative patents. For example, the principle Nested Doll, storing one thing inside another like a Russian doll, is employed in many different domains wherever a thing needs to be large at one time and small at another.

The sets of individual solutions such as telescopes, cables, stacking measuring cups, and extendable ladders are combined and abstracted to form the meta-analogy Nested Doll that can be applied more widely. A closely related phenomenon is scheme-driven analogizing, which is the application of abstract experiential knowledge to a design problem (Ball et al. 2004).

Approach

Approach Approach Approach Casakin (2006) observed that architecture students found it easier to employ metaphors as a design tool in the early stages of design when framing and defining the situation than in the later stages. Here Casakin's observations are extended to compare the use of both analogy and metaphor at different stages of the design process. The research team was motivated by the hypothesis that metaphors are used more frequently during the early, problem framing, stages of the design process and analogies are used later in the concept generation phase.

How does the actual use of metaphor and analogy play out in design?

12 interviews were conducted with multidisciplinary NPD teams from the graduate course at the University of California, Berkeley. Eleven interviews were performed in the final two weeks of the project and one was performed after the final tradeshow. Interviews were conducted with the full team present when possible, and the teams were asked to tell the story of their project from beginning to end explaining the key points as they saw them along the way. Interviews were recorded, transcribed and coded for discussion of relevant product metaphors and use of analogy.

For comparison to the metaphor use data, use of metaphor and analogy was coded from a prior study where design teams were asked to use a particular group idea generation technique and then spend forty minutes generating solutions to a design problem (Linsey et al., 2005). Again 12 teams were analyzed. All the group idea generation techniques evaluated for the study required teams to use only written communication. This study was a 3 X 2 factorial design. The first factor controlled the representation teams used for communication (words only, sketches only, or a combination). The second factor controlled how team members exchanged ideas, either all the ideas were posted on the wall or each team member had a sub-set of the ideas and they rotationally exchanged them. Teams consisted of five senior mechanical engineers. The experiment asked the teams to design a device to shell peanuts.

The analogy coding was based on clear references to other designs, such as "analogy to potato peeler" or "this is like a grill". This approach underestimates the actual number of analogies used by the design teams. Designers frequently use analogies without making explicit references and frequently without realizing the source of their idea (Linsey, Laux, Clauss, et al. 2007;Schunn and Dunbar 1996). In addition, the coding can not explicitly evaluate if the analogy was being used as an explanation tool or if the idea had been developed based on the analogy. A common use of analogy is to explain an idea rather than as an original source of inspiration (Casakin 2006). However, from observations of the coding process, it appeared clear that many analogies were being used for idea generation, as opposed to just explanation.

Conclusions Conclusions Conclusions Conclusions

In this chapter I presented two studies investigating different aspects of metaphor as a framing tool: for our understanding of the design process itself; and for how it finds use within design projects. The studies showed that metaphors in common use for design and its core concepts have an important effect on how we frame the design process itself, for example, whether it's a problem of search or one of argumentation. This, in turn, affects how we think about the core design concepts. We also saw that, when compared with the use of analogy in the design process, metaphor was more commonly used in the early stages of design projects to frame the design challenge, whereas analogy was more common for concept generation.

Designers must keep an open mind about what users need.

A senior human factors specialist at IDEO commented on one of the unexpected benefits of role playing as a design exercise that "we were all recognizing our otherness -none of us were the target market," (Elliott 2008 Design for people not products Design for people not products Design for people not products Design for people not products

With the decades of development dedicated to improving the automobile it can be easy to focus on the artifact as a goal in itself, forgetting that an automobile exists to serve the needs of its users, be they commuters, taxi-drivers, soccer mums or racing drivers. The same can happen on a smaller scale; it is easy to set out with a goal to make a better iron rather than to help those who do the ironing. Creating a better iron may improve the experience of those who iron, but it will rarely lead to a category changing product. Designing for the people who use it however, rather than the product, has the potential to lead to entirely new discoveries and unmet higher level needs.

The strongest teams explicitly focused on designing for people without a preconception of the product they would be making. While the Healthy Noodle team set boundaries to its innovation through the initial noodle focus, the team did extensive user research getting to know many individual users and their attitudes to ramen noodles. The development process was explicitly oriented to the people without presuming the form an eventual offering would take. Starting with strong preconceptions about the eventual form of a product makes it harder to listen, harder to value what you hear, and ask the right questions. Teams can help purge their preconceptions through early concept brainstorms, discussion about the target market, research questions to ask and avoiding tying expectations to a product. knowledge with regards to user research. In some senses, teams operate with a transactive memory. Transactive memory is the process by which groups store and remember information (see Wegner et al. 1985 andWegner 1987). Design teams excel at gathering information but not everyone has access to all of it. In particular, when design team members perform research with participants they learn different things. As I presented in

Chapter 06, when teams learn from research participants their perceptions of the issues and the problems and needs at hand diverge from those of their team members. Team members associate best with the participants they learned from (as one team member interviewing parents put it, "you take on that parent's personality. So suddenly you're arguing for something because you heard four parents say it but you have no idea how representative those parents tare") and they also learn more than they can tell (this is similar to the notion of tacit knowledge where we know more than we can say, see Polanyi (1966)). Hence even when they present their research findings they cannot share everything they experienced that may turn out to be pertinent.

Thus this theme is about reducing the differences in what has been learned by each team member, particularly with respect to user research, but this also applies to other design activities. Sharing research data richly helps bring everyone on the same page regarding what has been learned. This both helps align team members with each other and with their users' needs. Melican (2000) performed a study on the use of user research data by design teams where he first categorized research data formats along the two dimensions of the analytic perspective (conceptual to procedural) and the degree of abstraction (abstract to raw). For example, conceptual understanding of mountain bikers' attitudes to racing might be best approached through interviews, whereas procedural understanding of the preparation process for a race may more appropriately be observed. A direct quote from a user would be on the raw end of the spectrum, whereas a summarized theme such as "mountain bikers value competition"

would be more abstract. An important finding from his study was that raw research data were "clearly and overwhelmingly favored over the abstracted," -75% of references were to raw data, with only 25% to abstract data. Raw research data was also 50% more productive (his metric) for the teams as they designed. Even more pertinent to this design principle however is the finding that, "every instance in which an evocation of user research data is directly associated with a team's framing of the design problem or reflecting on the problem-solving value of an experimental move, involves the data classified on the raw end of the degree-of-abstraction spectrum." (Melican 2000 131-132) In particular where framing is concerned then, sharing richly, using raw data where possible, assists teams in productive framing.

I'll now discuss three design principles that support the theme of sharing richly.

Use rich media Use rich media Use rich media Use rich media Teams that shared their research data using rich media including stories, transcripts, photos and video received the dual benefits of both framing the problem in line with the needs of users and developing a shared understanding among the team. A common error NPD teams make is attempting to shortcut the data sharing phase by summarizing findings and paraphrasing the words and insights from their participants. In doing so important contextual information picked up by the researcher in the field is not transferred to the team. Sleeswijk et al. (2007) recommend that tools to communicate market information to designers should enhance empathy, provide inspiration, and support engagement. Wright and McCarthy (2008) also provide a useful collection of design tools employed in the field of Human Computer Interaction to enhance empathy with users, in particular emphasizing the role of rich dialog and narrative.

There is an inherent conflict between the amount of information team members can convey and the length of time it takes to share it. After all, one of the benefits of working in a team is that not everyone has to learn everything. A corollary perhaps is that we can expect that an advantage of teams who have repeatedly worked together is an increased trust in the opinions team members express without having to take the time to return to the raw user data. Rich media however, goes some way to resolving that conflict. A video provides enormous amounts of detail that would be impossible to convey otherwise in a short time (see Ylirisku and Buur (2006) for a thorough treatment of the use of video in user-centered design. They employ the metaphors of Video As Designer Clay and Video As Social Glue for the design team. Also, see Gaver (2007) and Raijmakers et al. (2006)). Likewise, sharing a participant's story word for word is often a powerful encapsulation of a more general need the person experiences and thus, an efficient means of transferring information.

Design research is a team Design research is a team Design research is a team Design research is a team sport sport sport sport There are many reasons why design research is more effectively carried out in pairs or more.

Design consultancies often require that clients participate in user research in order to help with buy-in to the research findings. In other words, there is an issue of trust involved where it is easier to trust and act upon your own experience than second-hand experience. When Manage the data deluge with frameworks Manage the data deluge with frameworks Manage the data deluge with frameworks Manage the data deluge with frameworks While collecting and sharing rich data helps teams both better understand users and develop shared understanding, this level of research data can be overwhelming. As one team member put it, "this wave of data and context crashed on top of us." Teams should manage the deluge using standard design tools such as personas, frameworks, metaphors, and typologies.

Framing is a means to manage the complexity of the real world (Boos 2007). While rich faceto-face communication helps uncover the complexity of the design situation it then needs to be brought under control. A mentor of mine used to explain, "I don't need you to tell me it's complex. I know its complex. I'm paying you to make it simple for me."

Developing frameworks as a team is an important exercise to develop shared understanding.

Frameworks like typologies, metaphors and position maps deliberately focus attention on certain aspects of the design situation. While building frameworks is commonly seen as helping identify opportunities, frameworks are also therefore an important means for teams to get on the same page. Having detailed conversations about what axes are relevant for a position map, or which metaphors are appropriate helps make frame differences explicit, and, as they refer back to raw research data, helps them negotiate a common frame.

Theme 3: Make decisions on a common basis Theme 3: Make decisions on a common basis Theme 3: Make decisions on a common basis Theme 3: Make decisions on a common basis A tower of bricks will break down at critical heights if it is not built on strong foundations.

When bricks are not in alignment, the overall structure is weakened. In the same way, teams that pass critical decision points, or stage gates, without making decisions on a common basis risk conflict as the decisions are implemented. Making decisions on a common basis is intuitively good practice yet many teams fall into difficulty after passing through important stage gates or producing deliverables without having reached agreement across the team.

For example, a team working on improving the ski-experience were split between its initial focus of a more comfortable ski-lift and helping skiers better plan their day by providing better information on the slopes. As a key deadline loomed the five person team voted with two for each direction and one remaining neutral. The deadline forced the neutral member to choose a direction although the two members who voted the other way were not convinced and the tension was raised as the team proceeded.

Making decisions on a common basis is perhaps more important for NPD teams in the class setting where the members are peers and there is no clear leadership. 24 In industry NPD teams where a project manager may impose a decision on other team members this may be of less consequence (though this research suggests it is not the most productive practice).

The following three principles are to help NPD teams avoid having to make decisions without a common basis.

Manage time for iteration and learning Manage time for iteration and learning Manage time for iteration and learning Manage time for iteration and learning

When decisions need to be made, frame differences are quickly made salient. Only when these differences are made salient to team members can they begin to be resolved. Teams that manage their time to allow for iteration and the gathering and sharing of more information after key discussions help resolve frame differences before key decisions need to be made. Indeed, poor time management is one of the principal factors affecting teams that follow the Backtrack path (Chapter 06).

I also discussed this point in chapter 04

This principle therefore reveals that time management is more critical to a team's success than it may seem. Making hasty key decisions does not just increase the chance of the team being wrong about what needs are really important, it also increases the likelihood that differences in perspectives on the team will not have been fully resolved -either frame conflicts remain or, more dangerously, different perspectives have not yet been brought into the open. This supports Song et al.'s (2003) observation that higher performing teams had high levels of shared understanding just before key decision points or stage gates, but highly divergent perspectives between stage gates.

Another way to manage time for iteration and learning is to follow IDEO's mantra of "fail early and fail often to succeed sooner" Littman 2001 and. While the explicit benefit from this approach is that it allows more iteration to frame the situation according to the needs of users, this research suggests that it also has the benefit of helping the design team learn from these failures and develop a shared understanding.

Manage knowledge gaps on the team Manage knowledge gaps on the team Manage knowledge gaps on the team Manage knowledge gaps on the team When a team member brings specialist technical or market knowledge about the project area a team has a substantial knowledge gap -i.e., one or more members know many relevant things that other members don't. Knowledge gaps lead to very different framing of the problem. In essence, the pseudo-frames the team members arrive with are very different. If left too long these gaps can divide the team as members opinions are not incorporated in critical decisions or they find their ideas repeatedly rejected. While a team should strive to see the world through its users' eyes it is also important to strive to see the project through the eyes of your team members. An effective practice to uncover and bridge these knowledge gaps is the simple act of interviewing knowledgeable team members. This can help keep teams abreast of differing perspectives and knowledge. This explicit discussion of team members' knowledge is in line with Schön and Rein's (1994 170) recommendation that designers need to "probe the meanings that lie behind the messages they receive from other designers, and probe other designers' interpretations that they receive." In other words, if sharing richly is a measure to deal with learning more than we can tell, interviewing your team members is a method to deal with knowing more than we can tell. Teams should make an explicit effort to make that implicit specialist knowledge more explicit.

Take the time to discuss Take the time to discuss Take the time to discuss Take the time to discuss Long discussions often have more value than they seem. They are typically seen as necessary, but painful, rites to make important decisions about user needs, concepts and product features. Yet, this research shows that they also serve the purpose of getting team members on the same page. While it may seem that a long discussion only led to one decision, the actual value in terms of highlighting different frames, making conflicts explicit and negotiating perspectives is actually much greater.

Use the discussions on team mission and vision as time to get the team on the same pageair differences in assumptions, values and expectations so they don't rear their heads in problematic ways later on.

Design teams also need to take time to develop a common understanding of key terms, including what user needs really mean, and any words teams may develop during the project. Using the words of research participants, when possible, helps forge a shared meaning while cutting down on dilution and paraphrasing.

Aiming for unanimous consensus on key decisions will also assist the team as it moves forward. Unanimous decisions require the team to be on the same page and encourage focusing on real user data and taking the time to discuss until agreement is reached. Voting, in particular, other than to promote discussion can be a harmful practice when followed through. A team divided by three votes to two needs to conserve time for iteration and information seeking to resolve the conflict before moving forward. Design teams often desire to create innovative products. The desire to be innovative often translates into a product that is different and novel, but without necessarily being usefulthe team ends up with a fun story, but one that doesn't resonate with its target market. The most effective way to create innovative products is to not to strive for novelty but to design products that meet eventual users real needs. Trying to meet users' unmet needs will often result in an innovative product, while striving for an innovative product says nothing about the needs it may or may not meet.

A product the design team sees as innovative is necessarily their own evaluation of the product where what matters is how the target market sees it. As discussed in Chapter 01, the innovative technology of the Segway didn't help regular users warm to it. As Berkun (2007) Look for the story behind the product Look for the story behind the product Look for the story behind the product Look for the story behind the product One of the reasons why teams often aim for innovative products rather than more mundane, need-meeting products is not appreciating the value of having found the right story behind the product. A powerful story can reframe our understanding of a product making new benefits visible and allowing effective selection between alternative concepts. For example, the healthy noodle team was frustrated after choosing its concept direction, as one member commented, "Wow! We could have thought of that idea like the night before." However, it was their deeper understanding of the needs of their users and why this concept resonated with them that both allowed them to select their direction and also provide a compelling message around their final offering -one based around recreating a traditional meal through fresh ingredients. In a similar way, Huggies Pull-Ups are only a minor change from traditional diapers -they have an elasticized waistband and they are sealed at the sides. Yet it was a fundamental shift in understanding that diapers are not just waste disposal products, but children's clothing, and that children's clothing symbolizes future success, that allowed this product concept among the many others to be chosen and marketed effectively -"I'm a big kid now." Powder Net's basic technology did not substantially change, but the team's understanding of how to pitch its value to the business market did.

The message is that even if the final product looks like the original idea, finding the story behind the product is worth the work it takes in user research. Understanding, or finding, the story that makes a product resonate with users allows the team to select between concepts and increases confidence that the path is the right one. "There was definitely a point where we had false clarity in the project. We thought we had it all figured out and some great ideas, but when we went to making them we found the details often tripped us up. It's kind of like writing pseudo code and thinking you have it all done before trying to write the real thing and finding that a lot of things didn't work.

So after we sat down to making these products and found out they weren't feasible there was a time when we were confused and just scrambling to get something together -something that was cool and useful at the same time."

Another design coach commented about his experience with one team that learned from its testing:

"I had a team that was going to reinvent the cereal box. They came up with a good range of solutions. Their favorite was one where you tip it over and it

gives you a fixed volume. They we're like, 'This is brilliant. We're done.'

Now the industry thinks the PET bottle is the answer but it's too expensive, so you can't outsell the cardboard box. So I said, 'Why don't you go back out and test with your product and the PET bottle as a control.'

The PET bottle hammered them. Totally smashed them. They were stunned.

But I was proud of those guys. They said "We have to start over." In the end they came up with a very real solution but really they were disappointed because it didn't have that flash factor. But it's the obvious stuff that matters."

In other words, testing helps ensure that a team is focusing on real needs over innovation.

***

Having presented the four themes and design principles I now turn to simple team practices to help design teams elicit differences of framing during team meetings and a lightweight method to support designing with metaphor.

Simple team practices: "This project i Simple team practices: "This project i Simple team practices: "This project i Simple team practices: "This project is s s s about…" about…" about…" about…"

Pugh's Concept Convergence (PCC) (Pugh 1991), though intended to help teams make design decisions, actively assists in encouraging the kinds of conversation that both make assumed knowledge explicit and provokes discussion towards developing shared understanding. Like brainstorming, which was found to also serve several useful organizational functions beyond idea generation such as preserving corporate memory (Sutton and Hargadon 1996), the utility of PCC is more than its explicit purpose. For example, Frey et al. (2007)

explain how

Pugh's method should proceed when some experts disagree: "In Pugh's method, a discussion proceeds in which the experts on both sides communicate their reasons for holding their views. In many cases, this resolves the issue because either: 1) facts are brought to light that some individual experts did not previously know, 2) a clarification is made about what a design concept actually entails, or 3) a clarification is made about what the criterion actually means." However, as we saw earlier, Pugh's tool is probably only used by a small percentage of firms (Salonen and Pertulla 2005), perhaps because of its appearance of complexity, and it is typically only turned to in the concept selection stages of the process. ID 2 -Innovation, Development, Diffusion (Legardeur 2001;Legardeur et al. 2003;Hey 2002) -a tool similar in appearance to PCC, was however explicitly designed to facilitate discussion, negotiation and understanding between actors in a project in the upstream phases of a design project. The tool includes functions to allow actors to comment, question, link or raise an alarm about different features and concepts. However, the software tool is designed to be used remotely and asynchronously. There remains a need for lightweight tools that can be employed at any stage of a project in a face-to-face design team meeting. In this section I present an illustration of such a tool, the rationale behind it, and the benefits of it in action.

This project is about… This project is about… This project is about… This project is about…

The "This project is about…" tool was designed to support the framing cycle proposed in Chapter 05 (also Hey, Joyce, and Beckman 2007). The framing cycle has the four stages of: Pseudo-frame setting; individual frames made explicit; conflicts among individual frames made salient; and common frame negotiated. The cycle implies that to negotiate a common frame, frame differences must first be made explicit and the conflicts made salient. I observed a common cause of difficulties was when teams first did not make their individual frames explicit, and, consequently, conflicts could not be made salient. In other words, differences were never brought into the open and so the team remained unaware that differences were even present.

Team members are not always clear on their framing of the situations. Writing their thoughts down forces them to make their framing explicit (to themselves and others)

The deliberately vague prompt allows for different interpretations by members allowing members to pick out what they see as important. For example, some members will focus on the higher goals they see as important, others will focus on the specific needs they see as most important. Open interpretation encourages team members to share what they think is most important.

Using Post-Its with the goal of sharing requires members to focus their thoughts, getting to the heart of the issue as they see it and cutting out the minutiae -there is not room on a Post-It for more.

Working individually before sharing encourages identification of conflicts as members don't know what others will write until they see it.

The explicit differences on the Post-Its encourage the team to come to a shared agreement before they move-on. If they don't come to agreement at least the team is now conscious of the frame conflicts as they move forward.

The tool was also inspired by the simple observation that the clearest evocations of a team's framing of its project in interviews was in sentences that began, "This project is about…"

In action In action In action In action

The tool was used as part of a facilitation session for one team designing a product involving young children and the Internet -Kid Net. The original inspiration for the project concerned leveraging the collective knowledge of parents to help create lists of web sites to protect kids from. After speaking with many parents and children the team had identified many different needs regarding children and the Internet that went beyond the original project vision. I facilitated an exercise with the team using the "This project is about…" tool.

Forced to cut to the essence of their project each member took several minutes to complete his or her Post-Its and two members took more than one Post-It. Responses included:

This project is about allowing children to explore the Internet the way they want to This project is about providing Internet training wheels for children This project is about protecting children from the dangers of the Internet This project is about giving parents confidence to let their kids explore the Internet This project is about making a kid-friendly entrance to the Internet When the Post-Its were shared in the center of the table the team was surprised by the diversity of responses. Some members felt strongly for or against each view. A discussion ensued as to why each member had put forward his or her view. The team referred to its research data to settle differences of opinion. In some cases, on seeing other perspectives, team members quickly disregarded their own Post-It in favor of others.

Encouraging the team to create one unified vision caused it to rate the importance of each view. For two members the perspective of the parents had not been fully realized. At the end the team settled upon:

This project is about giving parents confidence to introduce their children to the Internet All of the team members agreed with the statement as representing the most important goal of their project. More importantly, in a lightweight and inclusive way, the tool provoked a full turn of the framing cycle -making individual frames explicit; making conflicts salient; and negotiating a common frame.

Considerations in practice Considerations in practice Considerations in practice Considerations in practice

It is possible for conflicts not to become salient during the exercise when team members choose different levels of abstraction for their sentences. For example, one member may write, "This project is about lighting offices more pleasantly," and another may write, "This project is about improving the productivity of office workers." In this case, the first member has framed the project at a more specific level than the second. According to Patnaik's Need Hierarchy (Patnaik 2004) the first member has framed the project around an activity-level need and the second around a broader context level need.

This situation can leave conflicts unidentified even though they may be present. When this is the case, abstraction levels can be matched by asking How on the broader level statements, and Why on the more specific statements. For example, "Why do people need more pleasant lighting?" -is it because they need to improve productivity, or for some other reason. And if the team asked, "How would they improve the productivity of office workers?" has it been decided that improved lighting is indeed the best way. By asking these questions conflicts are once again made salient and the team can find a framing that they can agree on.

When a team struggles to produce one shared response the discussion can be the most productive as they identify what the points of contention are. Later in the project the most effective ways of making the decision will be to turn to the research data the team has collected. This provides grounded common data the team can appeal to.

Summary Summary Summary Summary

The "This project is about…" tool provides a means for teams to negotiate the stages of the framing cycle making their individual frames explicit, the conflicts salient and fostering discussion towards a shared frame.

The tool is provided here as an illustration of a simple, lightweight team practice explicitly designed to help teams deal with framing issues in NPD projects.

In this dissertation I also presented a study of metaphor use as a framing tool. Metaphor was seen to be a useful framing tool; however, its use could be improved through a simple method that better enabled teams to successfully identify compelling metaphors. Below I present a simple metaphor design process, its initial evaluation, and a tool to support this metaphor design process.

Supporting

Supporting Supporting Supporting metaphor use in design metaphor use in design metaphor use in design metaphor use in design

This work was born out of the insight that, despite well documented cases of metaphor use in design, there is little guidance for teams who wish to use it. The process of developing, or finding, the metaphor is difficult to reconstruct. The instances of metaphor use are often accompanied by a sudden creative insight or a suggestion from a team member and not from a repeatable process. If your team does not have that creative association then metaphor use will remain sporadic at best. Together with Erik Kolb, I set out to develop a tool that could assist in finding suitable metaphors (Kolb et al. 2008). To develop the tool it was necessary to delineate more clearly a process for generating metaphors. The process is also standalone and able to be used with or without the support of the tool. Below I discuss this metaphor design process and its evaluation in an undergraduate design education course to positive results. I then describe the tool, meta4acle, for generating metaphors that can be used to support the metaphor design process.

A metaphor design process A metaphor design process A metaphor design process A metaphor design process

The metaphor design process was developed from a reverse analysis of successful metaphor cases reported in the literature. The process has four primary stages and was produced as a worksheet, shown in Figure 8.2. The worksheet walks teams through the following stages:

Figure 8.2 Design Metaphor worksheet

In the first stage the team or designer, selects the attributes they require in their offering.

Typically, these attributes will be based on key user needs (e.g., relaxing, comfortable) or technical requirements (e.g., quiet, small) of the product or service. Requiring distant domains increases the chance of novel associations that are more likely to provide unexpected insights for the project and to differentiate the eventual offering from competitors.

The search for design metaphors in stage three is challenging. In practice it involves running through a mental checklist of concepts within the distant domain that share some or all of the desired attributes. While this stage is the most mentally difficult and has the most potential for uncertainty, in practice I observed individuals using the process were able to find interesting and relevant metaphors within ten minutes. The worksheet instructs the team members to record their metaphors, and, while the association is fresh in their mind, make a note of why they seem appropriate.

The final stage is optional as in many cases the choice of a suitable metaphor in stage three may already prove useful by providing a common means of communication for the team and a new perspective for understanding, or reframing, its design situation. However, the metaphor can be of further use in generating concepts by asking what useful features of the source concept selected are not present in any current solutions or products.

Testing the metaphor design process Testing the metaphor design process Testing the metaphor design process Testing the metaphor design process

The method was employed as a design exercise in an NPD module of an undergraduate engineering design class. As an introductory design class there were two five-week project modules, each with approximately 50 students. Two sessions of introducing and using the tool were performed during class time. In the first session teams shared one form between them, while in the second each team member worked on their own form. The students were already divided into project groups from 4 to 6 people and the teams participated in the exercise after they had performed initial user research, and gathered and prioritized needs for their project. These needs could therefore serve as the basis for the attributes. The teams then continued their projects to produce a final tested prototype and final presentation. The students were not required to use metaphors in their final project. The process for using the tool is similar to that of the design metaphor worksheet:

1. The design team inputs information about the desired characteristics or attributes of a suitable metaphor from a limited vocabulary 2. The tool performs a ranking from a database of potential source concepts to order those sources that possess the highest match of desired attributes 3. The tool returns to the most suitable source concepts together with the reason, in terms of attribute scores, for their selection 4. The team then selects from the suggested sources a metaphor they feel is appropriate For more details of implementation and evaluation see the paper, "Meta4acle: Generating compelling metaphors for design," (Kolb et al. 2008). The key differences between the pen and paper method and using meta4acle are that the desired attributes are rated numerically In our preliminary evaluation using data from three randomly selected past NPD design projects (from those selected in Hey, Linsey, et al. (2008)) as input we found that in each case meta4acle recommended source concepts that made suitable metaphors, and more interestingly, the tool also recommended metaphors from more distant domains than the design teams' actual choice of metaphor used in their projects.

Conclusions

Conclusions Conclusions Conclusions

In this chapter, I built on the models and research developed in this thesis to make recommendations for effective design team framing activities. I structured the contribution around two primary directions: increased understanding of framing activities and their consequences; and the development of simple team practices. With regards to understanding I presented four themes -Learn, don't confirm, Share richly, Make decisions on a common basis, and Drive innovation through real needs -and corresponding design principles to help design teams understand the consequences of their early stage design activities. I also presented the "This project is about…" tool as an illustration of the kind of simple team practice that can be developed to encourage productive dialogue about design team framing.

Finally, I presented a simple process and a tool developed to support the use of metaphor as a framing tool.

An alternative approach that would complement increased understanding and simple team practices is simply an improved awareness of the importance of framing in design and the less obvious consequences of framing activities. Addressing awareness is less direct and could perhaps best be approached through careful coaching of design projects or explicit attention to framing activities in design curriculum. An alternative approach is a tool that helps designers learn about framing activities and possible pitfalls without having to learn about them firsthand. One possible tool to this end based on the format of "Choose your own adventure" books is presented in the Appendix. The book allows NPD students to choose their own design path through a series of choices and to quickly learn the, often unanticipated, consequences of their actions.

Another consideration with the recommendations presented in this chapter is the effect of making implicit practice explicit. The themes, design principles, choose your own design path education tool and "This project is about…" tool presented here belie an assumption that more explicit understanding of design team framing can lead to better team performance.

However, making implicit practice explicit is not without its dangers. Asking a tennis professional to explain his or her serving action brings the implicit (or tacit) knowledge about the swing to the forefront of his or her mind. Thinking about how he or she does it, can, however, interfere with the swing itself. For example , Valkenburg, (2000), makes specific recommendations for the role of the project manager to become a 'frame coach', 'reflection guard' and 'move helper'. In advocating the adoption of the role of 'frame coach' Valkenburg is encouraging teams to be aware, and reflect on, their own framing practice. I don't know of any experimental results of this recommendation but we should acknowledge that, as with the tools presented here, its positive benefit is not assured. The effect could also vary depending on the expertise of the designers.

Figure A1 New product development alumni survey page 1

Finding framing Finding framing Finding framing Finding framing data collection and analysis data collection and analysis data collection and analysis data collection and analysis Data collection protocol Data collection protocol Data collection protocol Data collection protocol for MIT for MIT for MIT for MIT Data collected at the MIT new product development class followed the data collection at

Berkeley. It was assisted by Jessica Dolak. Below are the key tasks included in the data collection protocol:

1. List of people and projects -class roster, project name, major, contact details Interview guide Interview guide Interview guide Interview guide

The following questions were used as an interview guide for interviews at UC Berkeley and MIT. Interviews generally covered the majority of the initial questions, but remained flexible

to learn about what the teams found valuable to discuss. Data analysis protocol Data analysis protocol Data analysis protocol Data analysis protocol To find framing in the data collected we looked for instances where the key elements of a frame would change: a desired end state or goal (mission; prioritization of needs); relative importance and relevance of features (identification of needs); boundaries to the design situation (problem scope, solution scope, resource constraints, stakeholders); criteria for evaluation (of new information, features, and possible solution concepts). As the analysis continued additional important elements were added particularly regarding differences between individuals. The following issues were considered: The following is the coding scheme followed for the design path study. I present the themes identified and example quotes from each, primarily from interviews, though several are from written survey responses. Two researchers developed this coding scheme building on that developed for the finding framing study. Both researchers reviewed each interview. The intent was not to replicate identical coding between researchers but to be inclusive, i.e., if one researcher highlighted a quote the other didn't it was included in the discussion. "actually, at that time our mission is very broad like all kinds of extreme sports."

"there were two things, there was the sensor or the clothing prototype and we had to kind of decide … it was very vague and Alice kept saying it's up to you all and so as a team it was … everybody had different … I was more towards the sensor, being a technical person" "He had already at the time proposed it, I'm sure you remember he proposed a solution rather than a problem. Said we were already thinking of luggage you can sit on."

Surprises "A lot of it is based on doctor's impressions and I was really surprised that really the patient doesn't get a say in it as well. So whatever, if the doctor wants to give you medicine to treat it he gives you medicine. If he thinks you're ready for a procedure then you get a procedure. There's not really a lot of say you have in it."

"I mean like the manufacturer I just spoke to. You know they have such targeted ways of doing their work and like they don't … like they don't get that specific in the design process. And I was surprised to hear that but that was … kind of the truth." "we all kinda had the wind kinda knocked out of us as a group when we had to just change gears"

Performing user research (including how it was done and how much)

"It was nice when two people could do the interviews too then, like the preschool teacher, both of them would hear her. We got different things out of it. They notice different things."

"We couldn't ask up front very quantitative questions it was very sort of qualitative which meant that every single person gave us a completely different answer. And so I think what we recognized was to some extent this is such a new concept for a lot of people that it's hard to even ask them how they feel about it because they can't see it and they don't know what our vision is -we didn't even know what our vision is at that point."

"but we didn't do any extensive research or asking experts about it"

Different learrnings "we all latched onto different stuff."

"I think we still haven't all learned the same thing from our conversations"

"I think we came to different conclusions from the things that people were telling us."

Sharing user research "I'd much rather trust my teammate to capture the information and to communicate to us"

"but for certain parents that I spoke with I don't really feel everyone needs to read it to pull out the key issues and so you know there's a lot of repetition in different parents. You don't need to read everyone's."

"everybody did it a little differently. Some people just like wrote down a summary of the interview. I don't think they transcribed it."

Choice of target market "We didn't really interview any executives which is one of the many reasons that we decided that executive lunchbox is not the best way to go with this project."

"We spoke to a lot of people … I don't know what the typical group does but it was harder. Like you're trying to do a design for some consumer product you can go and just get your buddy to sit down with you for thirty minutes and ask them as a consumer. For us we had to be really targeted.

We had a big circle at the beginning and I spoke to a couple people who were in the manufacturing end. Some of us spoke to designers. And then from there as we got a little bit more targeted I think we kinda let dim the light a little bit to do it"

"How can you say their needs are any more important than this other group? At some point I think you just have to throw a dart and see where it lands."

Prioritizing needs "And a lot of them will feel very different. Like one says it has to make a lot of noise and the other person says it shouldn't make any noise at all. So it kind of made, going and talking to a lot of people a little bit frustrated cause at the end of the day you want to go and talk to people to help identify what the needs are. But when you're getting fifty percent saying one thing and fifty percent saying the exact opposite, and you're valuing your time then going in and doing a lot of that isn't a good use of your time."

"Different types of people preferred different ones depending on their needs so I think that was very hard to figure out. Which one, which emotional need is important and I don't think that you can say that one is more important than the other."

"I think there might be a bigger problem here. These [interviews] just opened my eyes."

Evaluations by users "they just didn't have the … like they just didn't have an opinion at all about it." "The parents just didn't get it. We said it was a safety device, so they didn't understand how it could also be a toy."

"when we talked to customers they didn't … it didn't jump out at them like as we hoped. Like we didn't see that need come through."

With regard to the team's shared understanding With regard to the team's shared understanding With regard to the team's shared understanding With regard to the team's shared understanding Different values "I thought if I am going to have to do all this work I am going to work on something that I believe had potential versus something that's a complete class exercise."

"there was a little bit of um disagreement about our goal in the sense that I was always interested in kind of actually creating a business out of it and everyone else was more interested in kind of fulfilling the requirements of the class and getting a good grade or whatever."

"my interest is in emerging technologies and emerging wireless communications in consumer electronics…I really had no particular interest if it was kitchen or the living room, direction, where the device was going to be was none of my interest. But the technology behind it was important."

Knowledge differences "he had worked at a company developing the medical devices he showed in class so he had all this background knowledge and we had none" "So I knew the field pretty well and so I figured, let's propose it and see what would happen if we try to do it as a consumer product."

"I think for us it is, we … they … there was such a gap in the amount of knowledge on the subject."

Strong agreement "we all jumped on board the story that we wanted to sell" "I think we're all agreed up to this point."

"none of the interviews that we've done have lead us to that conclusion so we might just have to strike it."

"Currently, the team is on the same page and we have not gotten into any disagreements."

Differences in perspective "While we were talking about what solutions would be and maybe putting words up on the board and maybe even draw to the best of our abilities after like another week of trying to work on that one concept, it would take like a week to realize that we still had different ideas to what this thing would look like in the end. And even now when we're talking about the final thing is going to look like in the end, it's still different between like my head and probably everyone else's head."

"I think we recognized that we had to and if we didn't iterate on the concept selection that we were going to not even all be on the same page about what path we were going down."

"that's when it became really apparent that we were asking very different questions cause we had such divergence of ideas. Like Jesse only asked questions about the refrigerator which was obviously very very different from the rest of us."

Split decisions "We gathered the points and it was like if he chooses the bag then we're two and two and we're not going anywhere so we just said like you decide which one."

"the info school students were keen on addressing that need, and the engineers wanted to make the better lift."

"or we could just flip a coin." <laughs> Team conflict "we got into heated discussion but not in a negative way just like we would get very deep" "I just feel like the whole underneath the sink just came out of nowhere and just like one person started using that word in every meeting and suddenly we need to design under the sink? And then I was just like I wasn't so … I think it was my problem with how the idea was borne and I didn't think I resolved it too well with the group but every meeting I was like Ughhh.

"Our team had a communication breakdown which we resolved by meeting to discuss our conflicts without discussing anything about our project. We were able to focus on our interpersonal issues. This brought us closer together and strengthened our team and lead to the success of our final product."

Tension points "We were there for so long and it was … we got there at five PM and it was already a long day so I think we stayed there until like nine, ten and all of us were very crabby at the end after arguing for a very long time …"

"up to that point we never really had like a contentious discussion I would say. Real time like the group had take sides or had started to become polar in a way"

"Some of us were rather for developing a new type of bike rack, others rather wanted a new type of lock. At first we kept these two directions because it was a source of richness as far as creativity is concerned. But we needed to take one direction eventually and we did not really agree on that.

In the end arguments of feasibility in the timeframe of the course convinced everyone to go for a new lock, and not a new rack."

Emotion " had an idea that didn't get carried forward and I got hurt about it so what I did was I renamed one of the ideas that was being carried forward my idea"

"we've been trying to keep this wide but it's really frustrating."

"we did have one time of conflict. Bryan was upset after the last survey about what the other group members thought of his effort. Although we had an uncomfortable conversation discussing it, he definitely contributed a lot more the second half of the class. Over time, we found that everyone seemed to develop their own niche to contribute to the process."

Focusing (selecting and narrowing)

"one of the huge challenges throughout this process is that there was just too many things to take into account so how to navigate that was one of our biggest challenges and I think at various points we just eliminated those things, like took them off the table for a little while and I think that was successful."

"But you know I think it was we had to do that for our [sanity?] … so that we had to do what we did well rather than doing a lot of stuff really really at a surface level."

"we met with our coach at his office and laid it all out on the floor for that and we basically kind of like aired our feelings like I don't want to do this because of XYZ. I felt like that was a good time, like a good forward movement for us then at the end I think it came out like two or three and our coach was just kind of 'alright, pick one,' and you know you're stuck with it kind of thing. I don't know I think that was a good focusing moment for us."

Assumptions and filters "when talking to doctors it was very clear that physical and mechanical removal was the only way to go"

"we have to think of our capabilities to get this done within ten weeks."

"it's safe to assume that the people who'd buy this would also…"

Metaphors (process and content)

"they're right at that hill and you just want to put the brakes on them."

"We felt like we were boiling the ocean and everything that she described, exactly what we went through, this sort of wave of data and context crashed on top of us"

"Prototypes are our friends."

Important events Important events Important events Important events

Key decisions "in the beginning we didn't really know that there were two different styles and then we had this one big discussion I think the night before the trade show where it turned out we talked about two different things" "I don't know if 'flip-flops' is the right word as much as this sudden requirement to narrow dramatically in like an hour that really led to like kind of … this maybe, arbitrary, not so much arbitrary but just like 'we have to do this now!' Just like, you know? And this happened probably like three times which is like way too much considering we made like three decisions in the semester."

"I think that some of the major decision points or catalysts came whenever we went back to the users and whenever we talked to Sara, the two conversations in particular, the one where they said we weren't really listening to our users' needs, I thought that was a big eye opener and we were like, Yeah you're right. We kind of went from the needs to -we did the needs and then apparently we did the personas and independently we did the concept testing and we didn't actually look from one to the other."

Stories "I had dinner with my cousin who I haven't seen in a while and he had a bunch of little kids with him. Uh, dinner took too long and the kids were getting antsy. Things were getting thrown at me or thrown down to the ground and the parents were getting irritated. And they ultimately left dinner before the food ever came and cut our time short. And I've seen similar circumstances happen on an airplane. So at that time I thought wouldn't it be cool if there was a toy that did this."

"we went through the whole process of saying I like this and this and this and this and we narrowed it down and a prototype was already done so I was expecting just a nicely done version of the prototype and the actual renderings that came out was rather different wasn't it? It was missing straps and it didn't have the features. The volumes of the compartments were totally different. So it seems like there's a last minute desire to sort of beautify it to a certain extent. I don't mean to discriminate but I was surprised as to how different it was to what I thought … what I expected it to have."

"I interviewed one professor that had the most amazingly vehement reaction to the entire institution of education content. I really didn't quite know what to do with it. I mean she was so irate and disenchanted with the way the content revision mechanism had taken place at the university. Then she basically said, "Yeah you're going to try to do something but you're not going to change anything." She was totally hopeless and it was really weird … then she apologized after the fact 'I'm sorry! Let's have the interview again duh duh duh,' but I was shocked by the nerve that the interview struck and also how strongly people feel about this topic."

Time management "I think we also set up more regular meetings in the beginning which is probably good because it allowed for us to have sort of the open air time so it allowed us to talk about a lot of these things."

"But I don't think we had either the opportunity nor the time to go in and actually ask them again to talk more about that at that point so I think that would have been interesting."

"to stay on track I feel like we need a list of prioritized needs today."

Design path classification protocol Design path classification protocol Design path classification protocol Design path classification protocol

In this section I present details of the protocol used to help follow the different paths of the design teams and classify them into Back Roads, Backtrack and Direct. The researchers asked a series of questions of the team's situations as it moved through the process in approximately these phases: the initial project assessment; during the gathering and digesting of user research; deciding on a final direction; and the final outcome of the project.

The data sorted into the themes and the raw data was used to answer as many of the following questions as possible. Even with the volume of data collected it was not possible to be confident about the answer to all questions. However, in most cases, there was sufficient confidence with the answers to other questions that team placements could be confidently made.

Initial project assessment: Initial project assessment: Initial project assessment: Initial project assessment:

Did the team have a clearly defined product in mind or was it a broad and open mission?

Did the team members agree on this original mission?

Did the team share similar values but have no clear product direction?

Did the team members have the same goal for the project?

Is there a knowledge gap within the team?

Gathering and digestion of research Gathering and digestion of research Gathering and digestion of research Gathering and digestion of research Did the team members learn similar things from their research?

Did they perform their research together?

Was the team's thorough research?

Did they share richly and take time to learn from each other's reserch?

Did they set out to confirm their original needs?

Did they learn anything new?

Did team members agree on a new framing and target user or where they more confused?

Did they do a substantial number of interviews?

Did they learn from users who weren't simply friends of the team?

Project direction decisions Project direction decisions Project direction decisions Project direction decisions Did the team reach unanimity on decisions?

Did they let the research data or user testing make the direction decisions?

Were decisions split between the team or were they resolved?

Did they backtrack to their original product vision?

Did they learn from research testing and perform another iteration?

Did the team bridge any knowledge gaps? Was all the team united behind their final outcome?

Through looking for information in the data collected to understand the answers to these questions it was possible to place the teams at different positions in the framework throughout their projects. Identification of the profiles of the team's path was done by aggregating the positions chosen by the two researchers.

To illustrate how these considerations guided the placing of the teams below is the path for the More Blood Donors team with corresponding data points labeled with each position and the source of each data point, Figure A6.

Figure A6 Example of design path classification

Choose your own design path tool Choose your own design path tool Choose your own design path tool Choose your own design path tool Raising awareness of the importance of issues of design team framing helps teams learn about both good practices and pitfalls without having to make errors first-hand -an attempt, as much education is concerned, to shorten the path to experience by just a little. Just as there are many possible principles to carry out the themes in the previous section, there are many ways to raise awareness of the issues involved in design team framing. In this section I illustrate one possible path for increased awareness using the design of an educational tool Choose your own design path, developed in collaboration with Jonathan Yu. I describe the basic features of the tool, the process to design the tool and illustrate how the tool is used.

The Choose your own design path tool The Choose your own design path tool The Choose your own design path tool The Choose your own design path tool

The Choose your own design path tool was developed based on the realization following the analysis of many teams' experiences that NPD, as experienced, is a series of sequential decisions. Although user-centered design processes require iteration, at each meeting decisions are made with regards to who to speak with, what questions to ask, how to generate concepts, how to share research data, how to select between concepts, how to conduct user testing and who to test with and so on. The Choose Your Own Adventure series of books follows a similar model where the reader, identified with a character, at each page is able to select a choice of action for the character -should they take the left fork in the road or the right? Choose your own design path is built following this basic scheme. It was also inspired by a graphic novel of the NPD process based on the MIT NPD class developed "as a tool to help students unfamiliar with the product development process, teaching the main steps and familiarizing students with working in groups and with deadlines" (Wong 2004).

Importantly, the Choose your own design path tool is based on a series of linear process decisions. While clearly a design team needs to make numerous product-based decisions throughout the design process, this tool is focused on learning about the consequences of process-based decisions.

The Choose your own design path tool has several advantages over traditional tools for raising awareness such as lectures or traditional books. It is more interactive, providing greater engagement and ownership over one's design path while at the same time allowing participants the opportunity to see previously abstract forces in real, practical terms. The decision-making required to continue in the book encourages reflection. The lightweight format is quick to absorb and allows NPD students to experiment with many possible paths.

In this way they can see possible outcomes not just of their decisions, but also of the alternatives. The book format also increases awareness without requiring the presence of multidisciplinary team members. Last but not least, reading through the paths is enjoyable.

Development of the tool Development of the tool Development of the tool Development of the tool

The tool was developed around a team whose path was well known and understood, the healthy noodle team. By necessity this team can only have experienced one of the many possible paths. Together we mapped out the key decision points that affect design team framing, derived from both Chapters 05 and 06, and illustrated the actual path the healthy noodle team took. This turned out to be the skeleton around which the rest of the design tool was designed.

Key decision points need to reflect important framing issues and through their selection illustrate the consequences of different choices. The key decision points included: Even with only 7 decision types the map of paths increase almost exponentially. Allowing only 2 decisions per path a maximum number of paths would be 2 7 = 128 possible design paths, and therefore distinct scenarios to envision. To keep the task manageable, and the teams path more varied, not all paths follow the same succession of decisions and we arranged for paths to meet each other -i.e., some situations can be accessed by more than one route. This left 30 unique situations to write. Figure A7 shows the map of decisions.

Figure A7 Decision tree for 'Choose your own design path' tool

Writing was an iterative process beginning with the actual team path and then expanding to include the possible consequences of decisions they didn't take, derived from the stories of other teams in similar situations. To ensure these situations were realistic we again returned to situations experienced by other teams but changed the project details to conform to the healthy noodle project. We continually reread the different paths to ensure that the story for each flowed correctly.

Each new situation was designed using the following template: illustrate the consequences of the team's previous decision; provide context for the new design decision with possible directions; illustrate some pros and cons for each; provide two choices leading to a new page.

To prevent ourselves from being too restricted, "context" pages were inserted in between certain "decision" pages in order to expand certain relevant subjects without being constrained by page limits.

Macro level feedback is provided by the overall outcome of the design path after the final decision. According to the design teams we observed, paths lead to one of three possible outcomes -high-performing, average performance and low performance. These criteria are founded on the overall experience of the team members after completing the project as well as the reception to the final product by users. In keeping with typical distributions, the majority of paths lead to average performance.

T T T The tool in action he tool in action he tool in action he tool in action Figure A8 illustrates one choice in the adventure. In the first page the team is trying to decide on how it should start its research. One team member proposes the team splits up and team members speak with people they think are close to the market. Another team member isn't so sure and thinks they should take some extra time now to discuss exactly who they should try to speak with. The page explains the advantages of each approach -gaining many different perspectives, or staying more focused but with more time spent now up front. The core issue is one of developing shared understanding of their target market. The reader is left to decide whose suggestion to follow.

If the team chooses to split up now the reader learns that the team interviewed a wide array of different users. It turned out people had very different ideas. And the flexibility also led most people to speak with friends and family. As people describe their findings they gloss over the details. One member is frustrated they didn't learn much and wants to meet the next day to go over the data in more depth. Another member says it would be better to spend the time getting some ideas out. The decision is put to the reader again. This time the core issue concerns the disadvantages of paraphrasing research, partly caused by an attitude of confirming -the team already thinks they know what is important -rather than learning.

Table 4 .1.

Table 7 .