PRODUCT DESIGN

Adapting the Generic Product Development Process

The development process described by Exhibits 2-2 and 2-3 is generic, and particular processes will differ in accordance with a firm's unique context. The generic process is most like the process used in a market-pull situation: a firm begins product development with a market opportunity and then uses whatever available technologies are required to satisfY the market need (i.e., the market "pulls" the development decisions). In addition to the marketpull process outlined in Exhibits 2-2 and 2-3, several variants are common and correspond to the following: technology-push products, platform products, process-intensive products,

customized products, high-risk products, quick-build products, and complex systems. Each of these situations is described below. The characteristics of these situations and the resulting deviations from the generic process are summarized in Exhibit 2-4.

Technology-Push Products

In developing technology-push products, the firm begins with a new proprietary technology and looks for an appropriate market in which to apply this technology (that is, the technology "pushes" development). Gore-Tex, an expanded Teflon sheet manufactured by W L. Gore Associates, is a striking example of technology push. The company has developed dozens of products incorporating Gore-Tex, including artificial veins for vascular surgery, insulation for high-performance electric cables, fabric for outerwear, dental floss,

and liners for bagpipe bags.

Many successful technology-push products involve basic materials or basic process technologies. This may be because basic materials and processes are deployed in thousands of applications, and there is therefore a high likelihood that new and unusual characteristics of materials and processes can be matched with an appropriate application.

The generic product development process can be used with minor modifications for technology-push products. The technology-push process begins with the planning phase, in which the given technology is matched with a market opportunity. Once this matching has occurred, the remainder of the generic development process can be followed.

The team includes an assumption in the mission statement that the particular technology will be embodied in the product concepts considered by the team. Although many extremely successful products have arisen from technology-push development, this approach can be perilous. The product is unlikely to succeed unless (1) the assumed technology offers a clear competitive advantage in meeting customer needs, and (2) suitable alternative technologies are unavailable or very difficult for competitors to utilize. Project risk can possibly be minimized by simultaneously considering the merit of a broader set of concepts which do not necessarily incorporate the new technology. In this way the team verifies that the product concept embodying the new technology is superior to the alternatives.

References and Bibliography

Many current resources are available on the Internet via www.ulrich-eppinger.net

Stage-gate product development processes have been dominant in manufacturing firms for the past 30 years. Cooper describes the modem stage-gate process and many of its enabling practices.

Cooper, Robert G., Winning at New Products: Accelerating the Process from Idea to Launch, third edition, Perseus Books, Cambridge, MA, 2001.

for STEP BY STEP GUIDE autocad simple tutorial please visit.........

www.autocadsimpletutorial.blogspot.com

---or---

www.autocad-simple-tutorial.com

Learning to Design

An appropriate use of the 'solution-focused' approach to design is something that seems to develop with experience. Experienced designers are able to draw on their knowledge of previous exemplars in their field of design, and they also seem to have learned the value of rapid problem-exploration through solutionconjecture. In comparison, novice designers can often become bogged down in attempts to understand the problem before they start generating solutions. For them, gathering data about the

problem is sometimes just a substitute activity for actually doing any design work.

However, novice designers are also frequently found to become fixated on particular solution concepts. Early solution concepts are often found to be less than satisfactory, as problem exploration continues. Novice designers (and sometimes more experienced ones) can be loath to discard the concept and return to a search for a better alternative. Instead, they try laboriously to design-out the imperfections in the concept, producing slight improvements until something workable but perhaps far from ideal is attained. Sometimes it can be much more productive to start afresh with a new design concept.

Another difference between novices and experts is that novices will often pursue a depth-first approach to a problem: sequentially identifying and exploring sub-solutions in depth, and amassing a number of partial sub-solutions that then somehow have to be amalgamated and reconciled, in a bottom-up process. Experts

usually pursue predominantly breadth-first and top-down strategies, as recorded in the example of the expert designer's decision tree in Figure 6 (Chapter 1). Experienced designers, like any skilled professionals, can make designing seem easy and intuitive. Because skilled design in practice therefore often appears to proceed in a rather ad hoc and unsystematic way, some people claim that learning a systematic process does not actually help student designers. However, a study by Radcliffe and Lee (1989) did show that a systematic

approach can be helpful to students. They found that the use of more efficient design processes (following closer to an ideal sequence) correlated positively with both the quantity and the quality of the students' design results. Other studies have tended to confirm this.

From studies of a number of engineering designers, of varying degrees of experience and with varying exposures to education in systematic design processes, Fricke (1996) found that designers following a 'flexible-methodical procedure' tended to produce good solutions. These designers worked reasonably efficiently and followed a fairly logical procedure, whether or not they had been educated in a systematic approach. In comparison, designers either with a too-rigid adherence to a systematic procedure (behaving 'unreasonably' methodically), or with very unsystematic approaches, produced mediocre or poor design solutions.

Successful designers (ones producing better quality solutions) tended to be those who:

• clarified requirements, by asking sets of related questions which focused on the problem structure

• actively searched for information, and critically checked given requirements

• summarised information on the problem formulation into requirements and partially prioritised them

• did not suppress first solution ideas; they held on to them, but returned to clarifying the problem rather than pursuing initial solution concepts in depth

• detached themselves during conceptual design stages from fixation on early solution concepts

• produced variants but limited the production and kept an overview by periodically assessing and evaluating in order to reduce the number of possible variants.

The key to successful design therefore seems to be the effective management of the dual exploration of both the 'problem space' and the 'solution space'.

Designing is a form of skilled behaviour. Learning any skill usually relies on controlled practice and the development of techniques. The performance of a skilled practitioner appears to flow seamlessly, adapting the performance to the circumstances without faltering. However, learning is not the same as performing,

and underneath skilled performance lies mastery of technique and procedure.

Engineering Design Methods

Strategies for Product Design

THIRD EDITION

Nigel Cross

The Open University, Mi/ton Keynes, UK

JOHN WILEY & SONS, LTD

Chichester- New York. Weinheim • Brisbane. Singapore. Toronto

Concept Development: The Front-End Process

Because the concept development phase of the development process demands perhaps more coordination among functions than any other, many of the integrative development methods presented in this book are concentrated here. In this section we expand the concept development phase into what we call the front-end process. The front-end process generally contains many interrelated activities, ordered roughly as shown in Exhibit 2-3. Rarely does the entire process proceed in purely sequential fashion, completing each activity before beginning the next. In practice, the front-end activities may be overlapped

in time and iteration is often necessary. The dashed arrows in Exhibit 2-3 reflect the uncertain nature of progress in product development. At almost any stage, new information may become available or results learned which can cause the team to step back to repeat an earlier activity before proceeding. This repetition of nominally complete activities is known as development iteration.

The concept development process includes the following activities:

• Identifying customer needs:

The goal of this activity is to understand customers' needs and to effectively communicate them to the development team. The output of this step is a set of carefully constructed customer need statements, organized in a hierarchical list, with importance weightings for many or all of the needs. A method for this activity is presented in Chapter 4, Identifying Customer Needs.

• Establishing target specifications:

Specifications provide a precise description of what a product has to do. They are the translation of the customer needs into technical terms. Targets for the specifications are set early in the process and represent the hopes of the development team. Later these specifications are refined to be consistent with the constraints imposed by the team's choice of a product concept. The output of this

stage is a list of target specifications. Each specification consists of a metric, and marginal and ideal values for that metric. A method for the specification activity is given in Chapter 5, Product Specifications.

• Concept generation:

The goal of concept generation is to thoroughly explore the space of product concepts that may address the customer needs. Concept generation includes a mix of external search, creative problem solving within the team, and systematic exploration of the various solution fragments the team generates. The result of this activity is usually a set of 10 to 20 concepts, each typically represented by a sketch and brief descriptive text. Chapter 6, Concept Generation, describes this activity in detail.

• Concept selection:

Concept selection is the activity in which various product concepts

are analyzed and sequentially eliminated to identify the most promising concept(s).

The process usually requires several iterations and may initiate additional concept generation

and refinement. A method for this activity is described in Chapter 7, Concept

Selection.

• Concept testing: One or more concepts are then tested to verify that the customer needs have been met, assess the market potential of the product, and identify any shortcomings which must be remedied during further development. If the customer response is poor, the development project may be terminated or some earlier activities may be repeated as necessary. Chapter 8, Concept Testing, explains a method for this

activity.

• Setting final specifications:

The target specifications set earlier in the process are revisited after a concept has been selected and tested. At this point, the team must commit to specific values of the metrics reflecting the constraints inherent in the product concept, limitations identified through technical modeling, and trade-offs between cost and performance.Chapter 5, Product Specifications, explains the details of this activity.

• Project planning:

In this final activity of concept development, the team creates a detailed development schedule, devises a strategy to minimize development time, and identifies the resources required to complete the project. The major results of the front-end activities can be usefully captured in a contract book which contains the

mission statement, the customer needs, the details of the selected concept, the product specifications, the economic analysis of the product, the development schedule, the project staffing, and the budget. The contract book serves to document the agreement (contract) between the team and the senior management of the enterprise. A project planning method is presented in Chapter 16, Managing Projects.

• Economic analysis:

The team, often with the support of a financial analyst, builds an economic model for the new product. This model is used to justify continuation of the overall development program and to resolve specific trade-offs among, for example, development costs and manufacturing costs. Economic analysis is shown as one of the

ongoing activities in the concept development phase. An early economic analysis will almost always be performed before the project even begins, and this analysis is updated as more information becomes available. A method for this activity is presented in Chapter 15, Product Development Economics.

• Benchmarking of competitive products:

An understanding of competitive products is critical to successful positioning of a new product and can provide a rich source of ideas for the product and production process design. Competitive benchmarking is performed in support of many of the front-end activities. Various aspects of competitive benchmarking are presented in Chapters 4-8.

• Modeling and prototyping:

Every stage of the concept development process involves various forms of models and prototypes. These may include, among others: early "proof-of-concept" models, which help the development team to demonstrate feasibility; "form-only" models, which can be shown to customers to evaluate ergonomics and style; spreadsheet models of technical trade-offs; and experimental test models, which can be used to set design parameters for robust performance.

References and Bibliography

Many current resources are available on the Internet via

www.ulrich-eppinger.net

Stage-gate product development processes have been dominant in manufacturing firms

for the past 30 years. Cooper describes the modem stage-gate process and many of its

enabling practices.

Cooper, Robert G., Winning at New Products: Accelerating the Process from Idea to

Launch, third edition, Perseus Books, Cambridge, MA, 2001.

How Designers Think

In an experimental research study, Lawson (1984) compared the ways in which designers (in this case architects) and scientists solved the same problem. The scientists tended to use a strategy of systematically trying to understand the problem, in order to look for underlying rules which would enable them to generate an optimum solution. In contrast, the designers tended to make initial explorations and then suggest a variety of possible solutions until they found one that was good, or at least satisfactory.

The evidence from the experiments suggested that scientists problem-solve by analysis, whereas designers problem-solve by synthesis; scientists use 'problem-focused strategies' and designers use 'solution-focused strategies'.

Some other studies have also suggested that designers tend to use conjectures about solution concepts as the means of developing their understanding of the problem. Darke (1984) found that designers impose a primary generator onto the problem, in order to narrow the search space and generate early solution concepts.

This primary generator is usually based on a tightly-restricted set of constraints or solution possibilities derived from the design problem. Since 'the problem' cannot be fully understood in isolation from consideration of 'the solution', it is natural that solution conjectures should be used as a means of helping to explore and understand the problem formulation. Making sketches of solution concepts is one way that helps the designer to identify their consequences, and to keep the problem exploration going, in what Sch6n (1983) called the 'reflective conversation with the situation' that is characteristic of design thinking.

Drawing and sketching have been used in design for a long time, certainly since long before the Renaissance, but the period since that time has seen a massive growth in the use of drawings, as designed objects have become more complex and more novel. Many of Leonardo da Vinci's drawings of machines and inventions

from the Renaissance period show one of the key aspects of design drawings, in terms of their purpose of communicating to someone else how a new product should be built, and also how it should work. Some of Leonardo's design drawings also show how a drawing can be not only a communication aid, but also a thinking and reasoning aid. For example, Leonardo's sketches for the design of fortifications (Figure 7) show how he used sight-lines and missile trajectories as lines to set up the design of the fortifications, and how his design thinking was assisted by drawing. In such drawings we see how the sketch can help the designer to consider many aspects at once; we see plans, elevations, details, trajectory lines, all being drawn together and thus all being thought about, reasoned about, all together.

Half a millenium later, we still see designers using essentially similar types of sketch to aid their design thinking. The early concept sketches for a house design by the contemporary architect Charles Moore (Figure 8) show similar kinds of representations as those used by Leonardo: plan, elevation and section all being

considered together with considerations of structure and calculations of dimensions and areas.

What might we learn about the nature of design thinking from looking at examples of what designers sketch? One thing that seems to appear is that sketches enable designers to handle different levels of abstraction simultaneously. Clearly this is something important in the design process. We see that designers think about the overall concept and at the same time think about detailed aspects of the implementation of that concept. Obviously not all of the detailed aspects are considered early on, because if they could do that, designers could go straight to the final set of detailed drawings. So they use the concept sketch to identify and then to reflect upon critical details, particular details that they realise might hinder or somehow significantly influence the final implementation of the complete design. This implies that, although there is a hierarchical structure of decisions, from overallconcept to details, designing is not a strictly hierarchical process; in the early stages of design, the designer moves freely between different levels of detail.

The identification of critical details is part of a more general facility that sketches provide, which is that they enable identification and recall of relevant knowledge. As the architect Richard MacCormac has said about designing, 'What you need to know about the problem only becomes apparent as you're trying to solve it.' There is a massive amount of information that may be relevant, not only to all the possible solutions for a

design problem, but simply to any possible solution. Any possible solution in itself creates the unique circumstances in which these large bodies of information interact, probably in unique ways for any one possible solution. So these large amounts of information and knowledge need to be brought into play in a selective way, being selected only when they become relevant, as the designer considers the implications of the solution concept as it develops.

Because the design problem is itself ill-defined and ill-structured,

a key feature of design sketches is that they assist problem structuring through the making of solution attempts. Sketches incorporate not only drawings of tentative solution concepts but also numbers, symbols and text, as the designer relates what he knows of the design problem to what is emerging as a solution. Sketching enables exploration of the problem space and the solution space to proceed together, assisting the designer to converge on a matching problem-solution pair. Problem and solution co-evolve in the design process.

Designers' use of sketches therefore gives us some considerable insight into the nature of design thinking and the resolution of design problems. These problems cannot be stated sufficiently explicitly such that solutions can be derived directly from them. The designer has to take the initiative in finding a problem starting point and suggesting tentative solution areas. Problem and solution are then both developed in parallel, sometimes leading to a creative redefinition of the problem, or to a solution that lies outside the boundaries of what was previously assumed to be possible.

Solution-focused strategies are therefore perhaps the best way of tackling design problems, which are by nature ill-defined. In order to cope with the uncertainty of ill-defined problems, the designer has to have the self-confidence to define, redefine and change the problem as given, in the light of solutions that emerge

in the very process of designing. People who prefer the certainty of structured well-defined problems will never appreciate thedelight of being a designer!

Engineering Design Methods

Strategies for Product Design

THIRD EDITION

Nigel Cross

The Open University, Mi/ton Keynes, UK

JOHN WILEY & SONS, LTD

Chichester- New York. Weinheim • Brisbane. Singapore. Toronto