You are on page 1of 147

(OWDOYOUDESIGN

!#OMPENDIUMOF-ODELS
BY(UGH$UBBERLY
$UBBERLY$ESIGN/FFICE 
(ARRISON3TREET


3AN&RANCISCO

#! 

.

The team building a rocket.Everyone designs. 3 . The teacher arranging desks for a discussion. The entrepreneur planning a business.

Even their actions appear quite different. So do the scales of their projects and the media they use. What’s similar are the processes they follow. 4 . So do their goals. What’s similar is that they are designing.Their results differ.

5 . If we wish to improve our products.Our processes determine the quality of our products. To know what we do and how we do it. To understand it and improve it. we must improve our processes. we must continually redesign not just our products but also the way we design. That’s why we study the design process. To become better designers.

such as the 4Ds (define. They range from short mnemonic devices. I have collected over one-hundred descriptions of design and development processes. 229-step “systematic method for designers. design. How do we design? Why do we do it that way? How do we describe what we do? Why do we talk about it that way? Asking these questions has practical goals: . deploy). But teaching new designers or working with teams on large projects requires us to reflect on our process.defining roles and processes in advance . such as Archer’s 9-phase.setting expectations (reducing uncertainty and fear) . Success depends on: .” Some are synonyms for the same process. others represent differing approaches to design. mechanical engineering.increasing repeatability (enabling improvement) Examing process may not benefit everyone. By presenting these examples. quality management. How do we do better? From this discussion. I hope to foster debate about design and development processes.identifying and fixing broken processes Ad hoc development processes are not efficient and not repeatable. more subtle questions also arise: How do we minimize risk while also maximizing creativity? When must we use a heavy-weight process? And when will a light-weight process suffice? What is the place of interaction design within the larger software development process? What is the place of the software development process within the larger business formation processes? What does it mean to conceive of business formation as a design process? 6 . the costs may not matter. to elaborate schemes. For an individual designer—imagine someone working alone on a poster— focusing on process may hinder more than it helps.Introduction In this book. develop.reducing risk (increasing the probability of success) . but large organizations cannot sustain them.documenting what we actually did . from architecture. At a small scale. and software development. They constantly must be reinvented making improvement nearly impossible. industrial design.

One of my goals is to cast each of these activities as design. Its principles became standard operating procedures in much of the business world. Development of automatic piloting devices and fire-control systems for aiming large guns led to servo-mechanisms and computing devices. operations research.” Today. Horst Rittel. In the 1970s. but so far as I know. and MIT and Berkeley in the US sought to rationalize and systemize the design process. Alexander’s work on design patterns in architecture contributed to thinking on design patterns in software. Software tools makers seek standards around which they can build tools—a new twist on codifying the design process. no one has attempted to bring together work from these three areas. demanded new techniques to deal with increased scale and complexity. cybernetics. many are unaware of much prior art. Even within their own fields. his “belated answer to [IBM Chairman] Tom Watson’s probing question as to why programming is so hard to manage. and software developers appear to be unaware of practices and thinking about process in the other disciplines. designers. one of the roots of artificial intelligence. One of the founders of the design methods movement. Christopher Alexander. In the software world. anticipating the emergence of cybernetics. to show how their processes are similar. Work in the UK. Curious ties exists between the design methods world and the software development world. and to encourage sharing of ideas between the disciplines. 7 . But for the most part. software developers are still actively discussing the question. at Ulm in Germany.Origins The oldest development process model I’ve seen dates from about 1920 and describes how to develop a battleship for the Royal Navy. business managers. becoming enshrined in ISO and six-sigma standards. released in 1964. During the 1950s. Stafford Beer and others applied systems thinking and especially operations research to business problems. Somewhat parallel efforts occurred in the business world. Large engineering projects undertaken during the war and later cold-war projects. Discussions about design and development processes began in earnest shortly after the second world war. Consultants seek to differentiate themselves with proprietary processes. They grew out of military research and development efforts in at least three fields. and large-scale engineering project management. W. which became popular in Japan and something of a fad in the US in the 1980s. The fields overlap. Several designers attempted to codify the design process and present it as a scientific method. which then matured into an academic discipline. such as the Atlas and Titan missile projects. another important figure in the movement. cybernetics. manager of OS/360. From operations research. co-wrote A Pattern Language. published The Mythical Man Month. Fred Brooks. Rittel’s research into IBIS is a precursor of today’s work on design rationale. interest in the development process dates back at least to the IBM System 360. The excitement of these new disciplines and the success of these huge engineering projects captivated many people. Pre-war efforts to make radar an effective part of the British air-defense system led to operations research. Edward Deming examined business processes. academic designers imported both methods and philosophy in what became known as the design methods movement (1962-1972). and large-scale engineering project management. His work led to the quality management movement. developed IBIS (Issues-Based Information System) to support the design process. In 1975.

Measure twice Cut once Ready Aim Fire Lab study Pilot plant Full-scale plant Research Development Manufacturing Sales 8 .

the chemical engineer’s “scale-up” process. 67 Software development Each is a process focused on achieving a goal.Contents The carpenter’s adage. the book is more a reference work than a primer. 136 Chronological list 140 Author list This collection is not exhaustive. I have paired models where I see a connection. 115 Cyclic models Each is an analog of the design process. I also combine design and development into one category. date. These pairings—and the entire structure—are idiosyncratic. because the distinction is without a difference. and author. 132 Complete list of models This book presents many other descriptions of design and development processes. the corporation’s departments— the four phrases on the previous page— have something in common. 11 Introducing process 19 Analysis versus synthesis 29 Academic models 61 Consultant models Each is a sequence of steps. Even so. At the end of the book are indices organized by title. organizing it presents a challenge. 9 . In the body of the book are threads but no strong narrative. Thus. 82 Complex linear models Each suggests iteration and convergence. the captain’s command. I call these descriptions design process models. distinguishing the description from the activity it describes.

its similarity to a “random walk” .its irreducible “black-box” nature  .the importance of iteration .” he said.Design process after Tim Brennan (~1990) At an off-site for Apple Computer’s Creative Services department. Tim Brennan began a presentation of his group’s work by showing this model.”  10 Brennan captures important aspects of the process: . “Somebody calls up with a project. “Here’s how we work. we do some stuff.the potential for play . and the money follows.

11 .Introducing process What is a process? Where does it begin? Where does it end? How much detail is enough? We begin with simple models of the design process and look at how they might be expanded into useful frameworks.

Garbage in. the transformation is reducible to a mathematical function. 0ROCESS /UTPUT . garbage out. Sometimes. It may promote an illusion of linearity and mechanism—of cause and effect. One risk in using this framework is that it neatens a messy world.Process archetype A process must have input and output. (Good in. good out?) In between. Think )NPUT 12 of using Photoshop’s curves function to lighten a photo. something may happen—the process—a transformation.

Processes have a fractal quality. The author chooses where to point the camera—where to begin mapping the process. You can add more detail—dividing phases into steps and steps into sub-steps. almost infinitely. how much detail to include. what to leave out. Processes rarely have fixed beginnings or endings. what to put in. 0ROCESS 0ROCESS )NPUT 0ROCESS /UTPUT 13 . increasing or decreasing abstraction or specificity. But documenting a process is like taking a photograph. You can zoom in or out. where to end.On the infinite expandability of process models An important step in managing any process is documenting it. That truism implies a process merely needs recording. You can almost always add steps upstream or downstream.

” 0ROCESS )NPUT 14 !NALYSIS 3YNTHESIS /UTPUT .” write Koberg and Bagnall. “If you’ll try it yourself. when consciously solving problems or when creatively involved in the activity of design. two basic stages are necessary.. we’re sure that the two “basic” stages of analysis and synthesis will emerge. we reassemble the situation based on our understanding of improvements discovered in our study (Synthesis).e. i. Synthesis after Koberg and Bagnall (1972) “When comparing many different problem-solving approaches it becomes necessary to search for their basic abstractions or common-denominators.Design process archetype: Analysis. First. we break the situation or whole problem into parts for examination (Analysis) and Second.

Foreman introduces the idea of needs.EEDS 3OLUTION &ACTORS2ELATIONSHIPS0RINCIPLES&ORMS 15 . 0ROBLEM %STABLISHING. This stance is typical of the first generation of the design methods movement.EEDS 3ATISFYING. like Koberg and Bagnall.Problem. casts design as problemsolving. He also begins to sub-divide the process. Solution after JJ Foreman (1967) Foreman.

SYNTHESIS ANALYSIS DEFINITION SYNTHESIS ANALYZE DEFINE IDEATE SELECT IMPLEMENT ANALYZE DEFINE IDEATE SELECT IMPLEMENT EVALUATE . select. Koberg and Bagnall (who taught in the College of Environmental Design at Cal Poly in San Luis Obisbo) expand the archtypal two-step process to three.” while the analysis phase remains intact. The synthesis phase becomes “ideate.” Within the book’s “problem-solving” frame. definition becomes problem definition.Expanding the two-step process after Don Koberg and Jim Bagnall (1972) In their classic book. and finally to seven steps. and they never follow up on the idea of definition as concept or parti. Finally. They note “that ‘out of Analysis’ we derive an understanding or concept that is then followed as a guideline in the rebuild- ANALYSIS ACCEPT 16 ing or Synthesis stage. then five. they add a new phase at the beginning and another at the end. implement. The Universal Traveler.

ANGUAGE .OMENCLATURE $ESIGN )MPLEMENTATION %VALUATE 0LAN $ESIGN 3TATE 3YNTHESIS %VALUATE $ESIGN 3PECIALISTS %NGINEERING 3TYLING %RGONOMICS !DVERTISING "ROCHURES #ATALOGS $IRECT-AIL 'RAPHIC&ORMATS )DENTITY%LEMENTS #ONTROL5SER-ANUALS . Grandiose Theory of Design. Doblin’s third and fourth processes correspond to Alexander’s third type of design.OMENCLATURE 0ACKAGING 0OINT /F 0URCHASE 4RADESHOWS %TC )MPLEMENT 3TATE $EPARTMENTS %NGINEERING 3TYLING #ATALOG 0ACKAGING !DVERTISING 0UBLIC2ELATIONS 4RADE3HOWS 5SER-ANUALS $IRECT-AIL #ORPORATE)TEMS %TC 17 .Matching process to project complexity after Jay Doblin (1987) In his article.) $IRECT$ESIGN 3TATE 0ROCESS 3TATE !NALYSIS 'ENESIS )NDIRECT$ESIGN 3TATE 3YNTHESIS !NALYSIS 3TATE .” Doblin presents a similar series of expanding processes. see the next page. “A Short. mediated design (my title). (For more on Alexander’s model.IST 3TATE 'ENESIS -ATRIX 3EMILATTICE 3CHEMATIC !NALYSIS 3TATE 3YNTHESIS -ECHANICAL $RAWING -ODEL 'ENESIS )NFORMATION 'ATHERING )NFORMATION 3TRUCTURING 0ROCESSES )NTERVIEWS 0RIMARY 3ECONDARY $ATA3EARCHES &IELD2ESEARCH 3UPERSETS #OMPETITION #HANNELS 4ECHNOLOGY #ONSUMERS 0LAN )SSUES 0OSITION #ONTENT . Dobin’s notion of direct and indirect design echos Alexander’s (1962) model of unselfconscious and self-conscious design.

a craftsman works directly and unselfconsciously through “a complex two-directional interaction between the context C1 and the form F1.” In the second. In the first.” In the third. the designer also works self-consciously. &ORM # & !CTUALWORLD # & -ENTALPICTURE # & &ORMALPICTUREOF MENTALPICTURE . in the world itself. on the other. designing is separate from making.Unself-conscious and self-conscious design after Christopher Alexander (1962) In Notes on the Synthesis of Form. Form is shaped “by a conceptual picture of the context which  5NSELFCONSCIOUS #ONTEXT &ORM #  !CTUALWORLD &ORM # & !CTUALWORLD # & -ENTALPICTURE -EDIATED #ONTEXT 18 & 3ELFCONSCIOUS #ONTEXT  the designer has learned and invented. this time abstracting and formalizing representations of the problem and solution so that he and others may inspect and modify them. on the one hand. Alexander (1962) described three situations in which designing may take place. and ideas and diagrams and drawings which stand for forms.

Jones proposed this procedure as a basic framework for design processes. While attention often focuses on the analysis-synthesis dichotomy. we might also consider other dichotomies: serialist versus holist linear versus lateral top-down versus bottom-up agile versus heavy-weight pliant versus rigid 19 .Analysis synthesis evaluation In 1962. But what relationship do the steps have? Are they discrete? Sequential? Overlapping? This section compares several models.

Oscillation We may view the design process as an oscillation of the designer’s attention between analysis and synthesis. Do wave-length and amplitude remain constant? Do they vary over time? What are the beginning and ending conditions? !NALYSIS )NPUT /UTPUT 3YNTHESIS 20 .

” 3CHEMATIC 0ROGRAM They note.” They describe programming as “problem seeking” and design as “problem solving. “[Programming is] a process leading to the statement of an architectural problem and the requirements to be met in offering a solution. Design IS synthesis. Parshall (1969) This model comes from architecture. where programming refers not to computers but to a phase of planning that precedes design of a building.Programming and designing after William M. Pena and Steven A.” Pena and Parshall recommend “a distinct separation of programming and design.” “The separation of the two is imperative and prevents trial-and-error design alternatives. “Programming IS analysis. Pena and Parshall quote Webster.” 0ROGRAM $EVELOPMENT 3CHEMATIC $ESIGN $ESIGN $EVELOPMENT 0ROGRAMMINGCONCERNSFIVESTEPS %STABLISH'OALS 7HATDOESTHECLIENTWANTTOACHIEVE.

AND7HY #OLLECTANDANALYZE&ACTS 7HATDOWEKNOW7HATISGIVEN 5NCOVERANDTEST#ONCEPTS (OWDOESTHECLIENTWANTTOACHIEVETHEGOALS $ETERMINE.EEDS (OWMUCHMONEYANDSPACE7HATLEVELOFQUALITY 3TATETHE0ROBLEM 7HATARETHESIGNIFICANTCONDITIONSAFFECTINGTHEDESIGNOFTHEBUILDING 7HATARETHEGENERALDIRECTIONSTHEDESIGNSHOULDTAKE 21 .

solving each sub-piece. Analyzing a problem leads to agreement—to definition—a convergent process. At that point. the “miracle” of transformation occurs in which the solution concept arises. Alexander (1962) and other designers have described analysis as a process of breaking a problem into pieces—of “decomposing” it.) 3YNTHESIS )NPUT /UTPUT "REAKING INTOPARTS #ONVERGE 22 2EASSEMBLING INANEWWAY 4RANSFORM $IVERGE . !NALYSIS We may just as easily describe the process by reversing the sequence (narrowing down. This decomposition-recombination process also diverges and then converges. Some (Souza) converge on a solution. and finally knitting all the pieces back together— “recombining” the pieces. Synthesis follows as re-ordering the pieces based on dependencies. expanding out). hopefully. the designer elaborates that concept in greater and greater detail—a divergent process. Then. we see this question arise again in the section on spiral models. suggesting the accumulation of detail. Later. Others (Boehm) diverge from a center.Diverge / Converge vs Narrow / Expand Often designers describe themselves as creating many options (diverging) and then narrowing down their options (converging). (See pages 122-125.

see page 32.” “This kind of procedure has been criticized in the design world because it seems to be based on a problem-focused.Decomposition / recombination after VDI 2221 (from Cross 1990) VDI 2221 mirrors Alexander’s decomposition-recombination process.) /VERALLPROBLEM 3UB PROBLEMS )NDIVIDUALPROBLEMS )NDIVIDUALSOLUTIONS 3UB SOLUTIONS /VERALLSOLUTION 23 . then breaking this into subproblems. Cross wrote.” (For another view of VDI 2221. It therefore runs counter to the designer’s traditional ways of thinking. finding suitable sub-solutions and combining these into an overall solution. “The VDI Guideline follows a general systemic procedure of first analyzing and understanding the problem as fully as possible. rather than a solution-focused approach.

Dynamics of divergence and convergence
after Bela H. Banathy (1996)
Banathy’s model illustrates the iterative nature of the design
process, repeating the process of divergence and convergence, analysis and sysnthesis.
In Banathy’s view, “We first diverge as we consider a number
of inquiry boundaries, a number of major design options, and
sets of core values and core ideas. Then we converge,

4RANSCEND%NVISION

4RANSFORM"Y$ESIGN

!LTERNATIVE)MAGES

!LTERNATIVE3OLUTIONS
4HE)MAGE
OFTHE&UTURE
3YSTEM

'ENESIS

$IVERGENCE

24

as we make choices and create an image of the future
system. The same type of divergence-convergence operates
in the design solution space. For each of the substantive
design domains (core definition, specifications, functions,
enabling systems, systemic environment) we first diverge
as we create a number of alternatives for each, and then
converge as we evaluate the alternatives and select the most
promising and most desirable alternative.”

#ONVERGENCE

$IVERGENCE

4HE-ODELOFTHE
&URTURE3YSTEM

#ONVERGENCE

Overall, the design process must converge
after Nigel Cross (2000)
Cross notes, “Normally, the overall aim of a design strategy
will be to converge on a final, evaluated and detailed design
proposal, but within the process of reaching that final design
there will be times when it will be appropriate and necessary
to diverge, to widen the search or to seek new ideas and
starting points.

The overall process is therefore convergent, but it will contain
periods of deliberate divergence.”
Banathy’s and Cross’s models suggest cycles and are similar
to the iterative process of Marcus and Maver (see page 45)
and to the spirals of Boehm and others (see pages 122-125).

4RACKOF
DESIGNERS
ATTENTION

3OLUTION

$IVERGENCE

#ONVERGENCE

$IVERGENCE

#ONVERGENCE

25

Gradual shift of focus from analysis to synthesis
after Bill Newkirk (1981)
Bill Newkirk first taught me that synthesis begins at the
very beginning of a design project. Koberg and Bagnall
(1972) suggested that both analysis and synthesis continue
throughout a project. Designers may begin by focusing on
analysis and gradually shift their focus to synthesis.
Lawson (1990) notes, “Most of the maps of the design
process which we have looked at seem to resemble more
closely the non-designer, scientist approach than that of the

architects: first analysis then synthesis. For the designers it
seems, analysis, or understanding the problem is much more
integrated with synthesis, or generating a solution.” He reports studies by Eastman (1970) and Akin (1986) confirming
this view. “Akin actually found that his designers were constantly both generating new goals and redefining constraints.
Thus, for Akin, analysis is a part of all phases of design and
synthesis is found very early in the process.”

!NALYSIS
)NPUT

/UTPUT
3YNTHESIS

26

In this model.) “Problem understanding and problem resolution are concomitant to each other. most people agree that a solution is inherent in a problem.Problem to solution: sequence. we’ve defined or at least outlined the solution. Having defined a problem.” Attempting to solve a problem (prototyping) may even improve our understanding of a problem—and thus change our definition. particularly in the early phases of the design methods movement. parallel process or loop? Pena and Parshall (1969). On the other hand. Briggs and Havlick (1976). and others.” (Italics are theirs. “The information needed to understand the problem depends upon one’s idea for solving it. Rittel and Webber (1973) note. 0ROBLEM 3OLUTION VS 0ROBLEM 3OLUTION VS 0ROBLEM 3OLUTION 27 . described problem solving as a sequential activity. we must define a problem before we can solve it.

IFTFOOT 2IGHTFOOT 28 .OWERFOOT .IFTFOOT -OVELEG .OWERFOOT -OVELEG . .Walking process after Lawson (1980) Bryan Lawson offered this map “with apologies to those design methodologists who like maps!” He notes that many models of the design process are “theoretical and prescriptive” rather than descriptions of actual behavior.EFTFOOT .

29 . and architecture have developed models of the design process to help their students learn to design. engineering.Academic models Many teachers in the design fields.

constraints and criteria of the design brief. ready for manufacture.” Cross’s model includes communication as a final stage.Four stage design process after Nigel Cross (2000) Writing from an engineering perspective. the design proposal is subject to evaluation against the goals. The end-point of the process is the communication of a design. (See page 98. Prior to this. usually after some initial exploration of the ill-defined problem space.) %XPLORATION 'ENERATION %VALUATION #OMMUNICATION 30 . Archer (1963) may have been the first to include communication as an explicit stage in a design process model. The proposal itself arises from the generation of a concept by the designer. based on the essential activities that the designer performs. Cross developed this “simple descriptive model of the design process.

Engineering design process
after Michael J. French (1985)

.EED

!NALYSISOF0ROBLEM

&EEDBACK

3TATEMENT
OF0ROBLEM

#ONCEPTUAL$ESIGN

3ELECTED
3CHEMES

%MBODIMENTOF3CHEMES

$ETAILING

French also wrote from an engineering perspective. He suggested, “The analysis of the problem is a small but important
part of the overall process. The output is a statement of the
problem, and this can have three elements:
- a statement of the design problem proper
- limitations placed up the solution,
e.g. codes of practice, statutory requirements, customers’
standards, date of completions
- the criterion of excellence to be worked to.”

The conceptual design phase “takes the statement of the
problem and generates broad solutions to it in the form of
schemes. It is the phase that makes the greatest demands
on the designer, and where there is the most scope for striking improvements. It is the phase where engineering science,
practical knowledge, production methods and commercial
aspects need to be brought together . . .”

In the third phase, “schemes are worked up in greater detail
and, if there is more than one, a final choice between them
is made. The end product is usually a set of general arrangement drawings. There is (or should be) a great deal of
feedback from this phase to the conceptual design phase.
In the detailing phase, “a very large number of small but essential points remain to be decided.”

7ORKING
$RAWINGS

ETC

31

System approach to the design of technical systems and products
after Verein Deutscher Ingenieure (1987)
VDI stands for Verein Deutscher Ingenieure, the professional
engineering society of Germany. Their guideline 2221 suggests, “The design process, as part of product creation, is
subdivided into general working stages, making the design
approach transparent, rational and independent of a specific
branch of industry.”

The full process contains much more detail than the diagram
below shows. In practice, the process is less linear than the
diagram implies. “It is important to note that the stages do
not necessarily follow rigidly one after the other. They are
often carried out iteratively, returning to preceding ones, thus
achieving a step-by-step optimization.”

3TAGES

2ESULTS

4ASK 

#LARIFYDEFINETHETASK
3PECIFICATION 
$ETERMINEFUNCTIONSTHEIRSTRUCTURES
&UNCTIONSTRUCTURE 
3EARCHFORSOLUTIONPRINCIPLESTHEIRCOMBINATIONS
0RINCIPLESOLUTION 
$IVIDEINTOREALIZABLEMODULES
-ODULESTRUCTURE 
$EVELOPLAYOUTSOFKEYMODULES
0RELIMINARYLAYOUTS 
#OMPLETEOVERALLLAYOUT
$EFINITIVELAYOUT 
0REPARINGPRODUCTIONOPERATINGINSTRUCTIONS
0RODUCTDOCUMENTS
4ASK

32

Design process after Gerhard Pahl and Wolfgang Beitz (1984) Cross recommends this model as “reasonably comprehensive” but not obscuring “the general structure of the design process by swamping it in the fine detail of the numerous tasks and activities that are necessary in all practical design work. (See page 98.” He seems to refer to Archer’s “Systematic method for designers”.) 4ASK #LARIFICATION OFTHETASK #LARIFYTHETASK %LABORATETHESPECIFICATION #ONCEPTUALDESIGN )DENTIFYESSENTIALPROBLEMS %STABLISHFUNCTIONSTRUCTURES 3EARCHFORSOLUTIONPRINCIPLES #OMBINEANDFIRMUPINTOCONCEPTUALVARIANTS %VALUATEAGAINSTTECHNICALANDECONOMICALCRITERIA 0RELIMINARYLAYOUT /PTIMIZEANDCOMPLETEFORMDESIGNS #HECKFORERRORSANDCOSTEFFECTIVENESS 0REPARETHEPRELIMINARYPARTSLISTANDPRODUCTIONDOCUMENTS /PTIMIZATIONOFTHELAYOUTANDFORMS $EVELOPPRELIMINARYLAYOUTSANDFORMDESIGNS 3ELECTBESTPRELIMINARYLAYOUTS 2EFINEANDEVALUATEAGAINSTTECHNICALANDECONOMICCRITERIA %MBODIMENTDESIGN #ONCEPT 5PGRADEANDIMPROVE $EFINITIVELAYOUT &INALIZEDETAILS #OMPLETEDETAILDRAWINGSANDPRODUCTIONDOCUMENTS #HECKALLDOCUMENTS $ETAILDESIGN )NFORMATIONADAPTTHESPECIFICATION /PTIMIZATIONOFTHEPRINCIPLE 3PECIFICATION $OCUMENTATION 3OLUTION 33 .

study it. though not necessarily in that order. assimilation is “The accumulation and ordering of general information specifically related to the problem in hand. The investigation of possible solutions or means of solution.” General study is “The investigation of the nature of the problem. devise a solution and draw it.Architect’s plan of work (schematic) after the RIBA Handbook (1965) Lawson presents this model from the RIBA (Royal Institute of British Architects) practice and management handbook. . “it is hardly a map at all. . all this map does is to tell us that designers have to gather information about a problem.” Lawson is critical. In short.” Development is “refinement of one or more of the tentative solutions isolated during phase 2. According to the handbook. .” !SSIMILATION 34 'ENERALSTUDY Communication involves describing “one or more potential solutions to people inside or outside the design team.” $EVELOPMENT #OMMUNICATION .

(detailed) after the RIBA Handbook (1965) The handbook also contains another.Architect’s plan of work. In the detailed description of each section the Plan of Work also describes what each member of the design team (quantity surveyor. and how he will relate to the architect. engineers etc) will do. .” "RIEFING )NCEPTION &EASIBILITY 3KETCHPLANS /UTLINEPROPOSALS 3CHEMEDESIGN 7ORKINGDRAWINGS $ETAILDESIGN 0RODUCTIONINFORMATION "ILLSOFQUANTITIES 4ENDERACTION 3ITEOPERATIONS 0ROJECTPLANNING /PERATIONSONSITE #OMPLETION &EED BACK 35 . and the architect what he must do rather than how it is done. So the Plan of Work may also seen as part of a business transaction. more detailed plan of work occupying 27 pages. . it tells the client what he will get. Lawson criticizes this model as “a description not of the process but of the products of that process. . This further reveals the Plan of Work to be part of the architectural profession’s propaganda exercise to stake a claim as leader of the multi-disciplinary building design team. It’s also worth noting that the stages in the Plan of Work are closely related to the stages of fee payment in the Conditions of Engagement for Architects. with the architect clearly portrayed as the manager and leader of this team. The 12 main stages are described below.

Maldonado and Bonsiepe (1964) also mention Polya in their article “Science and Design. In it. Systemic method for designers. George Polya wrote How to Solve It. he describes a process for solving math problems. as may be seen in the “scientific problem solving process” described on the following page. Many in the design methods movement seem to have been familiar with Polya’s book. Likewise. Bruce Archer (1963-1964) men- tions Polya in his booklet. an excellent little book for students and teachers of mathematics.  5NDERSTANDINGTHEPROBLEM 7HATISTHEUNKNOWN 7HATARETHEDATA 7HATISTHECONDITION $RAWAFIGURE )NTRODUCESUITABLENOTATION 3EPARATETHEVARIOUSPARTSOFTHECONDITION #ANYOUWRITETHEMDOWN  $EVISINGAPLAN &INDTHECONNECTIONBETWEENTHEDATAANDTHEUNKNOWN $OYOUKNOWARELATEDPROBLEM .OOKINGBACK #HECKTHERESULT #ANYOUDERIVETHERESULTDIFFERENTLY #ANYOUUSETHERESULT.OOKATTHEUNKNOWN (EREISAPROBLEMRELATEDTOYOURSANDSOLVEDBEFORE #OULDYOUUSEIT #OULDYOURESTATETHEPROBLEM #OULDYOURESTATEITSTILLDIFFERENTLY 'OBACKTODEFINITIONS 9OUSHOULDOBTAINEVENTUALLYAPLANOFTHESOLUTION  #ARRYINGOUTTHEPLAN #HECKEACHSTEP #ANYOUSEECLEARLYTHATTHESTEPISCORRECT #ANYOUPROVETHATITISCORRECT  .” Thus Polya seems to have influenced the teaching of architecture.Problem solving process after George Polya (1945) In 1945. though one might apply his process more generally.

ORTHEMETHOD.

FORSOMEOTHERPROBLEM 36 .

. Briggs and Havlick shared the early movement’s desire to cast design as a science.” 5NFULFILLEDNEEDANDUNSATISFIEDNEED 0ROBLEMSTATEMENT "ACKGROUNDSTATEMENT A"ACKGROUNDRESEARCH )MPORTANCESTATEMENT /BJECTIVE A!LTERNATIVEHYPOTHESIS 4HEDELINEATIONOFAMALFUNCTIONINTHEHUMANENVIRONMENTWHICH WASCREATEDBYTHEINABILITYTOPERFORMANEEDEDHUMANACTIVITY 4HEINVESTIGATIONINTOBACKGROUNDRESEARCHWHICHANSWERS THEWHO. . and precise approach to the solution of man’s environmental malfunctions. The college’s name implies links to environmental design faculties at Berkeley. and Ulm and thus to the design methods movement. They write. San Luis Obispo. . “the role of the environmental designer is to solve human environmental problems by the creation and implementation of optimal physical form. [We have] borrowed the scientific method from the traditional sciences and adapted it for the development of optimal solutions. systematic. Havlick (1976) Briggs and Havlick used this model for teaching design to undergraduates at the University of Colorado’s College of Environmental Design. it has been utilized to insure an analytic.Scientific problem solving process after Cal Briggs and Spencer W. The scientific method is the central process. Termed the scientific problem solving design process.

WHAT.

WHERE.

HOW.

WHEN.

ANDWHY OFTHEPROBLEM4HISSTAGEALSOEXPLORES A PREVIOUSLYATTEMPTEDPHYSICALFORMSOLUTIONSAND B ALLCONTRIBUTINGCAUSESTOTHEPROBLEM !STATEMENTWHICHDEMONSTRATESTHESIGNIFICANCEOFTHE ENVIRONMENTALMALFUNCTIONINTERMSOFCRITICALHUMANNEEDSAND WHATCONSEQUENCESMIGHTRESULTIFTHEPROBLEMWASNOTSOLVED !STATEMENTOFTHEINTENDEDGOALSTHATWILLBEFULFILLEDBYTHE SOLUTIONOFTHEPROBLEM !RESEARCHEDASSUMPTIONWHICHASSERTSTHATIFACERTAINPHYSICAL FORMAPPROACHISTAKEN.

CERTAINRESULTSWILLENSUETHESATISFACTIONOF UNMETNEED  B3ELECTEDHYPOTHESIS 0ARAMETERDEVELOPMENT A?????????????????????? B?????????????????????? C?????????????????????? D?????????????????????? 0ARAMETERSYNTHESIS 4HEDEFINITIONANDORDERINGOFALLDESIGNCONSIDERATIONS NECESSARYFORTHEDEVELOPMENTOFANOPTIMALSOLUTIONTOASTATED PROBLEMIE.

LEGALITY.

ECONOMICFEASIBILITY.

ECOLOGICALIMPLICATIONS.

SHAPE.

COLOR.

WEIGHT.

ETC 0ARAMETERSORVARIABLESARETHEFORM DETERMININGCOMPONENTSWHICHCOMPRISETHEPROPOSED HYPOTHESIS 4HESYSTEMATICOPTIMIZINGANDCOMPROMISINGOFORDEREDDESIGN PARAMETERSINTOARESULTANTPHYSICALFORMSOLUTIONWHICHOPTIMALLY ACHIEVESTHESTATEDOBJECTIVES)TSHOULDBESTATEDHERETHEhPHYS ICALFORMvCOULDBETHEWRITINGOFENVIRONMENTALLEGISLATION.

REDESIGN ORCREATIONOFAPRODUCT.

ORTHEFORMULATIONOFHOWASERVICECOULD BEBESTPROVIDED 3OLUTIONEVALUATION 4HEIMPLEMENTATIONANDTESTINGOFTHEGENERATEDDESIGNSOLUTION TODELINEATETHENEEDFORANYFURTHERMODIFICATIONSORRECYCLINGBACK THROUGHTHESCIENTIFICPROBLEMSOLVINGPROCESS4HISEVALUATION PROCESSPRECEDESIMPLEMENTATIONOFASOLUTION &ULFILLEDACTIVITYANDSATISFIEDNEED 4HEARROWSINTHEFLOWCHARTREVEALANIMPORTANTDIMENSIONOFTHE PROBLEMSOLVINGDESIGNPROCESS!TEVERYPROCEDURALSTAGE.

THE %NVIRONMENTAL$ESIGNERISABLETORECYCLEBACKTHROUGHTHEPROCESS ONEORMORESTAGESIFMODIFICATIONSARENECESSARYTOIMPROVETHE EVOLUTIONOFTHEFINALDESIGN 37 .

observation.generate a Hypothesis about a phenomenon . conclusion — an easy way to remember an outline of the scientific method. experiment. It approximates the process with these steps: . a model of the scientific method THEOC is an acronym for theory. .within a framework of a Theory . hypothesis.repeat as necessary 4HEORY (YPOTHESIS %XPERIMENT /BSERVATION #ONCLUSION 38 .Observe and record the results .THEOC.form a conclusion based on the relation of the observations to the hypothesis.run an Experiment to test the hypothesis .

” #63% “What do we explain? We explain our experiences. While the traditional pose of scientific objectivity may be fine in some areas. you can’t be objective. L’Amoreaux points out that “Maturana shows you not only don’t need objectivity to do science. Maturana writes.” 3CIENTIFICMETHOD  4HEDESCRIPTION OFWHATANOBSERVERSHOULDDO TOLIVETHEEXPERIENCE TOBEEXPLAINED  4HEDESCRIPTION OFTHEPHENOMENON TOBEEXPLAINED  4HEPROPOSITION OFAGENERATIVEMECHANISM  4HEPROPOSITION OFTHEHYPOTHESISORMODEL OFTHEREALITY THATUNDERLIESTHEPHENOMENON BEINGEXPLAINED  4HEDEDUCTION FROMALLTHEEXPERIENTIALCOHERENCES OFTHEOBSERVERIMPLIEDIN OFOTHERPOSSIBLEEXPERIENCES THATHEORSHEMAYLIVE ANDOFWHATHEORSHESHOULDDO TOHAVETHEM  4HEPREDICTIONOFOTHERPHENOMENA ASSUMINGTHATISVALID TOGETHERWITHTHEPROPOSITION OFWHATTODO TOSHOWTHEM  $OINGWHATHASBEENDEDUCTEDIN. “scientific explanations are not valid in themselves. . . We explain our living with the coherences of our living. we cannot understand perception and the nervous system within that framework.Criteria of Validation of Scientific Explanations (CVSE) after Humberto Maturana (1987) Claudia L’Amoreaux contributed the models below comparing Maturana’s view of scientific explanation with his view of the scientific method. explanations are interpersonal relations.” Nor can we understand design that way. . Explanations are not so in themselves.” “What do we explain? We explain our experiences with the coherences of our experiences. they are generative mechanisms accepted as valid as long as the criterion of validation in which they are embedded is fulfilled.

ANDIFTHEOBSERVERLIVESTHEEXPERIENCESTHEREDEDUCED.

THENISACCEPTEDASSCIENTIFICEXPLANATION  $OINGWHATHASBEENDEDUCEDIN.

ANDIFTHEPREDICTEDNEWPHENOMENAOCCUR.

THEHYPOTHESISORMODELPRESENTEDIN ISCONFIRMED 39 .

Some. The assertion that design is a science was most powerfully articulated by Carnegie vv Herbert Simon (1969) in The Sciences of the Artificial. Simon’s view is no longer fashionable. and chemists. Most academic designers remain within Schools of Art.Comprehensive anticipatory design science after Buckminster Fuller (1950?) According to the Buckminster Fuller Institute. industrial designers. which he taught at MIT in 1956 as part of the Creative Engineering Laboratory. Fuller began formulating his theory of a comprehensive anticipatory design science as early as 1927. )NVENTORY ALTERNATIVES $EVELOPARTIFACTS #OMMUNICATE PLAN #HOOSE PROBLEM SITUATION $EFINE PROBLEMS $EFINE PREFERED STATE $ESCRIBE PRESENT STATE $ESIGN PREFERED SYSTEM $EVELOP EVALUATION CRITERIA 40 $EVELOP IMPLEMENTATION STRATEGIES $OCUMENT PROCESS )NITIATELARGER PLANNINGPROCESS . Students included engineers. such as Banathy (1996). he outlined a course. materials scientists. representing research and development corporations from across the country. In 1950. suggest design is a third way of knowing distinct from the humanities and the sciences.

Design process and practice after Richard Buchannan (1997) Buchannan has a PhD in rhetoric and has taught design for many years—also at Carnegie Mellon. scenario building. he provides a practical model for students. Note the repetition of research. and visualization in the three middle phases. Below.      0HASES /BJECTIVES 6ISION STRATEGY $ISCOVERGOVERNINGIDEASANDCIRCUMSTANCES IDENTIFYORGANIZATIONALVISIONSTRATEGY PREPAREDESIGNBRIEF "RIEF )NDENTIFICATIONANDSELECTION IDENTIFYANDSELECTTHEINITIALISSUES.

FUNCTION.

ANDFEATURESTOBEADDRESSED #ONCEPTION 2EALIZATION $ELIVERY )NVENTIONANDJUDGMENT INVENTPOSSIBLECONCEPTSOFTHEPRODUCT JUDGEWHICHCONCEPTSAREVIABLE $ISPOSITIONANDEVALUATION PLANANDMAKEPROTOTYPEOFTHEPRODUCT EVALUATEBYUSERTESTING 0RESENTATION PRESENTPROTOTYPE.

DOCUMENTATION.

ANDPRODUCTIONSPECIFICATIONS #HARACTERISTICACTIVITIES $IALOGUE 3TRATEGICPLANNING 3TRATEGICDESIGNPLANNING.

WITHVISION /FTHEPRODUCTDEVELOPMENTPROCESS $ISCUSSION 2ESEARCH 3CENARIOBUILDING 6ISUALIZATION 0ROJECTPLANNING $OCUMENTATION 2ESEARCH "RAINSTORMING 3CENARIOBUILDING %ARLYFREQUENTVISUALIZATION $OCUMENTATION 2ESEARCH 3CENARIOBUILDINGREFINEMENT 6ISUALIZATION #ONSTRUCTION $OCUMENTATION /BSERVATION.

ETC 3CRIBING #ONCEPTMAPPING /BSERVATION #ONCEPTMAPPING 3KETCHING -ODELLING 0ROTOTYPE %VALUATE 0ROTOTYPE %VALUATE 0ROTOTYPE %VALUATE /RALPRESENTATION 7RITTENPRESENTATION 0ROTOTYPEDEMONSTRATION 41 .

an architect. As we have seen. days or even years.” . design problems are rarely initially entirely clear and much effort has to be expended in understanding them thoroughly. Other writers suggest that by withdrawing from the problem the thinker is then able to return with fresh attitudes and approaches which may prove more productive than continuing his initial thought development. compares the creative process to the design process. Some authors (MacKinnon 1976) explain this as unconscious cerebration during the incubation period. This period may itself last for many hours. “The period of ‘first insight’ (Kneller 1965) simply involves the recognition that a problem exists and a commitment is made to solving it. The thinker is unwittingly reorganizing and re-examining all his previous deliberate thoughts. (MacKinnon 1976) As with our maps of the design process it is recognized that there may be much coming and going between these first two phases as the problem is reformulated or even completely redefined.OCONSCIOUSEFFORT )LLUMINATION 3UDDENEMERGENCEOFIDEA 6ERIFICATION #ONSCIOUSDEVELOPMENT Yet all these writers emphasize here that this period of preparation involves deliberate hard work and is then frequently followed by a period of ‘incubation’ which involves no apparent effort. )NCUBATION 42 . The next phase of ‘preparation’ involves much conscious effort to develop an idea for solving the problem. The formulation of the problem may often be a critical phase in design situations. Once the idea has emerged all writers agree upon a final period of conscious verification in which the outline idea is tested and developed.Creative process after Bryan Lawson (1980) &IRSTINSIGHT &ORMULATIONOFPROBLEM 0REPARATION #ONSCIOUSATTEMPTATSOLUTION Lawson. but which is often terminated by the emergence of an idea (‘illumination’).

Primary generator after Jane Darke (1978) Lawson (1990) reports on Darke’s finding that at least some architects begin the design process with a simple idea or “primary generator”. “Thus.” 'ENERATOR #ONJECTURE Lawson suggests Darke’s model was anticipated by Hiller et al (1972). and the designer is then able rapidly to construct and analyze a scheme. develop a crude design on this basis and examine it to see what else you can discover about the problem.” Note the similarity to “hacking” in software development. Lawson summarizes Darke’s model. Here again. !NALYSIS 43 . a very simple idea is used to narrow down the range of possible solutions. relation between analysis and synthesis. first decide what you think might be an important aspect of the problem. “In plain language. we see this very close. perhaps inseparable.

Lawson suggests a looping relationship between brief and analysis. “. you have to "RIEFING 44 !NALYSIS start designing and briefing simultaneously. and everything you do modifies your idea of what is possible . you can’t start with a brief and [then] design. than by trying to draw up an abstract comprehensive performance specification.Design process after Jane Darke (1978) Based on Darke’s research. . .” 3YNTHESIS %VALUATION . because these two activities are completely interrelated. a brief comes about through essentially an ongoing relationship between what is possible in architecture and what you want to do. see page 26. One of the architects Darke interviewed described the process.” (For another take on this idea. . .) Lawson points out that this may be one reason “clients often seem to find it easier to communicate their wishes by reacting to and criticizing a proposed design.

Design process
after Thomas A. Marcus (1969) and Thomas W Maver (1970)
Typically, in design process models evaluation follows
analysis and synthesis. Marcus and Maver substitute decision, casting the design process as a series of decisions.
They layer these decisions in three levels, outline proposals,
scheme design, and detail design. This iterative structure is
similar to that proposed by Banathy (1996) and Cross (2000).

!NALYSIS

(See pages 24 and 25.) It’s also similar to Boehm’s spiral.
(See page 122.) The three-level, four-step structure of this
model anticipates the structure of the AIGA model on the
next spread.

3YNTHESIS

!PPRAISAL

$ECISION

3YNTHESIS

!PPRAISAL

$ECISION

3YNTHESIS

!PPRAISAL

$ECISION

/UTLINEPROPOSAL

!NALYSIS

3CHEMEDESIGN

!NALYSIS

$ETAILDESIGN

45

AIGA

46

Process of designing solutions
after Clement Mok and Keith Yamashita (2003)
American Institute of Graphic Arts (AIGA) president Clement
Mok enlisted Keith Yamashita to help the organization help
graphic designers explain what they do. Mok and Yamashita
produced a cheery little book describing a 12-step process
in which designers are “catalysts” for change.

The book casts design in terms of problem solving,
yet it also promises innovation.

$EFININGTHEPROBLEM    

$EFININGTHE
PROBLEM

%NVISIONINGTHE
DESIREDENDSTATE 
KNOWINGWHAT
VICTORYLOOKSLIKE

$EFININGTHE
APPROACHBYWHICH
VICTORYCAN
BEACHIEVED

)NCITINGSUPPORT
ANDTHENACTION    

3EEKINGINSIGHT
TOINFORM
THEPROTOTYPING
OFTHESOLUTION

0ROTOTYPING
POTENTIAL
SOLUTIONS

$ELINEATINGTHE
TOUGHCHOICES

%NABLINGTHETEAM
TOWORK
ASATEAM    

#HOOSINGTHE
BESTSOLUTION
THENACTIVATINGIT

-AKINGSURE
PEOPLEKNOWABOUT
YOURSOLUTION

3ELLING
THESOLUTION

2APIDLYLEARNING
ANDhTACKINGv
BASEDONYOUR
SUCCESSES
ANDFAILURES

)NNOVATING

'ENERATINGVALUE

47

Nathan Felde provided an example.Case study. using the AIGA process in Iraq by Nathan Felde AIGA has tried to use its 12-step model as a structure for organizing case studies. $EFININGTHEPROBLEM     $EFININGTHE PROBLEM %NVISIONINGTHE DESIREDENDSTATE KNOWINGWHAT VICTORYLOOKSLIKE $EFININGTHE APPROACHBYWHICH VICTORYCAN BEACHIEVED )NCITINGSUPPORT ANDTHENACTION .EEDOIL 'OTOIL #ONTROL)RAQ #REATEhAXISOFEVILv ANDCLIMATEOFFEAR )NNOVATING     3EEKINGINSIGHT TOINFORM THEPROTOTYPING OFTHESOLUTION 0ROTOTYPING POTENTIAL SOLUTIONS $ELINEATINGTHE TOUGHCHOICES %NABLINGTHETEAM TOWORK ASATEAM !SKDAD 'RENADA.

0ANAMA.

)NSPECTIONSVERSUS +UWAIT.

!FGHANISTAN OVERWHELMINGFORCE h9OUAREEITHERWITHUS ORAGAINSTUSv 'ENERATINGVALUE     #HOOSINGTHE BESTSOLUTION THENACTIVATINGIT -AKINGSURE PEOPLEKNOWABOUT YOURSOLUTION 3ELLING THESOLUTION 2APIDLYLEARNING ANDhTACKINGv BASEDONYOUR SUCCESSES ANDFAILURES 7AR h"OMBSAWAYv 48 #ALL2UPERT AND(ALLIBURTON 7EAPONSOF MASSDESTRUCTION .IBERATINGTHE PEOPLEOF)RAQ .

$ISCOVERINGTHEOPPORTUNITY     !CQUIRING ADISTINCTIVE PERSONA 0RACTICING CHARMUNTIL CHARISMA ISACHIEVED #IRCULATING AMONGSTTHE RIGHTPEOPLE . acknowledging aspects of the AIGA’s function (and that of other professional organizations) which few bring up in public.What the AIGA didn’t tell you by Nathan Felde Felde also offered an alternative version of the 12-step process.ISTENINGFOR DEVELOPING CHANGESIN STATUSQUO     2AISINGQUESTIONS THATONLYYOU CANANSWER %LIMINATINGOPTIONS OTHERTHAN YOURSERVICES 0RESENTING THEPROPOSAL WHILEAPPEARING UNAVAILABLE 0ROMISINGMORE THANTHECONTRACT REQUIRES     $ISCOVERING INSURMOUNTABLE DIFFICULTIES &INDINGSOMEONE ONCLIENTSIDE TOBLAME 2ESCUING CLIENTWITH BIGGERPROPOSAL !NNOUNCING SUCCESSWITH FIRSTSTAGE /BTAININGTHECONTRACT 'ETTINGPAID 49 .

Alice Agogino $EFINE 0ROTOTYPE %VALUATE 50 .

) "UILD 4EST &AB %RRORS $ESIGN %RRORS 51 . (See facing page. design-build-test is also analogous to defineprototype-evaluate. (See page 117. $ESIGN In the first step. Agogino presents a variation on the classic goal-action feedback loop.Design. test after Alice Agogino (1 of 3) This model is the first in a series of three developed by Alice Agogino for NASA’s Jet Propulsion Laboratory (JPL) at California Institute of Technology.) Of course. Agogino is a professor of mechanical engineering at UC Berkeley. build.

Agogino places the original design-buildtest process in the context of a larger project. test after Alice Agogino (2 of 3) In the second step. build. #ONCEIVE 3ELL $ESIGN "UILD 4EST &AB %RRORS $ESIGN %RRORS 3CIENCE5SE 3CENARIO 52 /PERATE .Design.

Design.” !RCHI TECTURAL %RRORS #ONCEIVE $ESIGN %RRORS -ODEL 4EST-ODEL 3ELL $ESIGN -ODEL 4EST-ODEL "UILD 4EST /PERATE &AB %RRORS $ESIGN %RRORS 3CIENCE5SE 3CENARIO 53 . test after Alice Agogino (3 of 3) In the last step. build. Agogio adds feedback loops with early tests of models in order to “find errors faster.

Mechanical engineering design process after students at UC Berkeley Institute of Design (BID) Agogino sometimes asks her students to diagram the design process—an interesting way to begin to understand how students (and others) understand things. Below is an example from one of her classes. 4ASK -ECHANICAL%NGINEERING 4ASK&ORMULATION0HASE 3PECIFICATION.

!NALYSISOF0RODUCT%NVIRONMENT 3IMPLIFIED&UNCTION &UNCTIONAL0HASE 4ECHNICAL2EQUIREMENTS AND3PECIFIED#OSTS $ETERMINATIONOF/VERALL&UNCTION3TRUCTURE $ETERMINATIONOF3PECIAL&UNCTION3TRUCTURE !CTUAL&UNCTION #OMPARISONOF3PECIFIEDAND!CTUAL&UNCTIONS &ORM$ESIGN0HASE &ORM$ESIGNAND-ATERIAL3ELECTION $ESIGNFOR0RODUCTION !CTUAL&UNCTION !CTUAL#OST #OMPARISON !CTUAL 3PECIFIED&UNCTIONVS!CTUAL 3PECIFIED#OST 2ESULT 0RODUCTION$RAWINGS 0RODUCT 54 .

It provides a useful outline. -ISSION 3TATEMENT )DENTIFY #USTOMER .EEDS %STABLISH 4ARGET 3PECIFICATIONS 'ENERATE 0RODUCT #ONCEPTS 3ELECT 0RODUCT #ONCEPTS 4EST0RODUCT #ONCEPTS 3ET&INAL 3PECIFICATIONS 0LAN $OWNSTREAM $EVELOPMENT $EVELOPMENT 0LAN 0ERFORM%CONOMIC!NALYSIS "ENCHMARK#OMPETITIVE0RODUCTS "UILDAND4EST-ODELSAND0ROTOTYPES 4ECHNICAL0OSSIBILITIES 0ROTOTYPING#YCLES #USTOMER0REFERENCES 55 .New product development process after Steven D. but does not capture the “messy” iteration typical of much product development work. Eppinger and Karl T. Ulrich (1995) Alice Agogino introduced me to Eppinger and Ulrich’s model of the product development process.

John Chris Jones 56 .

Design process after John Chris Jones (1970) Along with Christopher Alexander and Bruce Archer. (See the left side of the diagram. Jones’s scale is similar to the models of design scope described by Doblin and Alexander.) We may also apply his scale to the scope of problem being undertaken. Jones first published Design Methods in 1970.)  "RIEFISSUED  $ESIGNSITUATIONEXPLORED 3YSTEM$ESIGNING  0ROBLEMSTRUCTUREPERCEIVED ORTRANSFORMED $ESIGNBY$RAWING  "OUNDRIESLOCATED. He included several models of design and the design process. (See pages 17-18. John Chris Jones was one of the pioneers of the design methods movement. Jones used the model below for classifying and selecting design methods. Jones also provides a scale for describing the applicable range of a method. Jones notes that the steps decrease in generality and increase in certainty. Designers might use one or more meth- 4ECHNOLOGICAL#HANGE OR3OCIO TECHNICALINNOVATION ods to move from one step to another. I have included three in this section. In this way.

SUB SOLUTIONSDESCRIBED ANDCONFLICTSIDENTIFIED #RAFT%VOLUTION  3UB SOLUTIONSCOMBINED INTOALTERNATIVEDESIGNS  !LTERNATIVEDESIGNSEVALUATED ANDFINALDESIGNSELECTED 57 .

Value analysis after John Chris Jones (1970) Jones described value analysis as a design method.OT&EASIBLE 4ECHNICAL!NALYSIS !NALYSISAND3ELECTION "EST)DEA &INAL!NALYSIS OF#OST 2EJECT3OME4ECHNICAL2EASONS 3ELECTION 2EJECT3OME #OST2EASONS 0RESENTATION 3ELLINGTHE)DEA 58 0RESENTATION .OT2EQUIRED !NALYSISOF6ALUE #ONSIDER!LTERNATIVES #REATIVE0HASE .EW)DEAS #OMBINE7ITH .” He saw it as applying to the design of an element within a larger system. Yet his value analysis process (as he dia- grammed it) is itself a sort of design process—albeit with a special emphasis on cost. This example of a design processnested within a design process nicely illustrates the recursive nature of designing. $EFINE%LEMENT $EFINITION0HASE %XISTING)DEA $EFINE&UNCTION !NALYSISOF#OST %LIMINATE&UNCTION. one aimed “to increase the rate at which designing and manufacturing organizations learn to reduce the cost of a product.EW#ONCEPTS 0ARTIAL3UBSTITUTION 2EDUCTION !NALYSISOF#OST /THER%LEMENTS 0RELIMINARY3ORTING 2EJECT3OME.

Jones notes “the diagram should not be taken to imply a linear sequence of stages.Man-machine system designing after John Chris Jones (1970) Jones also described man-machine system designing as a design method. He proposes beginning with training procedures. is a sort of design process. one aimed “to achieve internal compatibility between the human and machine components of a system. The specifications in each box can be attended to in any order and will require many cross-references before they are complete. and external compatibility between the system and the environment in which it operates. too. and then designing the machine to support the desired training and interface. working out the man-machine interface.” He suggests deliberately reversing “the traditional sequence of machine-first-people-second” design.” This method. 3PECIFY)NPUTSAND/UTPUTSOF3YSTEM 3PECIFY&UNCTIONSOF3YSTEM#OMPONENTS !LLOCATE&UNCTIONSTO-ACHINESORTO(UMANS (UMAN&ACTORS$ESIGN 3PECIFY-ACHINE 3PECIFY(UMAN 0ERFORMANCE 0ERFORMANCE $ESIGN-ACHINE $ESIGN-AN -ACHINE $ESIGN*OB $ESIGN4RAINING #OMPONENTS )NTERFACES !IDS 0ROCEDURES #HECK3YSTEMFOR)NTERNAL AND%XTERNAL#OMPATIBILITY 59 .

Harold Kerzner offered the variation below.ON 0ARTICIPANTS $EFINITIONOF2EQUIREMENTS 60 . One reason these parodies are popular may be that they contain a large measure of truth. Lawson sites an example seen on a wall of the Greater London Council Architects Department in 1978.Eight phases of a project Sometimes presented as six phases of a project People have passed variations of this project parody around for years. More recently. 0ROJECT)NITIATION 7ILD%NTHUSIASM $ISILLUSIONMENT #HAOS 3EARCHFORTHE'UILTY 0UNISHMENTOFTHE)NNOCENT 0ROMOTIONOF.

but who would admit such a thing? 61 . Some firms see their processes as a competitive advantage and thus keep them proprietary. Some firms operate without processes.Consultant models A few consultancies publish their processes.

Define Design Develop Deploy Define Design Develop Deploy Debrief Imirage Define Design Develop Deploy Dedicate Bonns Define Design Develop Deploy Do Business Q4-2 Define Design Develop Deploy Enhance Satoria Define Design Develop Deploy Maintain Chris Brauer Diagnose Define Design Develop Deploy Muirmedia Discover Define Design Develop Deploy D5tech et al. The phrase is useful as a mnemonic device. but the wide range of variations suggests something is missing. Discover Define Design Develop Deploy Defend Dillon Group Discover Define Design Develop Deploy Denouement Cris Ippolite Discovery Define Design Develop Deploy Plan Define Design Develop Deploy Conclude Analyze Define Design Develop Deploy Assess Maintain Hbirbals Define Design Develop Test Deploy Manage Borland Detail Design Develop Deploy Define Team 1 Proxicom Phoenix Pop . Information Systems of Florida (SF) claims to have trademarked the Engagement Inform 62 four steps. develop. (define. design.4D software process and variations The 4D software process. feedback and iteration. for example. Author and date unknown. deploy) gained wide popularity among consultants developing websites during the internet boom. One company.

3COPE$OCUMENT 2EQUIREMENTS. The pairing of process steps and deliverables in a matrix is an important and recurring framework or archetype. linking each step to deliverables and related processes.IT consulting process overview after Mindtree Consulting Mindtree places the 4D process in a larger context.

!RCHITECTURE 2OAD-AP 5SER 4ECHNICAL$ESIGN 2EVIEWED 5NIT4ESTED 3OURCE#ODE 4ESTED0RODUCT -AJOR$ELIVERABLES #ONTINUOUS)NNOVATION $ISCOVERY $EFINITION !PPLICATION -ANAGEMENT $ESIGN $EVELOPMENT 4ESTING .IFE#YCLE0ROCESSES #ONTINUOUS2EFINEMENT 0ROJECT-ANAGEMENT 2EQUIREMENTS3COPE#HANGE-ANAGEMENT #ONFIGUREMENT-ANAGEMENT #ONTINUOUS0ROCESSES 63 .

They resemble the 4D model. 2004 Discover Validate Articulate Product Lifecycle Phases Conceptual Design Detailed Design Procurement/Production Operations/Support Product Design Project Definition Product Development Product Engineering Identify Frog. 2004 Product Definition Brand & Space Process Investigation Concept Development Digital Media Process Investigation 64 Exploration Concept Refinement/Validation Definition Implementation Integration/Testing Production Implementation Launch . 1998 Definition Concept Creation Implementation Cheskin.Other models This page presents a sampling of design process models from leading consultancies. Studio Archetype. IDEO is a large (by design standards) multidisciplinary design consultancy. On the facing page is IDEO’s design process as described in Business Week.

IDEO (2004)  /BSERVATION )$%/SCOGNITIVEPSYCHOLOGISTS.

ANTHROPOLOGISTS.

OhBUTS. ANDSOCIOLOGISTSTEAMUPWITHCORPORATECLIENTSTO UNDERSTANDTHECONSUMEREXPERIENCE 3OMEOF)$%/STECHNIQUES  "RAINSTORMING !NINTENSEIDEA GENERATINGSESSIONANALYZINGDATA GATHEREDBYOBSERVINGPEOPLE%ACHLASTSNOMORETHAN ANHOUR2ULESOFBRAINSTORMINGARESTRICTANDARE STENCILEDONTHEWALLS $EFERJUDGMENT$ONTDISMISSANYIDEAS "UILDONTHEIDEASOFOTHERS.

vONLYhANDSv %NCOURAGEWILDIDEAS%MBRACETHEMOSTOUT OF THE BOXNOTIONSBECAUSE THEYCANBETHEKEYTOSOLUTIONS 'OFORQUANTITY!IMFORASMANYNEWIDEASASPOSSIBLE)NAGOODSESSION.

UPTOIDEASAREGENERATEDINMINUTES "EVISUAL5SEYELLOW.

RED.

OINTERRUPTING.ANDBLUEMARKERSTOWRITEONBIG INCHBY INCH 0OST ITSTHATAREPUTONAWALL 3TAYFOCUSEDONTHETOPIC!LWAYSKEEPTHEDISCUSSIONONTARGET /NECONVERSATIONATATIME.

NODISMISSING.

NODISRESPECT.

NORUDENESS  2APIDPROTOTYPING -OCKING UPWORKINGMODELSHELPSEVERYONEVISUALIZE POSSIBLESOLUTIONSANDSPEEDSUPDECISION MAKINGAND INNOVATION 3OMEGUIDELINES  2EFINING !TTHISSTAGE.

)$%/NARROWSDOWNTHECHOICESTO AFEWPOSSIBILITIES (ERESHOWITSDONE  )MPLEMENTATION "RING)$%/SSTRONGENGINEERING.

DESIGN.

ANDSOCIAL SCIENCECAPABILITIESTOBEARWHENACTUALLYCREATINGA PRODUCTORSERVICE 4APALLRESOURCES)NVOLVE)$%/SDIVERSEWORKFORCEFROMCOUNTRIESTO CARRYOUTTHEPLANS 4HEWORKFORCE%MPLOYEESHAVEADVANCEDDEGREESINDIFFERENTKINDSOFENGINEERING MECHANICAL.

ELECTRICAL.

BIOMECHANICAL.

SOFTWARE.

AEROSPACE.

ANDMANUFACTURING -ANYAREEXPERTSINMATERIALSSCIENCE.

COMPUTER AIDEDDESIGN.

ROBOTICS.

COMPUTER SCIENCE.

MOVIESPECIALEFFECTS.

MOLDING.

INDUSTRIALINTERACTION.

GRAPHICANDWEB INFORMATION.

FASHIONANDAUTOMOTIVEDESIGN.

BUSINESS.

COMMUNICATIONS.

LINGUISTICS.

SOCIOLOGY.

ERGONOMICS.

COGNITIVEPSYCHOLOGY.

BIOMECHANICS.

ARTTHERAPY.

ETHNOLOGY.

MANAGEMENTCONSULTING.

STATISTICS.

MEDICINE.

ANDZOOLOGY 3HADOWING/BSERVINGPEOPLEUSINGPRODUCTS.

SHOPPING.

GOINGTOHOSPITALS.

TAKINGATRAIN.

USINGTHEIRCELLPHONES "EHAVIORALMAPPING0HOTOGRAPHINGPEOPLEWITHINASPACE.

SUCHASAHOSPITAL WAITINGROOM.

OVERTWOORTHREEDAYS #ONSUMERJOURNEY+EEPINGTRACKOFALLTHEINTERACTIONSACONSUMERHASWITHIN APRODUCT.

SERVICE.

ORSPACE #AMERAJOURNALS!SKINGCONSUMERSTOKEEPVISUALDIARIESOFTHEIRACTIVITIES ANDIMPRESSIONSRELATINGTOAPRODUCT %XTREMEUSERINTERVIEWS4ALKINGTOPEOPLEWHOREALLYKNOWˆORKNOWNOTHINGˆ ABOUTAPRODUCTORSERVICE.

ANDEVALUATINGTHEIREXPERIENCEUSINGIT 3TORYTELLING0ROMPTINGPEOPLETOTELLPERSONALSTORIESABOUTTHEIR CONSUMEREXPERIENCES 5NFOCUSGROUPS)NTERVIEWINGADIVERSEGROUPOFPEOPLE4OEXPLOREIDEASABOUT SANDALS.

)$%/GATHEREDANARTIST.

ABODYBUILDER.

APODIATRIST.

OFRILLS-AKEPROTOTYPESTHATDEMONSTRATEADESIGNIDEAWITHOUTSWEATING OVERTHEDETAILS #REATESCENARIOS3HOWHOWAVARIETYOFPEOPLEUSEASERVICEINDIFFERENTWAYS ANDHOWVARIOUSDESIGNSCANMEETTHEIRINDIVIDUALNEEDS "ODYSTORM$ELINEATEDIFFERENTTYPESOFCONSUMERSANDACTOUTTHEIRROLES "RAINSTORMINARAPIDFASHIONTOWEEDOUTIDEASANDFOCUSONTHEREMAINING BESTOPTIONS &OCUSPROTOTYPINGONAFEWKEYIDEASTOARRIVEATANOPTIMALSOLUTIONTOAPROBLEM %NGAGETHECLIENTACTIVELYINTHEPROCESSOFNARROWINGTHECHOICES "EDISCIPLINEDANDRUTHLESSINMAKINGSELECTIONS &OCUSONTHEOUTCOMEOFTHEPROCESSˆREACHINGTHEBESTPOSSIBLESOLUTIONS 'ETAGREEMENTFROMALLSTAKEHOLDERS4HEMORETOP LEVELEXECUTIVESWHOSIGNOFF ONTHESOLUTION.EVERWASTETIMEON COMPLICATEDCONCEPTS .ANDASHOEFETISHIST -OCK UPEVERYTHING)TISPOSSIBLETOCREATEMODELSNOTONLYOFPRODUCTS BUTALSOOFSERVICESSUCHASHEALTHCAREANDSPACESSUCHASMUSEUMLOBBIES 5SEVIDEOGRAPHY-AKESHORTMOVIESTODEPICTTHECONSUMEREXPERIENCE 'OFAST"UILDMOCK UPSQUICKLYANDCHEAPLY.

THEBETTERTHECHANCESOFSUCCESS 65 .

As proposed by the project sponsor As specified in the project request As designed by the senior analyst As produced by the programmers As installed at the user’s site What the user wanted 66 .

This section provides an overview of some of the prominent models. 67 .Software development models Development processes remain a topic of heated discussion in the software development world.

Output (a “deliverable document”) from one phase serves as input (requirements) to the next phase. fixed price for a project. “we inherited the waterfall lifecycle from other engineering disciplines.Waterfall lifecycle after Philippe Kruchten (2004) Kroll admitted.” According to Kruchten.” 2EQUIREMENTS $ESIGN #ODING 4ESTING 2EQUIREMENTS 2EQUIREMENTS $ESIGN $ESIGN #ODING $ESIGN #ODING 4ESTING 68 2EQUIREMENTS #ODING 4ESTING 4ESTING . This helps to simplify integration. . where it has proven very effective. This is the case when an organization has to bid a firm. most teams use a modified waterfall approach.” Per Kroll (2004) noted. get testers testing earlier. sometimes called phases or stages. breaking a project down into two or more parts. “Of paramount importance for certain projects is the issue of freezing the requirements specifications (together with some high-level design) in a contractual arrangement very early in the lifecycle.” The essence of the “waterfall” approach is getting one stage “right” before moving on to the next. prior to engaging in more thorough design and implementation work. “Many design teams would view modifying the design after Stage 1 as a failure of their initial design or requirements process. “In practice. and provide an earlier reading on project status. . It was first formally described by Winston Royce in 1970. Kruchten noted. This approach also breaks up the code into manageable pieces and minimizes the integration code .

‘Analyze a little. -AJORMILESTONE )NTERNALRELEASE %XTERNALRELEASE 0HASES Kruchten noted.Rational Unified Process (RUP) after Phillippe Kruchten (2003) RUP follows an “iterative” lifecycle—as opposed to the “waterfall” lifecycle—“developing in iterations that encompass the activities of requirements analysis.The horizontal dimension represents time and shows the lifecycle aspects of the process as it unfolds.’” (For more on Boehm’s model. Rational (and later IBM) developed and sold a suite of software development tools built around the Rational Unified Process (RUP). the Unified Software Process Model (USPM). . two dimensions: . RUP was designed using the Unified Modeling Language (UML) and has as its underlying object model. design a little. and loop back. implementation. integration. test a little.A vertical dimension represents core process disciplines (or workflows). You can summarize it with the catch phrase. see page 122.” )NCEPTION %LABORATION #ONSTRUCTION 4RANSITION )TERATIONS "USINESSMODELING 2EQUIREMENTS !NALYSISANDDESIGN )MPLEMENTATION 4EST $EPLOYMENT #ONFIGURATIONAND CHANGEMANAGEMENT 0ROJECTMANAGEMENT %NVIRONMENT 69 . “The process has two structures or. design. if you prefer. which logically group software engineering activities by their nature. and tests.) Rational Software was an independent developer purchased by IBM in 2003. One of the best descriptions is in Professor Barry Boehm’s paper on the “spiral” model.

founder of Extreme Programming. Three weeks later. however. The context in which the software development takes place proves as important to the project’s success as the programming itself. Beck had them print their first one. for each story. in each iteration. however. the system still couldn’t print a check. has described how he created XP in 1996. Yes.ATEST6ERSION !CCEPTANCE 4ESTS 3PIKE . write “acceptance tests” to demonstrate the story meets customer expectations. the problem concerns relationships between the business people and the programmers.EXT)TERATION . eighteen months into the project. you can screw up the programming so badly you kill the project.Extreme Programming (XP) Process after Don Wells (2000) Kent Beck. poor communications—factors unrelated to the programming.EW5SER3TORY. argues 4EST3CENARIOS 5SER3TORIES 2EQUIREMENTS . Usually.EW5SER3TORY 0ROJECT6ELOCITY 3YSTEM-ETAPHOR 2ELEASE0LAN !RCHITECTURAL 3PIKE 2ELEASE 0LANNING "UGS )TERATION 5NCERTAIN #ONFIDENT %STIMATES %STIMATES #USTOMER!PPROVAL . Alan Cooper. the budget process. When they called him.” At its core. “Up until then I believed better programming would solve all the world’s ills. implement a few new features called “stories”. Chrysler asked him to put a payroll system project back on track. XP is a simple process of experimentation and improvement: Divide a project into “iterations”.

ATEST 6ERSION 3MALL 2ELEASES .EW&UNTIONALITY $EVELOPMENT "UG&IXES "UGS &AILED!CCEPTANCE4ESTS 70 $AYBY$AY .EARNAND#OMMUNICATE )TERATION0LAN )TERATION 0LANNING .EXT )TERATION . 0ROJECT6ELOCITY 2ELEASE 0LAN 5SER3TORIES 5NFINISHED4ASKS 0ROJECT6ELOCITY .

one of the primary distinguishing features of XP.EARNAND #OMMUNICATE 5NFINISHED 4ASKS )TERATION 0LAN 4OO-UCH 4ASKS ownership. Beck claims this increases quality. see page 127.EW &UNCTIONALITY -OVE0EOPLE!ROUND #2##ARDS .EED(ELP #OMPLEX0ROBLEM 2UN!LL 0AIR5P . (For another model of extreme programming.EW&UNCTIONALITY #OMPLEX#ODE !CCEPTANCE 4EST0ASSED 2EFACTOR -ERCILESSLY 71 . Two programmers work together at a single computer.EW5NIT4ESTS 0AIR0RO GRAMMING 0ASSED5NIT4EST 3IMPLE#ODE 5NIT4ESTS #ONTINUOUS )NTEGRATION 2UN&AILED !CCEPTANCE4EST . the second “zooms in” on iteration.) 3HARE 0AIR0ROGRAMMING TO$O 2EFACTOR-ERCILESSLY . The first one shows the whole project.EXT4ASKOR 3TAND5P -EETING &AILED #OLLECTIVE #ODE /WNERSHIP 5NIT4ESTS0ASSED !CCEPTANCE4EST0ASSED !CCEPTANCE 4ESTS $AYBY$AY "UG&IXES &AILED!CCEPTANCE4ESTS -OVE0EOPLE !ROUND #2# #ARDS 3IMPLE$ESIGN #HANGE0AIR 5NIT 4ESTS0ASSED 7E. (For more on Cooper. It has to be a lot more fun than coding alone. At the center of the last diagram is pair programming.EXT4ASKOR &AILED!CCEPTANCE4EST &AILED5NIT4EST #REATEA 5NIT4EST . see pages 86-91. and the fourth on collective code . the third “zooms in” on development.) The models below are nested.XP is not a design process—because it includes no mechanism for understanding user goals.

“The V Model is a series of General Directives (250. formerly of the Army Research Laboratory. The V shows the typical sequence of development activities on the left-hand (downhill) side and the corresponding sequence of test execution activities on the right-hand (uphill) side” #ONTRACT Accounts of this model’s origin vary. According to Goldsmith and Graham.’s National Computing Centre publications in the 1990s with the aim of improving the efficiency and effectiveness of software development. “Initially defined by the late Paul Rook in the late 1980s. 251. the V Model emerged in reaction to some waterfall models that showed testing as a single phase following the traditional development phases . methods to be applied.” 2EVIEW 4EST 7ARRANTY 5SERS3OFTWARE 2EQUIREMENTS !CCEPTANCE4ESTING 3OFTWARE 2EQUIREMENTS 3PECIFICATIONS 3OFTWARE $EVELOPMENT 3YSTEM4ESTING (IGH.K. Goldsmith and Graham (2002) note.” But according to Morton Hirschberg. . “In fact. IABG (1992) The principle characteristic of the V model seems to be that it weights testing equally with design and development. The V Model portrays several distinct testing levels and illustrates how each level addresses a different stage of the lifecycle. and 252) that prescribe or describe the procedures. .EVEL$ESIGN )NTEGRATION4ESTING $ETAILED$ESIGN 5NIT4ESTING #ODING 0ROJECT -ANAGEMENT 72 1UALITY !SSURANCE .V model Paul Rock (~1980). and the functional requirements for tools to be used in developing software systems for the German Federal Armed Forces. the V was included in the U.

According to Carmel et al (1993). “JAD was conceived by Chuck Moris and Tony Crawford of IBM in 1977. usually three to five days long. magnetic visual displays. in which various levels of users meet with developers to hammer out requirements for a system. Typically consultants use the process to quickly lock down user requirements for automation projects—so they can minimize the time needed to define requirements and work within a fixed bid. .” 0ROJECT2EQUEST $EFINITION )NTERVIEW-ANAGEMENT 3ELECTTHE*!$4EAM 0REPARETHE-ANAGEMENT $EFINITION'UIDE 3CHEDULETHE3ESSION -ANAGEMENT $EFINITION'UIDE 2ESEARCH "ECOME&AMILIAR WITHTHE3YSTEM #REATE$ATA-ODELSAND 0ROCESS-ODELS 'ATHER0RELIMINARY)NFORMATION 0REPARETHE3ESSION!GENDA $ATA-ODELSAND 0ROCESS-ODELS 3ESSION !GENDA 0RELIMINARY )NFORMATION 0REPERATION 7ORKING$OCUMENT 4HE7ORKING$OCUMENT 6ISUAL!IDS 4RAINTHE3CRIBE 4HEPRE 3ESSION -EETING 3ET5PTHE-EETING2OOM /VERHEADS.Joint Application Development (JAD) after Jane Wood and Denise Silver (1995) JAD sessions (sometimes jam sessions) are intensive workshops. and careful documentations of the meeting. The first JAD meetings . used the same basic JAD concepts still used today: user participant meetings. The JAD approach was loosely derived from another IBM methodology—BSP (Business Systems Planning). .

&LIP#HARTS.

AND-AGNETICS 4HE3ESSION 0ROCESS-ODELS $ATA-ODELS 3CREENS !SSUMPTIONS /PEN)SSUES 0RODUCETHE &INAL$OCUMENT !SSEMBLETHE $OCUMENT 4RACK$ISTRIBUTION 4HE2EVIEW-EETING !PPROVETHE $OCUMENT 2EPORTS 3CRIBE.OTES AND&ORMS 4HE&INAL$OCUMENT #HANGING2EQUIREMENTS 3IGNED!PPROVAL&ORM *!$$OCUMENT 73 .

and techniques to project activities to meet project requirements. One dimension describes [nine]‘knowledge areas’ while the other dimension describes project management processes split into five process groups. including software development and deployment projects. tools. The PMBOK defines a project as ‘a temporary endeavor undertaken to create a unique product or service.PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987) Charbonneau wrote. “The PMBOK describes a set of generally accepted practices that PM practitioners can use to manage all types of projects.’ The PMBOK presents [thirty-nine] PM practices in logical groupings.” The process groups are shown in the model below. 0LANNING 0ROCESSES #ONTROLLING 0ROCESSES ARROWSREPRESENTFLOW OFINFORMATION 74 %XECUTING 0ROCESSES #LOSING 0ROCESSES . skills.’ It defines )NITIATING 0ROCESSES PM as ‘the application of knowledge.

and counteracting the possible adverse effects of use on human health. safety and performance. It describes user centered design as a multi-disciplinary activity. which incorporates human factors and ergonomics knowl- edge and techniques with the objective of enhancing effectiveness and productivity. (1999) “ISO 13407 provides guidance on achieving quality in use by incorporating user centered design activities throughout the life cycle of interactive computer-based systems. improving human working conditions.ISO 13407 Human-centered design processes for interactive systems Tom Stewart et al.” 0LANTHEHUMAN CENTEREDPROCESS -EETSREQUIREMENTS 5NDERSTANDAND SPECIFYTHECONTEXT OFUSE %VALUATE DESIGNAGAINST USERREQUIREMENTS 3PECIFYUSER ANDORGANIZATIONAL REQUIREMENTS 0RODUCE DESIGNSOLUTIONS 75 .

‘How do we stack up?’” 7HYDOWETHINKWEWILLUSETHISOFFERING -ARKETINGDEFINITION 7HATARETHEYLOOKINGFOR 4ASKANALYSIS 7HATELSEISOUTTHERE #OMPETITIVEEVALUATION (OWSTHISFORSTARTERS $ESIGNANDWALK THROUGH $OESTHISWORK 7HATWOULDMAKEITBETTER $ESIGNEVALUATIONANDVALIDATION (OWDOWESTACKUP "ENCHMARKASSESSMENT 76 . types of users. and early feedback is gathered from users. prime competitors. answering the question. a user feedback benchmark assessment session is conducted to answer the question. ‘How’s this for starters?’ This leads to several cycles of iterative detailed design and user feedback through design evaluation and validation sessions. ‘Who do we think will use this offering?’ This involves understanding the target markets. we attempt to understand how the tasks described in the prior step are carried out today either with a competitor’s product or an analog method. Next. answering the questions.User-centered design process (UCD) after Karel Vredenburg (2003) Vredenburg describes this “simplified generic description of the design process” as follows: “The design process starts with the collection of relevant market definition information to answer the basic question. ‘What are they looking for?’ Following this. and so forth. market trends. conceptual design of the user experience starts. ‘What else is out there?’ At this point. high level needs and preferences. detailed information is collected from representative users within the target markets to understand their goals and tasks to answer the question. This answers the question. ‘Does this work?’ and ‘What would make it better?’ At the end of the development cycle.

albeit an important one. )NTEGRATED0ORTFOLIO-ANAGEMENT4EAM)0-4 "USINESS-ANAGEMENT -ARKETINFORMATION #USTOMERFEEDBACK #OMPETITIONINFORMATION 4ECHNOLOGYTOOLS 0RODUCTPORTFOLIO 5NDERSTAND 0ERFORM 0ERFORM $EVELOP !LIGN -ANAGE THEMARKETPLACE MARKET PORTFOLIO MARKETSEGMENT ANDOPTIMIZE MARKETSEGMENT SEGMENTATION ANALYSIS STRATEGY BUSINESSPLANS ANDASSESS )NTEGRATED0RODUCT$EVELOPMENT #ANDIDATEPROJECTS $EVELOP $EVELOP $EVELOP 1UALIFY 2AMP UP . development of education and training. Having UCD and UE included directly in the corporate-wide IPD process ensures that decisions made about an offering will be required to take UCD and UE information into account. in the overall strategy of building ease of use into the total user experience at IBM. Vredenburg noted. and provision of tools and technology as part of IBM’s strategy for integrating UCD. which is the business checkpoint mechanism used for all funding and projectmilestone reviews within IBM. communications.” Vredenburg also noted creating new corporate-wide positions.Relation of UCD to IPD and Business Management after Karel Vredenburg (2003) The model below illustrates how User Centered Design (UCD) fits into IBM’s integrated product development process (IPD) and to its overall business management process. “Developing a new process and further enhancing it is only one component. UCD is a core enabling process in the overall integrated product development (IPD) process. Organizations need to be enabled to carry out new processes and be provided with leadership and guidance while executing them.IFECYCLE 3ATISFIED PRODUCT PRODUCT ANDVERIFY ANDCERTIFY ANDLAUNCH MANAGEMENT CUSTOMERS CONCEPTS DEFINITION PERFORMANCE ANDPLAN  ANDPLAN #ONCEPT$#0 5SER#ENTERED$ESIGN 0LAN$#0 !VAILABILITY$#0 3TUDY #REATE )TERATIVELY 6ALIDATE ANDDEFINE CONCEPTDESIGN DEVELOPDETAILED PRODUCTAGAINST USERS. and collaboration programs.

TASKS.

AND OFUSER DESIGN USEREXPECTATIONS COMPETITION EXPERIENCE WITHUSERS 0ROJECT$EVELOPMENT4EAMS0$4 77 .

EEDS )DENTIFYALLCUSTOMERS 0RIORITIZECUSTOMERS !SSESSCURRENTCUSTOMERDATA #OLLECTh6OICEOFTHE#USTOMERv $ETERMINEh6OICEOFTHE#USTOMERv STRATEGY !NALYZEANDPRIORITIZENEEDS #4/$RILLDOWN $ETERMINECHARACTERISTICSAND MEASURESFORNEEDS 3ELECTCRITICALFEWMEASURES -EASUREMENTSYSTEMCAPABILITY %STABLISHTARGETSANDSPECS 3ETPERFORMANCE3IGMA GOALS "ENCHMARKINGBESTPRACTICE IDENTIFIED #ONCEPT$ESIGN )$FUNCTIONSREQUIREDTOMEET#RITICAL TO1UALITIES#41S $EVELOPALTERNATEDESIGNCONCEPTS 3ELECTMOSTPROMISINGCONCEPTS $EVELOPCONCEPTDESIGN 0ERFORMANCE'AP $EPLOY#41STOCONCEPTDESIGN 0REDICT#41PERFORMANCE 0ERFORM'!0ANALYSISANDREVISE CONCEPTDESIGN 0ERFORMDESIGNRISKASSESSMENT &-%! $ETAILED$ESIGN $EVELOPDETAILEDDESIGNELEMENTS &LOWDOWN#41STOELEMENTS %STIMATECAPABILITIESOFDETAILED DESIGN 0ERFORMDESIGNRISKASSESSMENT &-%! !NALYZEGAPANDOPTIMIZEDESIGN 6ERIFICATION0LAN #USTOMERFEEDBACKONDESIGN $ETERMINEWHATTOVERIFY #REATETESTDOCUMENT #REATEPILOTPLAN 6ERIFIED$ESIGN "UILDPILOTPRODUCTPROCESSFOR VERIFICATION %XECUTETESTDOCUMENT !NALYZERESULTSANDADJUSTDESIGN 0ROJECT#LOSURE )MPLEMENTDESIGNFULLSCALE %XECUTECONTROLPLAN 4RANSFEROWNERSHIP &INANCIALBENEFITSVERIFIEDAND APPROVED 0HASEAND'ATEAPPROVAL 2EFINEBENEFITESTIMATES 0HASEAND'ATEAPPROVAL 5PDATEPROJECTIN024 0HASEAND'ATEAPPROVAL #ONTROL0LAN )$CRITICALINPUT.Sun Sigma Framework DMADV methodology for new products 0(!3%3  $EFINE )DENTIFYTHEPROBLEMOR PROCESSTOBEFIXEDORTO BEDESIGNED  -EASURE )DENTIFYLISTOFCUSTOMER REQUIREMENTSANDDEVELOP ANDPRIORITIZE#41SAROUND CUSTOMEREXPECTATIONS  !NALYZE #USTOMIZECUSTOMER EXPECTATIONSTOCREATEA CLEANPAPERDESIGN  $ESIGN $EVELOPONECLEANPAPER DESIGNTOMEETCUSTOMERS REQUIREMENTS  6ERIFY )MPLEMENTTHENEW PROCESSANDVERIFYTHATTHE DESIGNWORKS !#4)6)4935--!29 #HARTERAPPROVAL 3UN3HOT7ORKOUT 3ESSIONTO IDENTIFY1UICK(ITS 0HASEAND'ATEAPPROVAL 5PDATEPROJECTIN024 #USTOMER0RIORITIZED.

PROCESS.

EVEL0ROCESS-AP 3TAKEHOLDER!NALYSISAND!CTIONS 78 h6OICEOFTHE#USTOMERv3TRATEGY !LTERNATEDESIGNCONCEPTS $ETAILEDDESIGNELEMENTS 0ILOTPRODUCTPROCESS 0ERFORMANCE3IGMA GOALS &INALCONCEPTDESIGN 4ESTDOCUMENT 5PDATEDSCORECARD &IRSTPASSSCORECARD 5PDATEDSCORECARD 0ILOTPLAN &INALPRODUCTPROCESS 3TAKEHOLDERANALYSISANDACTIONS 3TAKEHOLDERANALYSISANDACTIONS 5PDATEDSCORECARD 3TAKEHOLDERANALYSISANDACTIONS .OUTPUT PARAMETERS $OCUMENTPROCEDURESTOGUIDE ONGOINGOPERATION %XITSTRATEGYIDENTIFIED 5PDATEPROJECTIN024 #ELEBRATIONANDRECOGNITION !SSESSPATENTABILITYOF PROCESSPRODUCT 5PDATEPROJECTIN024 0HASEAND'ATEAPPROVAL 5PDATEPROJECTIN024 /540543 0ROJECT#HARTER "USINESS#ASE 0ROBLEM3TATEMENT 'OAL3TATEMENT 3COPE $EFINITIONOF4EAMAND4IME #OMMITMENTS 4IMELINE-ILESTONES %STIMATED"ENEFITS 2ISKSAND#ONSTRAINTS #HARTER!PPROVALS (IGH.

Sun Sigma Framework DMAIC methodology for improving existing products 0(!3%3  $EFINE )DENTIFYTHEPROBLEMAND IDENTIFYTOPTO#RITICAL TO1UALITIES#41S TO FOCUSIMPROVEMENTSON  -EASURE -EASURETHECURRENT PERFORMANCEOFTHEDEFECT #41NOTMET ANDDISPLAY VARIATIONINTHEPROCESS  !NALYZE !NALYZETHEPROCESS VARIATIONTODETERMINEROOT CAUSESANDOPPORTUNITIES FORREDUCINGTHEVARIATION  )MPROVE 'ENERATE.

SELECT.

DESIGN.

TEST.

ANDIMPLEMENT IMPROVEMENTS  #ONTROL )NSTITUTIONALIZETHE IMPROVEMENTAND IMPLEMENTONGOING MONITORING !#4)6)4935--!29 #HARTERAPPROVAL 3UN3HOT7ORKOUT 3ESSIONTO IDENTIFY1UICK(ITS 0HASEAND'ATEAPPROVAL 5PDATEPROJECTIN024 /UTPUT-EASUREMENT 0ROJECT9ANDDEFECTDEFINED 0ERFORMANCESPECIFICATIONFOR9 $ATACOLLECTIONPLAN -EASUREMENTSYSTEMVALIDATED #OLLECTDATAFOR9 0ROCESSCAPABILITYFOR9 )MPROVEMENTGOALFOR9 2OOT#AUSE!NALYSIS "RAINSTORMALLPOSSIBLE8S 0RIORITIZELISTOF8S 6ERIFY8WITHDATA 0ERFORMANCE'AP )DENTIFYGAPSBETWEENCAPABILITIES ANDCUSTOMERREQUIREMENTS 2E EVALUATE$-!)#VS$-!$6 3OLUTION'ENERATIONAND0ILOT4EST $EVELOPANDSELECTSOLUTIONS 0ERFORMPILOTOFSOLUTIONS #ONFIRMIMPROVEMENTS #ONFIRMPRIORITIZED8S -APNEWPROCESS $ETERMINENEWCAPABILITY PERFORMANCE "ENCHMARKINGBESTPRACTICE IDENTIFIED "ENCHMARKING 0HASEANDGATEAPPROVAL 2EFINEBENEFITESTIMATES )MPLEMENTATION0LAN $EVELOPIMPLEMENTATIONPLAN )DENTIFYCONTROLS )MPLEMENTIMPROVEMENTS 5PDATEPROJECTIN024 0HASEAND'ATEAPPROVAL "ENCHMARKING 5PDATEPROJECTIN024 0HASEAND'ATEAPPROVAL 3USTAINED3OLUTION 0ROCESSDOCUMENTATIONCONTROLSIN PLACE -EASUREPERFORMANCE #ONFIRMSUSTAINABLESOLUTION 6ALIDATEMEASUREMENTSYSTEMON8S 0ROJECT#LOSURE %VALUATIONTRANSITIONOPPORTUNITIES )DENTIFYOTHERIMPROVEMENT OPPORTUNITIES 0ROJECTDOCUMENTATIONCOMPLETE 4RANSLATIONPACKAGE &INANCIALBENEFITSVERIFIEDAND APPROVED 0HASEAND'ATEAPPROVAL 5PDATEPROJECTIN024 5PDATEPROJECTIN024 #ELEBRATIONANDRECOGNITION /540543 0ROJECT#HARTER "USINESS#ASE 0ROBLEM3TATEMENT 'OAL3TATEMENT 6ALIDATEDCUSTOMER#41S 3COPE $EFINITIONOFTEAMANDTIME COMMITMENTS 4IMELINEMILESTONES %STIMATEDBENEFITS 2ISKSANDCONSTRAINTS #HARTERAPPROVAL $ETAILEDPROCESSMAP 3TAKEHOLDERANALYSISANDACTIONS 3TAKEHOLDERANALYSISANDACTIONS 0OSSIBLESOLUTIONS 0ROJECTDOCUMENTATION 0ILOTOFSOLUTIONS 4RANSLATIONPACKAGE -APOFNEWPROCESS )MPLEMENTATIONPLAN &INALIMPROVEMENTS 3TAKEHOLDERANALYSISANDACTIONS (IGH.EVEL0ROCESS-AP 3TAKEHOLDER!NALYSISAND!CTIONS 79 .

IST"/- $EFECT2ESOLUTIONAND 2ISK!SSESSMENT 2EPORTS &INALIZED00$ -ARKETING0LAN 4RAINING-ATERIALS !NNOUNCEMENT 0ACKAGE 80 &INALIZED3UPPORT 0LAN #USTOMER !CCEPTANCE4EST 2EPORT $EFECT2ESOLUTIONAND 2ISK!SSESSMENT 2EPORTS 4RAINING-ATERIALS %ND OF 0RODUCT0LAN &INALIZED%ND OF 3UPPORT .INE -ANAGEMENTTOSTART PROJECTS !NNOUNCETOCHANNELS !PPROVEEACH #OMPONENT0ROJECT 0LAN #REATEANDDELIVER 0RODUCTION4RAINING #REATEANDEXECUTE .Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product instances 0(!3%3         #ONCEPT 0LAN $EVELOP )NTEGRATE 4EST 3YSTEM4EST #USTOMER !CCEPTANCE $EPLOY 3USTAIN 2ETIRE #REATEOPTIONAL 3UB 3TEERING #OMMITTEES %XECUTE3YSTEM4EST 6ERIFYEXECUTION THROUGHSYSTEMTEST OF0RODUCT0LAN !NNOUNCETOTHE PUBLIC 3USTAINTHEPRODUCT )NVENTORYCAP EQUIPMENTAND DISPOSABLES !#4)6)4935--!29 "USINESS5NITCREATES A0RODUCT0ORTFOLIO 3TEERING#OMMITTEE #REATEOPTIONAL #ONSOLIDATION4EAMS # 4EAMS #REATETRAINING MATERIALS #REATEANNOUNCEMENT PACKAGE %XECUTE#USTOMER !CCEPTANCE4EST !NNOUNCETOINTERNAL COMMUNITY )NFLUENCE.IFE0LAN .IST"/-  PAGERSFORREQUIRED COMPONENTS #OMPONENT0LANS &INALIZED3ALES0LAN )NTERNAL$ESIGN 3PECIFICATION 3YSTEM4EST2EPORTS #OMPONENT )NTEGRATION4EST0LANS  PAGERSFOR COMPONENTS &INALIZED00$ /PS-RG0LAN 5PDATED0RODUCT "OUNDARY3UMMARY !PPROVED0RODUCT #ONTENT.AUNCH0ACKAGE #ONDUCTSTLESSONS LEARNEDREVIEW #ONDUCTON GOING VIABILITYASSESSMENTS !NNOUNCEINTENTTO END OF LIFE #ONDUCTNDLESSONS LEARNEDREVIEW !NNOUNCEEND OF LIFE TOPUBLIC %XECUTE%ND OF 0RODUCT0LAN #ONDUCTRDFINAL LESSONSLEARNED REVIEW #REATETRAINING MATERIALS #ONDUCT2EVENUE 2ELEASE !PPROVEEACH #OMPONENT0ROJECT !RCHITECTURE 4ESTEACHCOMPONENT $ELIVEREACH #OMPONENT0ROJECTTO # 4EAM #ONDUCT#OMPONENT 4/) 4EST#OMPONENTS #ONDUCT0RODUCT4/) /540543 0RODUCT 2EQUIREMENTS $OCUMENT )NITIAL&UNCTIONAL 3PECIFICATION 0RODUCT#ONTENT $OCUMENT &UNCTIONAL 3PECIFICATION 0RODUCT0LAN $OCUMENT )NITIAL0RODUCT #ONTENTS.

AUNCHTHEPRODUCT 3TABILIZEOPERATIONAL ANDSUPPORT PROCESSES -ANAGEPRODUCT PROFITABILITYAND GROWTH 2ETIREPRODUCTAND MANAGECUSTOMER TRANSITIONS 0ROVIDECUSTOMER SUPPORTANDDEFECT TRACKING 0REPARE COMPREHENSIVEPLANS FORINTRODUCTIONAND SUPPORT /540543 0RODUCT.Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product lines 0(!3%3  #ONCEPT  0LAN  $EVELOP )NTEGRATE 4EST  3YSTEM4EST  #USTOMER !CCEPTANCE  $EPLOY  3USTAIN  2ETIRE !#4)6)4935--!29 "5CREATES0RODUCT .INE0LAN $OCUMENT 0RODUCT.INE0ORTFOLIO3TEERING #OMMITTEE0# $EVELOPTHEPRODUCT ANDVERIFYCOMPONENT PERFORMANCE 1UALIFYTHEPRODUCT FUNCTIONALITYAND PERFORMANCE $EVELOP3UNSAND CRITICALPARTNERS PRODUCTIONPROCESSES 1UALIFYPRODUCTION ANDSUPPLIER PROCESSES #ONFIRMPRODUCT FUNCTIONALITYIN PLANNEDCUSTOMER ENVIRONMENTS %XECUTEINTRODUCTION ANDSUPPORTPLANS .INE 2EQUIREMENTS $OCUMENT )NITIAL&UNCTIONAL 3PECIFICATION &UNCTIONAL 3PECIFICATION 0RODUCT.INE#ONTENT $OCUMENT 81 .

82 . This may be another function of George Miller’s famous “Magic Number 7.” The next section includes some very detailed models. they’re typically organized into a tree with three to seven major steps.Complex linear models Most of models of the design process have three to seven steps. If they contain more steps.

So far as I know. they have not published it.Vanguard Group The model on the following spread comes from the design team at the Vanguard Group. 83 .

AVIGATIONAL $IAGRAMS  #OMPLETE #ONCEPTUAL 4ESTING #REATE$ETAILED 7IREFRAMES !#4)6)4935--!29 #ONDUCTUSER RESEARCH $EVELOPUSER RESEARCHPLAN $EVELOPBUSINESS CASESUMMARY #REATEUSERPROFILES 2EFINEPROFILE MAPPINGTOSEGMENT STRATEGY (EAVYITERATIONOF REQUIREMENTS.Web development process after Vanguard Group (circa 1999) -AJORREVIEWPOINT 4EAMMUSTRECEIVE3ENIOR-ANAGEMENT APPROVALTOPROCEED 0(!3%30LANNING  )DEA #REATE"USINESS #ASEAND)NITIAL 3COPE 2EQUIREMENTS#ONCEPTUAL$ESIGN  #OMPLETE)NITIAL 5SER2ESEARCH  #REATE3ITE !RCHITECTUREAND #ONCEPTUAL $ESIGN  !NALYSIS$ESIGN  "EGIN &UNCTIONAL 2EQUIREMENTS  #REATE .

5%!$$WITHLESSONSLEARNED 7EBTEAM PARTICIPATIONAT BRAINSTORMING STAGEAND DURINGSTRATEGY FORMULATION 3EPARATEUSERGOALS BUSINESSSTRATEGY.AVIGATIONAL DIAGRAMS 0APERMOCK UPS 5SABILITYREPORT 7IREFRAMESITERATED 'AINBUSINESSBUY IN BEFOREENTERINGINTO COSTLYDESIGN DEVELOPMENTCYCLE "ALANCEBUSINESS OBJECTIVESANDUSER NEEDSEXPECTATIONS +EEP)MPORTANTTASKS WITHINAFEWCLICKS 5SABILITYEXPERTISE ALLOWSFORRAPID VALIDATION ADJUSTMENTOF ARCHITECTURE REQUIREMENTS %NSURETHATDESIGNIS SCALEABLEANDFLEXIBLE TOALLOWFORONGOING MAINTENANCE 6!. ARCHITECTUREAND DESIGN 2EFINETASKANALYSIS "EGINTASKANALYSIS #ONDUCTCOMPETITIVE ANALYSIS "UILDARCHITECTURE FROMCONTAINER RELATIONSHIPOUTLINE ANDMENTALMODELS )DENTIFYDETAILED CONTENTINVENTORY 2EFINEMENTALMODEL "EGINTOESTABLISH MENTALMODEL $EFINEGOALSAND OBJECTIVES #REATEOUTLINEOF CONTAINERSANDTHEIR RELATIONSHIPS -APDETAILEDCONTENT TOARCHITECTURE #ONDUCTGAPANALYSIS "EGINTOhTHUMBNAILv HIGH LEVELLOOKAND FEEL )DENTIFYANDPRIORITIZE KEYCONTENT #REATEhVISUALIZATIONv OFREQUIREMENTS )DENTIFYTOPTASKSFOR TESTING !UDITPAGESTO UNCOVERFUNCTIONAL ANDNON FUNCTIONAL REQUIREMENTS 6ALIDATEREQUIREMENTS ANDARCHITECTUREWITH USERS 0REPAREAPPROPRIATE MATERIALSFORTEST "EGINTOREFINE APPLYDESIGN STANDARDS #ONDUCTTESTS #REATERECOMMENDA TIONSBASEDON FINDINGS 6ALIDATIONOFCONCEPTS WITHTHEBUSINESS /540543 "USINESSCASE #LIENT)NTERVIEWS 2EPORTOFFINDINGS 3ITEARCHITECTURE DESIGNCONCEPTS 2EQUIREMENTS .

ANDTHENRECONCILE DISCREPANCIES )NVOLVETHERIGHT PEOPLEEARLYINTHE PLANNINGPROCESS #ONTROLCOMPLEXITY 5NDERSTANDUSER GOALSANDBEHAVIORS TOAVOIDLOWUSAGE #OHESIVETEAM ENVIRONMENTCREATES EFFICIENT.

INFORMED OUTPUTANDRAPID ITERATION 2EDUCESCOMPLEXITY TASKS.

LANGUAGE.

METAPHORS.

ETC #REATESCLARITYAROUND TASKS.

FOCUSESTHE EFFORT !SSISTSWITHBUSINESS PRIORITIZATIONREAL ESTATE (IGH LEVELTECHNOLOGY ASSESSMENT 84 !SSESDESIGN STANDARDSAND DETERMINEIF DIFFERENTIATIONIS NECESSARYANDWHY 4RANSLATIONOF COMPETITIVEANALYSIS TOCONCEPT -APARCHITECTURE BACKTOBUSINESS STRATEGYANDUSER GOALS #ONSIDERUSAGE REPORTING #LARIFYSCOPEAND FUNCTIONALITY #ONSIDERCROSS OVER EXPERIENCE "USINESSANALYSISOF TESTRECOMMENDA TIONS *UDGEMENTIN APPLYINGTHERIGHT USABILITYTECHNIQUES TOTHEPROJECT !LLOWBUSINESSTOSEE ANDPARTICIPATEINTHE EVOLUTIONOFTHESITE #ONSIDERERROR CONDITIONS !DDITIONALDESIGN STRATEGYSTANDARDS ANALYSIS .

#THROUGH TOELEVATION -ONITOR IMPROVEMENTS THROUGHDATA 5SABILITYREPORT $ESIGNSTRATEGY h3KINNEDPROTOTYPEv h3KINNEDPROTOTYPEv ITERATED 5SABILITYREPORT 0ROTOTYPE DOCUMENTATION $ATETRACKINGAN ANALYSIS 6/#0ARETOS 7EB5SAGE2EPORTS %RROR.)#%CALLS 0REDICTUSERINTEREST )NCORPORATINGMULTIPLE OPTIONSINTOTESTSTO REDUCECOMPLEXITYFOR THEUSER "USINESSANALYSISOF TESTRECOMMENDA TIONS )MPLEMENTADHERETO CHANGECONTROL PROCESS .OGS %XIT3URVEYS 74334RENDS .-AJORREVIEWPOINT 4EAMMUSTRECEIVE3ENIOR-ANAGEMENT APPROVALTOPROCEED 2EFINEMENTOF5)$ESIGN  #OMPLETE5SER 4ESTINGOF 7IREFRAMES  #REATE$ESIGN 3TRATEGY $ESIGN 'UIDELINE 3PECIFICATION 0REPARENEXTLEVELOF TASKSANDTEST MATERIALS !SSEMBLETHEDESIGN STRATEGYAND DOCUMENT #ONDUCTTEST 2EFINEANDAPPLYSITE SPECIFICDESIGN GUIDELINES 2EPORTUSABILITYTEST FINDINGS )NTERPRETFINDINGSAND MAKERECOMMENDA TIONS  "UILD-ONITOR)MPROVE   "UILD #OMPLETE5SER )NTERFACE #REATEDETAILED DESIGNFORALLUNIQUE INSTANCES #OMPLETE 4ESTINGOF&INAL 5SER)NTERFACE #ONDUCTFINALTESTING TOUNCOVERMAJOR FLAWS &OCUSTESTINGON UNIQUEINSTANCES #REATERECOMMENDA TIONSBASEDON FINDINGS )DENTIFYKEYCONTENT PLACE $ELIVER5) 3PECIFICATIONS AND2ELATED $OCUMENTATION #ONTINUOUS )MPROVEMENT %LEVATE 4EST &INALIZE5) SPECIFICATIONS PROTOTYPEOFUNIQUE INSTANCES 'ATHERDATA $ELIVERANDREVIEW5) WITHTHEDEVELOPMENT TEAM 5SE$-!)#TOIDENTIFY IMPROVEMENTS 5NCOVERISSUESAND DEFECTS 7ORKWITHBUSINESSTO SUBMIT3#2SAND PROJECTREQUESTS 6ALIDATEDESIGN STRATEGYWITHTHE BUSINESS &OLLOW3$.OOKANDFEELOFTHE SITEISBEING ESTABLISHEDAND VALIDATEDWITHKEY BUSINESS STAKEHOLDERS %VALUATIONOFPAGE LOADS -ANAGEBUSINESS FEEDBACKBYAREAOF EXPERTISEAVOID DESIGNBECOMINGTHE FOCUSVERSUSCONTENT (IGHDEGREEOFDESIGN BUSINESSITERATION #REATEASITETHAT hHANGSTOGETHERv #OVERINGALL POSSIBILITIESTHROUGH UNIQUEINSTANCES &INALCHECKPOINTWITH USERSTOVALIDATETHE EXPERIENCEDESIGN.

ARCHITECTURE.

CONTENT.

ANDUSABILITY &INALIZETEMPLATEFOR USAGEREPORTING #ONTINUAL IMPROVEMENTOF DOCUMENTATIONTO CREATEEFFICIENCIES BETWEENDESIGNAND DEVELOPMENT 4HOROUGHATTENTIONTO INTEGRATIONTEST 1UALITYANDCONTROL ASSESSMENTBY DESIGNTEAMINTHE INTEGRATIONREGION 0AGEPERFORMANCE ANALYSISAND TROUBLE SHOOTING $ETAILEDANALYSISOFALL DATA0#%.

6/#.

752.

7)33.

06#3 4RACKER.

2ESEARCH.

ETC 6/#ANALYSIS 65%PROJECTS 0RIORITIZATIONOF ENHANCEMENTSWITH THEBUSINESS .OOKFORCOMPATIBILITY ACROSSBROWSERS.

/3.

ANDDOWNLOADS.

ETC 85 .

Programmers make this approach worse by picking or negotiating their way through the list. a list of features often becomes the de facto product plan. no additional material or manufacturing costs restrain feature creep. Kim Goodwin.Alan Cooper Few people are good computer programmers and also good interaction designers. Cooper points out. The first two were first published in the AIGA journal. often trading features for time. and Robert Reimann. Thus. including Dave Cronin. 86 Cooper advocates five significant changes to conventional methods of software development in his goal-directed design process: 1) Design first. The second two have not been published previously. Give that user a name and an environment and derive his or her goals. 3) Hold designers responsible for product quality and user satisfaction. 4) Invent on specific user for your product—a persona. About Face: The Essentials of User Interface Design (1995) and The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity (1999). In the traditional software development process. Gain. . 5) Work in teams of two: designer and design communicator I developed the diagrams that follow based on a series of conversations with Cooper and members of his staff. David Fore. the cost of adding one more new feature is almost nothing. many people inside a company—and oftentimes customers as well—ask for features. Cooper’s favorite topic is what’s wrong with the software that increasingly fills our lives and how it came to be so bad. it’s hard to know when a product is complete. Jonathan Korman. He holds forth on the subject in two books. Cooper’s argument is as follows: In software. In summary. The trouble is: Each additional feature makes the product more complicated to understand and more difficult to use. program second. 2) Separate responsibility for design from responsibility for programming. In such a process. Alan Cooper is one.

They began writing and selling software for personal computers.000 from his dad and started a company with his high-school friend. 0ROGRAMMERS /RIGINALLY. as Cooper saw it. Keith Parsons. Cooper borrowed $10. The diagram below describes the evolution of the software development process from the beginning of the personal computer industry to the present.Evolution of the software development process after Alan Cooper (2001) In 1975.

PROGRAMMERSDIDITALL )NTHEEARLYDAYSOFTHE0#SOFTWAREINDUSTRY.

SMARTPROGRAMMERSDREAMEDUPUSEFULSOFTWARE.

WROTEIT.

ANDEVENTESTEDITONTHEIROWN!STHEIR BUSINESSESGREW.

THEBUSINESSESANDTHE PROGRAMSBECAMEMORECOMPLICATED #ODE4EST -ANAGERS -ANAGERSBROUGHTORDER )NEVITABLY.

PROFESSIONALMANAGERSWEREBROUGHT IN'OODPRODUCTMANAGERSUNDERSTANDTHE )NITIATE MARKETANDCOMPETITORS4HEYDEFINESOFTWARE PRODUCTSBYCREATINGREQUIREMENTSDOCUMENTS /FTEN.

HOWEVER.

REQUIREMENTSARELITTLEMORETHAN ALISTOFFEATURES.

ANDMANAGERSFINDTHEMSELVES HAVINGTOGIVEUPFEATURESINORDERTOMEETSCHEDULES 3HIP 0ROGRAMMERS #ODE4EST 3HIP 4ESTINGBECAMEASEPARATESTEP !STHEINDUSTRYHASMATURED.

TESTINGHAS BECOMEASEPARATEDISCIPLINEANDASEPARATE STEPINTHEPROCESS4ODAY.

ITSCOMMONTO FINDTESTERFOREVERYORPROGRAMMERS 4HISCHANGEILLUSTRATESTHATTHEPROGRAMMERS ROLEISNOTFIXEDBUTSTILLEVOLVING -ANAGERS 0ROGRAMMERS 1! )NITIATE #ODE 4EST 4ODAY.

COMMONPRACTICEISTOCODE ANDDESIGNSIMULTANEOUSLY )NTHEMOVEFROMCOMMAND LINETOGRAPHICAL USERINTERFACE.

DESIGNERSBECAMEINVOLVEDIN THEPROCESSˆTHOUGHOFTENONLYATTHEEND 4ODAY.

COMMONPRACTICEISFORSIMULTANEOUS CODINGANDDESIGNFOLLOWEDBYBUGANDUSER TESTINGANDTHENREVISION -ANAGERS 0ROGRAMMERS 1! )NITIATE #ODE $ESIGN "UG4EST 5SER4EST $ESIGNERS 5SABILITY&OLKS #OOPERINSISTSTHATDESIGN PRECEDEPROGRAMMING )N#OOPERSGOAL DIRECTEDAPPROACHTO SOFTWAREDEVELOPMENT.

ALLDECISIONSPROCEED FROMAFORMALDEFINITIONOFTHEUSERANDHISOR HERGOALS$EFINITIONOFTHEUSERANDUSERGOALS ISTHERESPONSIBILITYOFTHEDESIGNERˆTHUS DESIGNPRECEDESPROGRAMMING -ANAGERS $ESIGNERS 0ROGRAMMERS 1! )NITIATE $ESIGN #ODE "UG4EST 5SER4EST 3HIP 3HIP 3HIP 5SABILITY&OLKS 87 .

Goal-directed design process after Alan Cooper (2001) 5SERS #OOPERPUTSUSERGOALSATTHECENTEROF THESOFTWAREDESIGNPROCESS4HATPROCESS ISPARTOFASERIESOFOFFICEPRACTICESWHICH DEPENDONTHETALENTANDSKILLSOFDESIGNERS ANDONTHEIRAPPLICATIONOFPRINCIPLESAND PATTERNSTHROUGHOUTTHEPROCESS PROVIDEINPUTTO 0RIMARYRESPONSIBILITY 4HISDIAGRAMSHOWSTHEPROCESSPROCEEDING INSTEPSFROMLEFTTORIGHT)TLEAVESOUTFEED BACKLOOPSANDITERATIONWHICHARENECESSARY FORPRODUCINGGOODWORK 2ESEARCHAND!NALYZE FOCUSINTHEFIRSTHALF.

CONTINUINGTHROUGHOUT !CTIVITY 2ESULT !RTIFACT $ESIGNERS INSUREFINANCIALSUCCESS )NITIATE $ESIGN /PPORTUNITIES.

#ONSTRAINTS.

AND#ONTEXT 7HOWILLUSETHEPRODUCT 7HATPROBLEMWILLITSOLVEFORTHEM $EFINEINTENTAND CONSTRAINTSOFPROJECT 2EVIEWWHATEXISTS EGDOCUMENTS $ISCUSSVALUES.

ISSUES.

OTES #HALKTALK EARLYFINDINGS #HALKTALKWITH MANAGEMENT POTENTIALUSERS THEIRACTIVITIES THEIRENVIRONMENTS THEIRINTERACTIONS THEIROBJECTSTOOLS AEIOUFRAMEWORKFROM 2ICK2OBINSON.OTES .EXPECTATIONS !PPLYETHNOGRAPHIC RESEARCHTECHNIQUES 3COPE !UDIT )NTERVIEWS /BSERVATIONS 0ERSONAS DESIREDOUTCOMES TIMECONSTRAINTS FINANCIALCONSTRAINTS GENERALPROCESS MILESTONES 3COPEMAYBE LOOSEORTIGHT BUSINESSPLAN MARKETINGPLAN BRANDINGSTRATEGY MARKETRESEARCH PRODUCTPLAN COMPETITORS RELATEDTECHNOLOGY MANAGEMENT DOMAINEXPERTS CUSTOMERS PARTNERS SALESCHANNEL 4HISSTEPLEADSTO APROJECTMANDATE USEPATTERNS 0ROJECT"RIEF 3UMMARY )NSIGHTS 4APES 4RANSCRIPTS 3UMMARY )NSIGHTS )NTERVIEWS -EETINGS "RIEFING 88 PROVIDEMANDATETO -ANAGERS $EFINETYPICAL USERS $EDUCEWHAT USERSWANT LEADTO 'OALS PRIMARY SECONDARY SUPPLEMENTAL NEGATIVE SERVEDINDIRECTLY PARTNER CUSTOMER ORGANIZATIONAL LIFE END EXPERIENCE 4APES 4RANSCRIPTS 3UMMARY )NSIGHTS .

3APIENT $ESIGN/FFICE0RACTICES $ESIGNER4ALENTAND3KILLS 4HEWAYTHEOFFICEISSETUPANDRUNnTHEENVIRONMENT.

THESPOKENANDUNSPOKENRULESnAFFECTTHEWORK #OOPERSSTAFFDESCRIBESSEVERALKEYPRACTICES GOAL DIRECTEDDESIGNPROCESS COLLABORATIVEENVIRONMENTANDCOMMONPURPOSE $$#TEAMSTRUCTURESEESEPARATEDIAGRAM EGOLESSDESIGN APPROPRIATENESSOFASSIGNMENTS COMMITMENTTOEDUCATION COMMITMENTTOENHANCEPROCESS ASSESSMENTANDSELF ASSESSMENT !DESIGNERSNATIVEABILITIESANDBACKGROUNDALSOAFFECT THEWORK#OOPERLOOKSFORPEOPLEWITHTHESESKILLS ANALYTIC EMPATHIC CONCEPTUAL INTERPERSONAL VISUAL BRAINSTORMING WRITTEN IMAGINATION COMMUNICATIONS PERSONAL PRACTICAL CORPORATE FALSE .

PROVIDEFEEDBACKONUSABILITYTO 5SERS PROVIDEBUGREPORTSTO PROVIDESPECTO 0ROGRAMMERS INSURECUSTOMERSATISFACTION PROVIDECODETO INSUREPERFORMANCE #ODE 1! CERTIFYPRODUCTFORRELEASE 3OFTWAREDEVELOPMENTPROCESS INSURERELIABILITY 4EST 3HIP 4HEGOAL DIRECTEDDESIGNPROCESSTAKESPLACEWITHINALARGERSOFTWAREDEVELOPMENTPROCESS 3YNTHESIZEAND2EFINE &ORM.

-EANING.

AND"EHAVIOR ONGOINGTHROUGHOUT.

FOCUSINTHESECONDHALF 7HATISIT (OWWILLITBEHAVEFORUSERS )MAGINEASYSTEMTO HELPUSERSREACHGOALS DRIVE #ONCEPT $ERIVECOMPONENTS BASEDONUSERS /RGANIZETHE COMPONENTS 2EFINEDETAILS DESCRIBEMODELS 3CENARIOS %LEMENTS &RAMEWORK 3PEC DAY IN THE LIFE KEY PATH ERROR SET UP INFORMATIONOBJECTS FUNCTIONALOBJECTS CONTROLMECHANISMS OBJECTRELATIONSHIPS CONCEPTUALGROUPINGS PATTERNS LOGICNARRATIVEFLOW NAVIGATIONSTRUCTURE APPEARANCE LANGUAGE FLOWBEHAVIOR PRODUCTCHARACTER PRODUCTSTORY &ORMAL$OCUMENT 0ROBLEM3TATEMENT 6ISION3TATEMENT .OTES 3TORYBOARDS .ISTS 3KETCHES $IAGRAMS (IGH LEVELDATAMODELS 3KETCHES &LOW$IAGRAMS &ORMAL$OCUMENT $EMONSTRATION 0ROTOTYPE 0RESENTATION #HALKTALKWITH PROGRAMMERS 0RESENTATION PROBLEMDEFINITION SPARK VISIONDEFINITION INFORM DESIGNIMPERATIVES MOTIVATE -AYREQUIRECHANGES INSCOPE FILTER 4ELLSTORIESABOUT USINGTHESYSTEM ORGANIZE PRIORITIZE INFLECT VALIDATE 4HROUGHOUTTHEGOAL DIRECTEDDESIGNPROCESS.

DESIGNERSAPPLYOTHERPRACTICES.

THEIRTALENTANDSKILLS.

ASWELLASPRINCIPLESANDPATTERNS $ESIGN0RINCIPLES $ESIGN0ATTERNS 0RINCIPLESGUIDETHECHOICESDESIGNERSMAKEASTHEY CREATE0RINCIPLESAPPLYATALLLEVELSOFDESIGNFROMBROAD CONCEPTTOSMALLDETAIL&OREXAMPLE $ONOHARM(IPPOCRATES -EETUSERGOALS #REATETHESIMPLESTCOMPLETESOLUTION/CKHAM.

&ULLER #REATEVIABLEANDFEASIBLESYSTEMS $ESIGNPATTERNSARERECURRINGFORMSORSTRUCTURESWHICH DESIGNERSMAYRECOGNIZEORAPPLYnDURINGANALYSISAND ESPECIALLYDURINGSYNTHESIS#HRISTOPHER!LEXANDER.

h!0ATTERN.ANGUAGE.

vPROVIDESEXAMPLESOFPATTERNSFOR ARCHITECTURE#OOPERCOLLECTSPATTERNSFORSOFTWARE INTERACTION&OREXAMPLE.

ACOMMONPATTERNISDIVIDINGA WINDOWINTOTWOPANESTHELEFTSMALLERPANEPROVIDESTOOLS ORCONTEXTANDTHERIGHTLARGERONEPROVIDESAWORKING SPACEORDETAILS 89 .

His view of how architecture should be practiced provides a model for how he believes software development should be practiced. architects determine what the CLIENTS DEMONSTRATE ARTICULATE building will be like (how it will “behave”). engineering. architecture has fascinated Cooper. Cooper organized the process of developing a building into three domains: architecture. engineers determine how to make the building stand up. the builders execute the architect’s and engineer’s plans. And finally.Idealized process of developing buildings after Alan Cooper (2004) Since high school. architects serve their clients and consult with engineers and builders on what is possible and practical. In his view. Based on the architect’s plans. and construction. Obviously. NEEDS GOALS AREOBSERVEDBY ARCHITECTS DESIGN FORMS CREATINGPOTENTIALUSESFOR REPRESENTEDINPLANS DESIGN STRUCTURES ENSURINGSTABILITYANDSAFETYFOR REPRESENTEDINPLANS BUILD BUILDINGSFOR PROVIDEABASISFOR ENGINEERS GUIDE BUILDERS AREASSESSEDBY INSPECTORS MAYISSUE MAYREFUSE WHICHREQUIRESCORRECTIONSFROM 90 PERMITS WHICHALLOWOCCUPANCYBY ACCORDINGTOBUILDINGCODES .

to consult with engineers to understand what’s possible. the programmers write real code to execute the interaction designer’s and engineer’s plans. DEMONSTRATE ARTICULATE NEEDS GOALS DESIGN FORMS BEHAVIORS DESIGN PROGRAMSTRUCTURES AREOBSERVEDBY INTERACTIONDESIGNERS CREATINGPOTENTIALUSESFOR REPRESENTEDINPLANS PROVIDEABASISFOR ENGINEERS VERIFIEDBYSMALLPROTOTYPES REPRESENTEDINSPECIFICATIONS WHICHAREIMPLEMENTEDBY PROGRAMMERS WRITE CODEWHICHISUSEDBY ISASSESSEDBY TESTERS FIND BUGS WHICHREQUIRECORRECTIONSFROM 91 . Based on the interaction designer’s plans. Here too. Cooper acknowledges the need for feedback—for interaction designers to observe users to understand their goals. engineers determine how to make the software work by writing many very short test programs—but no final code. They like to create and don’t want to be told what to do. Cooper distinguishes engineers from programmers.Idealized process of developing software After Alan Cooper (2004) Following his ideal model of architecture. don’t like ambiguity. Interaction designers determine what the software will be like (how it will “behave”). Cooper warned. and USERS finally to consult with programmers to answer questions as they program. engineering. According to him. he suggested. Cooper advocated organizing the process of developing software into three domains: interaction design. and programming. And finally. engineers like to figure out how to solve problems. They like to code and simply want to know what the code is suppose to do. Programmers. putting an engineer in a programming job or a programmer in an engineering job is a recipe for unhappiness.

“Each design-project has an individual history which is peculiarly its own.Morris Asimow Asimow defines morphology of design as “the study of the chronological structure of design projects. “design by evolution. Design is [also] an iterative problem-solving process. . Nonetheless. Jones. Ulm 10/11 (1964). products are designed de novo. “Now more frequently than ever in the past.Planning for production . particularly those which can be met by the technological factors of our culture. Tomas Maldonado and Gui Bonsiepe introduced it to the design and architecture community.revision .evaluation .” from “design by innovation.” He notes.” describing these steps” . distinguishes craft-based design. a sequence of events unfolds in a chronological order forming a pattern which.decision .Planning for retirement Asimow. .” Two years after Asimow first published his model. . is common to all projects. by and large. Asimow devotes more than 50 pages to describing engineering design and the design process. .optimization .Preliminary design . As a profession. “Design is a progression from the abstract to the concrete. as a project is initiated and developed.synthesis . Engineering is largely concerned with design.) He likened the design process (horizontal) to “the general problem solving process.” and suggests this creates greater risk and complexity and thus implies the need for new design tools (the subject of his book. He defines engineering design as “a purposeful activity directed toward the goal of fulfilling human needs.)” In Introduction to Design.Planning for consumption .” Asimow defines the phases of a project (vertical) as .” He continues. like Alexander. . (This gives a vertical structure to a design project. What distinguishes the objects of engineering design from those of other design activities is the extent to which technological factors must contribute to their achievement.Planning for distribution . .” He notes. and Doblin.analysis .Detailed design .implementation 92 According to Rowe (1987).Feasibility study .) . Asimow was “an industrial engineer prominent in the 1950s and 1960s. including it in their seminal article “Science and Design” published in the journal. (This gives a horizontal structure to each design step.

EEDS!NALYSIS 6ALID 3TEP $ESIRED/UTPUTS 3TEP $ESIGN0ROBLEM 2ELEVANT  4ECH )NFO 3YSTEM)DENTIFICATION %NGR3TATEMENT OF0ROBLEM #REATIVE 4ALENT $ESIGN#ONCEPTS 0LAUSIBLE  3TEP 3YNTHESIS !LTERNATIVE3OLUTIONS 3TEP 0HYSICAL2EALIZABILITY 0HYSICAL!NALYSIS 4ECH +NOWL %CONOMIC!NALYSIS 0AY 0OSSIBLE  2EALIZABLE3OLUTIONS %CON &ACTORS 3TEP %CONOMIC7ORTH 7ORTHWHILE3OLUTIONS 3TEP &INANCIAL&EASIBILITY &INANCE &ACTORS &INANCIAL!NALYSIS -ONEY  3ETOF5SEFUL3OLUTIONS 3YMBOLOGY 0ROCESS )NFO 3OURCE /UTCOME $ECISION )TERATIVEORFEEDBACKLOOP 93 .Morphology of design (1 of 3) after Morris Asimow (1962) 0HASE&EASIBILITY3TUDY -ARKET )NFO .

AB 4ECHNIC 4ESTING 7ORK  4EST2ESULTS 3TEP "ETTER !CCEPTED0ROPOSAL 94 3IMPLIFICATION %XPER IENCE 3TEP .Morphology of design (2 of 3) after Morris Asimow (1962) 0HASE0RELIMINARY$ESIGN %XP 4ECHN 3ELECTIONOF $ESIGN#ONCEPT "EST 3TEP 4ENTATIVE3ELECTION 3TEP 6ALID -ATHEMATICAL !RCHETYPES %NGR 3CIENCE 3ENSITIVITY!NALYSIS 7HICH !NALYTICAL&ORMULATION -ATH !NALYSIS 3TEP 3ENSITIVE0ARAMETERS 3TEP &IT #OMPATIBILITY!NALYSIS 4ECH )NFO 3TABILITY!NALYSIS 3TABLE !DJUSTED0ARAMETERS -ATH 4EST 3TEP !DJUSTED&OR3TABILITY 3TEP "EST /PTIMIZATION -ATH 0ROJECTION)NTO&UTURE 4IME /PTIMUM 4RENDS 3TEP "EHAVIOR/VER4IME 3TEP 0ERFORM  0REDICTIONOF"EHAVIOR -ATH 4EST %XPECTED0ERFORMANCE .

Morphology of design (2 of 3) after Morris Asimow (1962) 0HASE$ETAILED$ESIGN %XPER IENCE 0REPARATION&OR$ESIGN 6ALID 3TEP "UDGET/RGANIZATION 3TEP 'OOD $ESCRIPTION 3UBSYSTEMS 4ECHN +NOWL $ESCRIPTION #OMPONENTS 'OOD 3UBSYSTEM#ONCEPTS 4ECHN +NOWL 3TEP #OMPONENT#ONCEPTS 3TEP 'OOD $ESCRIPTIONOF0ARTS 4ECHN +NOWL !SSEMBLY$RAWINGS &IT 3PECIFICATIONS AND$RAWINGS 4ECHN %XPER 3TEP #OMPLETE$ESCRIPTIONS 3TEP 0RODUCE IBLE %XPERIMENTAL #ONSTRUCTION 3HOP 0RODUCT4EST0ROGRAM $OES )T7ORK  0ROTOTYPE .AB 3TEP 4EST$ATA 3TEP 'OOD !NALYSIS0REDICTION -ATH !NALYSIS 2EDESIGN "ETTER $ETECTED&LAWS 4ECHN +NOWL 3TEP )MPROVED$ESIGN 95 .

After all. “The fact is that being systematic is not necessarily synonymous with being automated. then the problem is not. see page 18.) This section presents three models from Archer. as far as I know. Alexander. by definition. it became a goal in itself. the whole process of design. Rowe (1987) notes that at Ulm. if the solution to a problem arises automatically and inevitably from the interaction of the data.” He calls out four authors as especially important: Jones. (Rittel came to see design as a process of argumentation aimed at coming to agreement on goals. then it follows that neither the designer nor his client (nor. a design problem. could be clearly and explicitly stated. “speculation moved beyond description and explanation of design behavior and into the realm of idealization. Not only was the possibility of a ‘scientific’ and totally objective approach toward design seriously entertained. relevant data gathered.” 96 Archer’s statements about the design process contradict Rowe’s critique. “When all has been said and done about defining design problems and analyzing design data.Bruce Archer Cross (1984) notes.” Archer continues. see pages 56-59. If we accept that value judgments cannot be the same for all people. and Rittel.) Archer taught at both the Royal College of Art (RCA) in London and the Hochschule für Gestaltung in Ulm (HfG Ulm). it was believed. Archer. eventually. there still remains the real crux of the act of designing—the creative leap from pondering the question to finding a solution. systematic design procedures. the user) can abdicate the responsibility for setting up his own standards. A confident sense of rational determinism prevailed. and an ideal artifact produced.” . for more on Alexander. . he presented no staged or procedural models of design. “One of the first tasks attempted by the design methodologists was the development of new. . . Similarly. parameters established. (For more on Jones. there is no escape for the designer from the task of getting his own creative ideas. for all places or all time.

rockets and remote controlled instruments have turned to cybernetics for inspiration.) $ISCERN@SOMETHINGWRONG (EIGHTENALERTNESSANDLOCATETHEAREAOFDISTURBANCE "RINGAPPROPRIATESENSEORGANSTOBEAR %VALUATEEVIDENCEANDCOMPAREWITHPREVIOUSEXPERIENCES 0OSTULATEAPOSSIBLECAUSEFORTHEDISTURBANCE 2ECALLEXPERIENCEWITHSIMILARANDORANALOGOUSCAUSES 0REDICTCONSEQUENCEOFSUGGESTEDCAUSE &ORMULATECOURSESOFACTIONPOSSIBLEINRESPONSETOSUCHACAUSE 2ECALLEXPERIENCEWITHSIMILARANDORANALOGOUSCOURSEOFACTION 0REDICTCONSEQUENCESOFEACHSUGGESTEDCOURSEOFACTION 3ELECTCOURSEOFACTIONTOBEFOLLOWED !CT $ISCERNEFFECTOFACTION 2ECALLEXPERIENCEWITHSIMILARANDORANALOGOUSEFFECTS 2EPEATFROMUNTILEQUILIBRIUMISRESTORED 97 . See models from cybernetics on pages 117-118. designers of highly complicated control systems for machine tools. “The study of control mechanisms of living organisms is called cybernetics. an ancient philosophical study of the method of intellectual discovery which has been revitalized recently by Professor [George] Polya of Stanford University.” “The method for solving design problems set out in this article owes something to both the heuristic and the cybernetic approaches.Biological sequence of problem solving after Bruce Archer (1963-1964) Archer notes the similarity of biological response mechanisms and problem solving in computer programming and design.” “A further line of thinking which does not quite fall into this pattern but which has contributed to the development of systematic methods for designers is the ‘heuristic’.” (See Polya’s model on page 36. USA. And he explicitly links these processes to cybernetics. aeroplanes. In recent times.

Regarding the procedure.g.Basic design procedure after Bruce Archer (1963-1964) This diagram was reprinted in the journal Ulm (1964) and several other places. 2000) and Rowe (1987). Archer proposed this model as representative of an emerging “common ground” within the “science of design method” even while acknowledging continuing “differences”. with frequent returns to early stages when difficulties are encountered and obscurities found. “The practice of design is thus a very complicated business.” He continues. “In practice. he points out. the harder the job of the designer will get. The more sophisticated the demands of function and marketing become. the stages are overlapping and often confused.. Already it has become too complicated for the designer to be able to hold all the factors in his mind at once. involving contrasting skills and a wide field of disciplines. It has always required an odd kind of hybrid to carry it out successfully. Cross (1984.” 4RAINING !NALYTICAL0HASE "RIEF 0ROGRAMMING %XPERIENCE /BSERVATION -EASUREMENT )NDUCTIVE2EASONING $ATA#OLLECTION !NALYSIS #REATIVE0HASE 3YNTHESIS %VALUATION *UDGMENT $EDUCTIVE2EASONING $EVELOPMENT %XECUTIVE0HASE 98 3OLUTION #OMMUNICATION $ESCRIPTION 4RANSLATION 4RANSMISSION . e.

#HECK.ISTFOR0RODUCT$ESIGNERS &ORWARD3UMMARY 4HECHECKLISTWHICHACCOMPANIEDTHEORIGINALSERIESOFARTICLESIN $ESIGNWASREGARDEDBYTHEAUTHORASTHEEMBODIMENTOFA HYPOTHESISONTHESTRUCTUREOFTHEDESIGNACT3INCETHISWAS PUBLISHED.

FURTHERFUNDAMENTALSTUDYHASBEENUNDERTAKEN 4HEFOLLOWINGCHECKLISTISTHUSPRESENTEDASASECONDHYPOTHESIS.

EVERTHELESS. WHICHTHEAUTHORRECOGNIZESASSTILLNAIVEINPLACES)TISNOT INTENDEDTOBEREADASANARRATIVE.

STUDYOFTHE SUMMARYBELOWMIGHTBEUSEFULINPRESENTINGANOVERALLPICTUREOF DESIGNPROCEDURE4HEREMAINDEROFTHECHECKLISTISOFFEREDASA DESIGNTOOL.

CALCULATEDTOBEUSEFULINTHECONTROLOFMOSTNORMAL PRODUCTDESIGNPROJECTS (OWTOUSECHECKLISTANDARROWDIAGRAMS 4HECHECKLISTHASBEENSETOUTINTHEFORMOFALISTOFACTIVITIESAND EVENTSACCORDINGTOTHECONVENTIONSOFNETWORKANALYSIS )TISSUGGESTEDTHATTHEDIAGRAMAPPROPRIATETOTHEPHASEWHICHHAS BEENREACHEDINTHEDESIGNPROJECTINQUESTIONSHOULDBEMOUNTED ONTHEWALLADJACENTTOTHEDESIGNERgSDRAWINGBOARD!STHEWORK PROGRESSES.

THEDESIGNERSHOULDIDENTIFYEVENTSINTHECHECKLISTAS THEYTAKEPLACE.

ANDTICKTHEMOFFONTHEDIAGRAM4HELINKSINTHE DIAGRAMSHOWWHATMUSTBEDONENEXT4ARGETDATESANDOR ESTIMATEDWORKINGHOURSCANBEADDEDWHEREAPPROPRIATE 0HASE 0RELIMINARIES 2ECEIVE%NQUIRY %VALUATE%NQUIRY %STIMATE/FFICE7ORK.OAD 0REPARE0RELIMINARY2ESPONSE 0HASEn2ECEIVEBRIEF.

ANALYZEPROBLEM.

PREPAREDETAILEDPROGRAMMEANDESTIMATE "RIEFING 2ECEIVE)NSTRUCTIONS $EFINE'OALS $EFINE#ONSTRAINTS 0ROGRAMMING %STABLISH#RUCIAL)SSUES 0ROPOSE!#OURSE/F!CTION 0HASEn#OLLECTDATA.

PREPAREPERFORMANCEORDESIGN SPECIFICATION.

REAPPRAISE.

EEDS 3ELECT#OMMUNICATION-EDIUM 0REPARE#OMMUNICATION 7INDING5P 7IND5P0ROJECT #LOSE2ECORDS 99 .PROPOSEDPROGRAMMEANDESTIMATE $ATA#OLLECTION 2ECEIVE)NSTRUCTIONS #OLLECT2EADILY!VAILABLE)NFO #LASSIFY!ND3TORE$ATA !NALYSIS )DENTIFY3UB PROBLEMS !NALYZE3UB PROBLEMS!BOUT%NDS 0REPARE0ERFORMANCE3PECIFICATION 2EAPPRAISE0ROGRAM!ND%STIMATE 0HASEn0REPAREOUTLINEDESIGNPROPOSALS  3YNTHESIS 2ECEIVE)NSTRUCTIONS 2ESOLVE2EMAINING0ROBLEMS!BOUT%NDS 0OSTULATE-EANS&OR2ECONCILING$IVERGENT$ESIDERATA)N0ERFORMANCE3PECIFICATION $EVELOP3OLUTIONS)N0RINCIPLETO0ROBLEMS!BOUT-EANS!RISING&ROM0ERFORMANCE3PECIFICATION 0OSTULATE/UTLINE/VERALL3OLUTIONS 0HASEn$EVELOPPROTOTYPEDESIGNS  $EVELOPMENT 2ECEIVE)NSTRUCTIONS $EFINE$ESIGN)DEA %RECT!+EY-ODEL $EVELOP3UB PROBLEM-UTUAL3OLUTION $EVELOP/VERALL3OLUTIONS 0HASEn0REPAREANDEXECUTE VALIDATIONSTUDIES $EVELOPMENT#ONTINUED 6ALIDATE(YPOTHESES 0HASEn0REPAREMANUFACTURINGDOCUMENTATION #OMMUNICATION $EFINE#OMMUNICATION.

%XPLANATION )NTHEDIAGRAMS.

TIMEFLOWSFROMLEFTTORIGHTACROSSTHEPAGE.

EACH ARROWREPRESENTSANON GOINGACTIVITY.

WHICHTAKESAGREATERORLESSER AMOUNTOFTIME(OWEVER.

THEREISNOTATTEMPTTOMAKETHELENGTHOF THEARROWPROPORTIONALTOTHETIMETAKENBYTHEACTIVITY4HECIRCLESAT EACHENDOFTHEARROWREPRESENTTHEEVENTSWHICHOPENANDCLOSEAN ACTIVITY%VENTSOCCURATANINSTANTINTIME.

OAD 0REPARE0RELIMINARY2ESPONSE 4HECONVENTIONSDESCRIBEDARECOMMONTOVARIOUSFORMSOFNETWORK ANALYSIS.RATHERTHANOVERAPERIOD OFTIME3OMETIMESMORETHANONEACTIVITYISREQUIREDTOCOMPLETE ANEVENT3OMETIMESANEVENTPERMITSMORETHANONEACTIVITYTO COMMENCE%VENTSWITHTHESUFFIXNMUSTBEREPEATEDANUMBEROF TIMESFORDIFFERENTSUB PROBLEMS 0HASE 0RELIMINARIES 2ECEIVE%NQUIRY %VALUATE%NQUIRY %STIMATE/FFICE 7ORK.

OAD 3URVEY%XISTING!ND0ROJECTED0ROGRAMMED %STIMATE-ANPOWER!VAILABILITY       3URVEY/F/FFICE7ORKLOAD2EADY %STIMATE/F-ANPOWER!VAILABILITY2EADY       0REPARE0RELIMINARY2ESPONSE "REAK$OWN4ASK$ESCRIBED5NDER)NTO!N/UTLINE0ROGRAM -ATCH/UTLINE0ROGRAM7ITH-ANPOWER!VAILABILITY%STIMATE3ET/UT5NDER 0REPARE0RELIMINARY%STIMATE/F#OSTS &ORMULATE!$RAFT0ROPOSAL #HECK$RAFT0ROPOSAL%STIMATE )F.FOREXAMPLECRITICALPATHPLANNINGAND0%24 +EY  %VENT  2EPEATED%VENT N  !CTIVITY #ARRY&ORWARD  2EPEAT)F.IMITATIONS)MPOSED    2EPORT/N%VALUATION/F%NQUIRY2EADY    %STIMATE/FFICE7ORK.ECESSARY &ROM%VENT)NDICATED  7AITING4IME          )TEM !CTIVITY  0RELIMINARIES      !CTIVITY.O %VENT 2ECEIVE%NQUIRY 3END!CKNOWLEDGMENT /PEN0ROJECT&ILE #OMMENCE#HART&OR2ECORDING0ROGRESS          %NQUIRY2ECEIVED !CKNOWLEDGMENT$ISPATCHED 0ROJECT&ILE!ND0ROGRESS-ACHINERY2EADY        %VALUATE%NQUIRY&OR%XAMPLE  )DENTIFY!UTHORITY4O7HOM!NSWERABLE )DENTIFY4YPE/F4ASK )DENTIFY#LASSOF0RODUCT $EFINE&ORM/F3UBMISSION2EQUIRED $EFINE!NY&ACILITY/R&REE3TRUCTURE/FFERED $EFINE!NY0ROGRAM.ECESSARY.

2EITERATE&ROM5NTIL!3ATISFACTORY0ROPOSAL)S$RAFTED 0REPARE!ND$ISPATCH&AIR#OPY/F0ROPOSAL!ND%STIMATE "RING&ILE!ND0ROGRESS-ACHINERY5P TO DATE            /UTLINE0ROJECT0ROGRAM2EADY   $RAFT0ROPOSAL!ND%STIMATE2EADY $RAFT0ROPOSAL!ND%STIMATE!PPROVED .

  .

    0ROPOSAL!ND%STIMATE$ISPATCHED &ILES!ND0ROGRESS-ACHINERY5P4O$ATE   2EITERATE3ECTION5NTIL!GREEMENT)S!CHIEVED/N!#OMMISSION4O#ARRY/UT0HASE 2ECEIVE"RIEF.

!NALYZE0ROBLEM.

0REPARE$ETAILED0ROGRAM!ND%STIMATE.

/R5NTIL 0ROJECT)S!BANDONED 100  .

0HASE "RIEFING 0ROGRAMMING 2ECEIVE)NSTRUCTIONS $EFINE'OALS $EFINE #ONSTRAINTS %STABLISH#RUCIAL)SSUES 0ROPOSE!#OURSE/F!CTION         N    N             )TEM !CTIVITY  "RIEFING !CTIVITY.O %VENT     2ECEIVE)NSTRUCTIONS 3END!CKNOWLEDGMENT "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE -AKE!RRANGEMENTS&OR&ORMAL"RIEFING     .

.

        #OMMISSION2ECEIVED4O%XECUTE0HASE !CKNOWLEDGMENT$ISPATCHED &ILE!ND0ROGRESS-ACHINERY5P4O$ATE !RRANGEMENTS#OMPLETE&OR&ORMAL"RIEFING    $EFINE'OALS&OR%XAMPLE  $EFINE#LIENTgS#ORPORATE0OLICY.

4RADING0OLICY.

0ROJECT!IMS.

0ROBLEM!IMS.

OW.)DENTIFY2EASONS&OR %XAMINING0ROBLEM.

ATIONAL#ONSTRAINTS.$EFINE$ESIGN'OALS    $EFINITION/F'OALS#OMPLETE    $EFINE#ONSTRAINTS&OR%XAMPLE  )DENTIFY!NY.

!NY4RADE#ONSTRAINTS.

!NY-ANDATORY#OMPANY#ONSTRAINTS.

!NY#ONTRACTUAL#ONSTRAINTS.

"UDGETARY#ONSTRAINTS.

-ARKETING#ONSTRAINTS.

-ANUFACTURING #ONSTRAINTS.

!NY/THER#ONSTRAINTS    $EFINITION/F#ONSTRAINTS#OMPLETE  0ROGRAMMING     %STABLISH#RUCIAL)SSUES !NALYZE'OALS2ECORDED5NDER!ND$EFINE#RITERIA&OR-EASURING3UCCESS !NALYZE#ONSTRAINTS)DENTIFIED5NDER!ND$EFINE&IELD!VAILABLE&OR-ANEUVER )DENTIFY#RUCIAL)SSUES     .

IST#OURSES/F!CTION!VAILABLE 3ELECT!0ROMISING#OURSE/F!CTION 4EST3ELECTED#OURSE/F!CTION!0ILOT3TUDY )N4HE.     #RITERIA&OR-EASURING3UCCESS)DENTIFIED &IELD&OR-ANEUVER$EFINED #RUCIAL)SSUES)DENTIFIED        0ROPOSE!#OURSE/F!CTION 2EVIEW%XPERIENCE/F!NALOGOUS0ROBLEMS #OLLECT#ASE(ISTORIES/F3IMILAR0ROBLEMS(ANDLED%LSEWHERE .IGHT/F%XPERIENCE7ITH!NALOGOUS0ROBLEMS.

ECESSARY.!PPRAISE0ROBABLE!DEQUACY/F #OURSE/F!CTION3ELECTED )F.

2EITERATE&ROM5NTIL!3UFFICIENTLY!SSURING#OURSE/F!CTION)S3ELECTED 2EAPPRAISE/FFICE7ORKLOAD!ND0ROJECT&ACILITIES 2EAPPRAISE0ROGRAM!ND4IMETABLE &ORMULATE$RAFT2EVISE0ROPOSAL!ND%STIMATE7ITH3PECIAL2EPORTS/N.

!ND)F .ECESSARY     .

  .

    .

ISTED !0ROMISING#OURSE/F!CTION3ELECTED 4EST/F3ELECTED#OURSE/F!CTION#OMPLETED !PPRAISAL/F0ROBABLE!DEQUACY#OMPLETE     .        2EVIEW/F%XPERIENCE7ITH!NALOGOUS0ROBLEMS#OMPLETE #OLLECTION/F#ASE(ISTORIES2EADY !VAILABLE#OURSES/F!CTION.

.

OAD!ND0ROJECT&ACILITIES#OMPLETE 2EAPPRAISAL/F0ROJECT0ROGRAM!ND4IMETABLE#OMPLETE $RAFT2EVISED0ROPOSAL!ND%STIMATE2EADY    101 .     2EAPPRAISAL/F/FFICE7ORK.

ECESSARY.O %VENT  #HECK$RAFT0ROPOSAL!ND%STIMATE )F. 0HASE#ONTINUED 0HASE 0ROGRAMMING#ONTINUED $ATA#OLLECTION 0ROPOSE!#OURSE/F!CTION#ONTINUED 2ECEIVE)NSTRUCTIONS !NALYSIS #OLLECT2EADILY!VAILABLE)NFO #LASSIFY!ND3TORE$ATA )DENTIFY3UB0ROBLEMS           N          )TEM !CTIVITY !CTIVITY.

2EITERATE&ROM5NTIL!3ATISFACTORY0ROPOSAL)S$RAFTED 0REPARE!ND$ISPATCH&AIR#OPY/F0ROPOSAL!ND%STIMATE "RING&ILE!ND0ROGRESS-ACHINERY5P4O$ATE 2EITERATE3ECTIONS!ND.

5NTIL!GREEMENT)S2EACHED4O#ARRY/UT0HASE #OLLECT$ATA.

0REPARE0ERFORMANCE3PECIFICATION.

2EAPPRAISE0ROPOSED0ROGRAM!ND%STIMATE.

/R5NTIL 0ROJECT)S!BANDONED    $RAFT2EVISED0ROPOSAL!ND%STIMATE!PPROVED .

  .

    2EVISED0ROPOSAL!ND%STIMATE$ISPATCHED &ILES!ND0ROGRESS-ACHINERY5P4O$ATE    $ATA#OLLECTION    2ECEIVE)NSTRUCTIONS 3END!CKNOWLEDGMENT "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE     .

.

     #OMMISSION2ECEIVEDTO%XECUTE0HASE !CKNOWLEDGMENT$ISPATCHED &ILES!ND0ROGRESS-ACHINERY5P4O$ATE    #OLLECT2EADILY!VAILABLE)NFORMATION&OR%XAMPLE/N  %NVIRONMENTAL!T0OINT/F5SE.

)DENTITY/F5SERS.

5SER%RGONOMICS.

5SER-OTIVATION.

0RODUCT&UNCTION.

0RODUCT-ECHANICS.

0RODUCT&INISH.

0RODUCT!ESTHETICS.

-ARKET%NVIRONMENT.

#OMPETITIVE0RODUCTS.

0RODUCT!RCHETYPE.

"RAND0REDECESSORS.

-AKERgS(OUSE3TYLE.

2ULING-ARKET0RICES.

%CONOMIC1UANTITIES.

0RODUCT&ACILITIES.

IMITING$IMENSIONS..

-ATERIALS.

IST/F)NFORMATION2EADY    !VAILABLE)NFORMATION#LASSIFIED!ND3HELVED  !NALYSIS      )DENTIFY3UB PROBLEMS .IST!LL4HE3UB PROBLEMS4HUS)DENTIFIED )DENTIFY4HE!PPARENT3EQUENCE/F$EPENDENCE/F3UB PROBLEMS5PON/NE!NOTHER       .IST!LL4HE&ACTORS)N4HE/VERALL0ROBLEM 0AIR)NTERDEPENDENT&ACTORS3O!S4O&ORM!LL-ATTERS)NTO3UB0ROBLEMS . #OLLECT/THER2EADILY!VAILABLE)NFORMATION    !VAILABLE)NFORMATION2EADY       #LASSIFY!ND3TORE$ATA .IST)NFORMATION4OPICS(ANDLED 2ATIONALIZE4OPIC(EADINGS $ESIGN!N)NFORMATION#LASSIFICATION3YSTEM #LASSIFY!LL)NFORMATION(ELD 3HELVE4HE)NFORMATION'ATHERED        .

IST/F&ACTORS2EADY )NTERDEPENDENCE-ATRIX2EADY .ETWORK2EADY 102      .      .IST/F3UB PROBLEMS2EADY 3UB 0ROBLEM.

0HASE#ONTINUED !NALYSIS#ONTINUED  !NALYZE3UB PROBLEMS!BOUT%NDS 0REPARE0ERFORMANCE3PECIFICATION          N   N   N N  N  N  N  N  N   N   N         )TEM !CTIVITY !CTIVITY.O %VENT  $ISTINGUISH0ROBLEMS!BOUT-EANS&ROM 0ROBLEMS!BOUT%NDS 2ESOLVE0ROBLEMS!BOUT%NDS!S)NDICATED)N3ECTIONS!ND  .

ISTOF0ROBLEMS!BOUT-EANS2EADY .       .IST/F0ROBLEMS!BOUT%NDS2EADY .

  .

  .

              .IST/F&ACTORS)N3UB PROBLEM2EADY 'OALS!ND#ONDITIONS)DENTIFIED #ONNECTION"ETWEEN&ACTORS!ND'OALS/R #ONDITIONS%STABLISHED 6OLUNTARILY%VALUABLE&ACTORS)DENTIFIED %XTERNALLY)NFLUENCED&ACTORS)DENTIFIED $EPENDENTLY6ARIABLE&ACTORS)DENTIFIED .

ETWORK2EADY .   2EVISED.

.

.

    .

 .

ECESSARY$ATA2EADY 3IMPLIFYING!SSUMPTIONS0OSTULATED &IELD/F&EASIBLE3OLUTIONS$ELINEATED .      .

   /PTIMAL3OLUTION)DENTIFIED .

IST/F0ROBLEMS!BOUT%NDS2EADY 0ROBLEMS7ITH#OMPATIBLE/PTIMAL3OLUTIONS)DENTIFIED       0ROBLEMS7ITH#OMPATIBLE/PTIMAL&EASIBLE3OLUTIONS )DENTIFIED 0ROBLEMS7ITH#OMPATIBLE&EASIBLE3OLUTIONS)DENTIFIED    0ROBLEMS7ITH)NCOMPATIBLE3OLUTIONS)DENTIFIED                       !NALYZE3UB PROBLEMS!BOUT%NDS 3ELECT!0ROBLEM!BOUT%NDS&ROM4HE.ETWORK)DENTIFIED5NDER .   !LL0ROBLEMS!BOUT%NDS2ESOLVED    0RIORITIES)DENTIFIED2ANKING-ATRIX       2ANKED.IST4HE&ACTORS)N4HIS3UB PROBLEM )DENTIFY4HE'OAL4O"E!CHIEVED %STABLISH4HE#ONNECTION"ETWEEN4HE&ACTORS!ND4HE'OAL )DENTIFY4HOSE&ACTORS7HERE4HE$ATA6ALUES-AY"E6OLUNTARILY&IXED "Y4HE$ESIGNER )DENTIFY4HOSE&ACTORS7HERE4HE$ATA6ALUES!RE&IXED"Y%XTERNAL)NFLUENCES )DENTIFY4HOSE&ACTORS7HERE4HE$ATA!RE$EPENDENT6ARIABLES&OR%XAMPLE.

ECESSARY.7HERE 4HE$ATA!RE4HE3OLUTIONS4O/THER3UB PROBLEMS )F.

ETWORK)N3O4HAT0ROBLEMS7HICH0ROVIDE$ATA&OR/THER 0ROBLEMS!RE$EALT7ITH)N4HE2IGHT/RDER.2EVISE.

/R3ELECT!NOTHER0ROBLEM!T #OLLECT.ECESSARY$ATA%ITHER%XTRACT$ATA&ROM2ECORD3YSTEM/R!DD&RESH$ATA 7HERE3UFFICIENT.

0RECISE$ATA)S!VAILABLE.

$ELINEATE-AXIMUM&IELD/F&EASIBLE3OLUTIONS 7HERE3UFFICIENT0RECISE$ATA)S.OT!VAILABLE.

0OSTULATE3IMPLIFYING !SSUMPTIONS"Y0LAUSIBLE2EASONING!ND4HEN$ELINEATE!&IELD/F &EASIBLE3OLUTIONS 2EFERRING4O.

ETWORK!S.ECESSARY 2EITERATE3ECTION/F%ACH0ROBLEM!BOUT%NDS)N4HE.ETWORK 0REPARE0ERFORMANCE3PECIFICATION 4AKING%VERY#OMBINATION/F0AIRS/F3UB PROBLEMS!BOUT%NDS.)DENTIFY4HE:ONE7HERE3ATISFACTION/F'OAL)S/PTIMUM 2EEXAMINE3ECTION!ND-ODIFY0ROBLEM.

IST/F3UB PROBLEMS)N/RDER/F0RECEDENCE )DENTIFY4HOSE0AIRS7HERE4HE/PTIMUM3OLUTIONS!RE)N&ACT-UTUALLY#OMPATIBLE.)DENTIFY7HICH)N%ACH0AIR -UST4AKE0RECEDENCE)F4HEIR/PTIMUM3OLUTIONS!RE)NCOMPATIBLE 2ANK4HE#OMPLETE.

OT4HE/PTIMUM 3OLUTIONS/F4HE/THER )DENTIFY4HOSE0AIRS7HERE&EASIBLE3OLUTIONS"UT.OT4HE/PTIMUM3OLUTIONS !RE#OMPATIBLE )DENTIFY4HOSE0AIRS7HERE&EASIBLE3OLUTIONS!ND/PTIMUM3OLUTIONS!RE)NCOMPATIBLE 103 .2EFERRING 4O&OR%ACH3UB PROBLEM )DENTIFY4HOSE0ARIS7HERE4HE/PTIMUM3OLUTION/F/NE)S#OMPATIBLE7ITH&EASIBLE"UT .

0HASE#ONTINUED !NALYSIS#ONTINUED  0REPARE0ERFORMANCE3PECIFICATION#ONTINUED 2EAPPRAISE0ROGRAM!ND%STIMATE        .

IST.O %VENT  3ELECT!LL4HE3UB PROBLEMS.                  )TEM !CTIVITY !CTIVITY.ISTED5NDER!ND7HICH3TAND(IGH/N4HE2ANK /RDERED.

ECESSARY)F4OO-ANY)NCOMPATIBILITIES2EMAIN.!ND2EEXAMINE4HEM!CCORDING4O3ELECTION2EEXAMINE!SSIGNED 6ALUES!ND3IMPLIFYING!SSUMPTIONS!T 2EITERATE&ROM!S.

2EITERATE3ECTIONS !ND3EEKING%ASEMENTS 7HEN!LL0ROBLEMS!BOUT%NDS(AVE"EEN2ESOLVED/R!S-ANY/F4HEM!S3EEMS 0RACTICABLE .

!SSEMBLE!LL4HEIR3OLUTIONS)NTO!0ERFORMANCE/R$ESIGN 3PECIFICATION.

IST!NY2EMAINING)NTRACTABLE0ROBLEMS!BOUT%NDS&OR2EFERENCE4O#LIENT!NDOR&OR 2ESOLUTION!S#REATIVE0ROBLEMS . 2ANKED3UBSTANTIALLY)N!CCORDANCE7ITH .

.

.

.

   #RITICAL0ROBLEMS2EEXAMINED .

.

   0ERFORMANCE3PECIFICATION2EADY    2EMAINING)NTRACTABLE0ROBLEMS!BOUT%NDS.ISTED .

.

  .

    .

.

.

.

  .

    .

.

ISTED #OURSE/F!CTION2EFORMULATED 2EPORT/N0ROBLEM!BOUT%NDS2EADY 0ROGRAM!ND4IMETABLE2EAPPRAISED 7ORKLOAD!ND&ACILITIES2EAPPRAISED $RAFT2EVISED0ROPOSAL.        0ROBLEM2ESTATEMENT2EADY 2EAPPRAISED#RUCIAL)SSUES.

0ERFORMANCE3PECIFICATION!ND %STIMATE2EADY    $RAFT0ROPOSAL!ND%STIMATE$ISPATCHED .

  .

    0ROPOSAL!ND%STIMATE$ISPATCHED &ILES!ND0ROGRESS-ACHINERY5P4O$ATE              2EAPPRAISE0ROGRAM!ND%STIMATE )N4HE.IGHT/F.

!ND.

2ESTATE4HE0ROBLEM3ET/UT)N 2EAPPRAISE4HE#RUCIAL)SSUES3ET/UT)N 2EAPPRAISE!ND)F.ECESSARY2EFORMULATE!#OURSE/F!CTION.

0ERVIOUSLY3ET/UT)N 7HERE2EQUIRED.

0REPARE!2EPORT/N4HE/VERALL0ROBLEMS!BOUT%NDS.

2EFERRING4O 2EAPPRAISE0ROGRAM!ND4IMETABLE 2EAPPRAISE/FFICE7ORKLOAD!ND0ROJECT&ACILITIES &ORMULATE$RAFT2EVISED0ROPOSAL!ND%STIMATE 7ITH0ERFORMANCE3PECIFICATION&OR!PPROVAL.

!ND2EPORT/N/VERALL0ROBLEM!ND%NDS 7HERE.ECESSARY2EITERATE&ROM5NTIL!3ATISFACTORY0ROPOSAL)S$RAFTED 0REPARE!ND$ISPATCH&AIR#OPY/F0ROPOSAL!ND%STIMATE "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE 2EITERATE3ECTION5NTIL!GREEMENT)S2EACHED4O#ARRY/UT0HASE 0REPARE/UTLINE $ESIGN0ROPOSALS .ECESSARY #HECK!ND!PPROVE$RAFT0ROPOSAL!ND%STIMATE )F.

/R0ROJECT)S4ERMINATED 7HERE3UITABLE.

0HASE $EVELOP0ROTOTYPE$ESIGNS !NDOR0HASE 0REPARE!ND %XECUTE 6ALIDATION3TUDIES-AY!LSO"E#OMMISSIONED!T4HE3AME4IME!S0HASE 104 .

0HASE 3YNTHESIS  2ECEIVE)NSTRUCTIONS 2ESOLVE2EMAINING0ROBLEMS!BOUT%NDS             N   N    N N N   N  N  N N  N N  N    N N   N N      )TEM !CTIVITY  3YNTHESIS    2ECEIVE)NSTRUCTIONS 3END!CKNOWLEDGMENT "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE  2ESOLVE2EMAINING0ROBLEMS!ND%NDS.OTE4HAT.

)N'ENERAL.

3OLUTIONS4O0ROBLEMS !BOUT%NDS7ILL0OSE0ROBLEMS!BOUT-EANS 2EAPPRAISE4HE0ERFORMANCE3PECIFICATION0REPARED5NDER!ND4HE.IST/F)NTRACTABLE 0ROBLEMS!BOUT%NDS0REPARED5NDER!ND0REPARE!.IST/F5NRESOLVED0ROBLEMS !BOUT%NDS &OR%ACH0ROBLEM)N4HE.IST0REPARE5NDER.EW.

O %VENT     ..IST4HE&ACTORS)N4HE0ROBLEM )DENTIFY4HE'OALS4O"E!CHIEVED!ND4HE#ONSTRAINTS/R#ONDITIONS4O"E3ATISFIED                  !CTIVITY.

.

     #OMMISSION2ECEIVED4O%XECUTE0HASE !CKNOWLEDGMENT$ISPATCHED &ILES!ND0ROGRESS-ACHINERY5P4O$ATE .

.

.

   2EVISED.IST/F5NRESOLVED0ROBLEMS!BOUT%NDS2EADY       %STABLISH4HE#ONNECTIONS"ETWEEN4HE&ACTORS/R4HE'OALS!ND#ONSTRAINTS/R#ONDITIONS )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS(ANDLED%LSEWHERE #ATALOG4HE0ROPERTIES/F4HE!NALOGOUS0ROBLEMS!ND2EEXPRESS%ACH7ITHIN! #OMMON&ORMAT 2EEXPRESS0RESENT3UB PROBLEM7ITHIN4HE&ORMAT$EVELOPED5NDER .

      .

      .IST/F&ACTORS)N3UB PROBLEM2EADY 'OALS!ND#ONSTRAINTS/R#ONDITIONS&OR 3UB PROBLEMS)DENTIFIED #ONNECTIONS"ETWEEN&ACTORS%STABLISHED !NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE)DENTIFIED !NALOGOUS0ROBLEMS(ANDLED%LSEWHERE)DENTIFIED !NALYSIS/F!NALOGOUS0ROBLEMS#OMPLETE .

   )DENTIFY4HOSE&ACTORS)N4HE3UB PROBLEM&OR7HICH4HE$ATA6ALUES-AY"E6OLUNTARILY &IXED"Y4HE$ESIGNER )DENTIFY4HOSE&ACTORS)N4HE3UB PROBLEM&OR7HICH4HE$ATA6ALUES!RE&IXED"Y %XTERNAL)NFLUENCES )DENTIFY4HOSE&ACTORS7HERE4HE$ATA!RE$EPENDENT6ARIABLES&OR%XAMPLE.

ECESSARY.7HERE4HE $ATA!RE4HE3OLUTIONS4O/THER3UB PROBLEMS )F.

3USPEND7ORK/N4HIS 0ROBLEM!ND3ELECT!NOTHER!T3O4HAT3UB PROBLEMS!RE$EALT7ITH)N4HE2IGHT/RDER #OLLECT.OT!VAILABLE.ECESSARY$ATA%ITHER%XTRACT$ATA&ROM2ECORD3YSTEM/R!DD&RESH$ATA 7HERE3UFFICIENT0RECISE$ATA)S.

OT0RACTICAL3OLUTION%MERGES.0OSTULATE3IMPLIFYING!SSUMPTIONS/R!SSIGN 6ALUES"Y0LAUSIBLE2EASONING 7HERE.

6ARY/NE/F4HE6OLUNTARILY!SSIGNED6ALUES!NDOR !SSUMPTIONS3EE!ND !ND3EEK%ASEMENTS 7HERE4HIS&AILS.

2EAPPRAISE#ONSTRAINTS3EE .

AST2ESORT.!ND3EEK%ASEMENTS )N4HE.

2EAPPRAISE'OALS3EE !ND3EEK6ARIATION 2ESOLVE0ROBLEM.

$ELINEATING-AXIMUM&IELD/F&EASIBLE3OLUTIONS       2E EXPRESSION/F3UB PROBLEM7ITHIN#OMMON &ORMAT#OMPLETE &ACTORS7HERE$ATA6ALUES!RE6OLUNTARILY!SSIGNABLE )DENTIFIED &ACTORS7HERE$ATA6ALUES!RE%XTERNALLY&IXED)DENTIFIED    &ACTORS7HERE$ATA!RE$EPENDENT6ARIABLES)DENTIFIED .

  .

.

    .

       .

.

.

.

ECESSARY$ATA2EADY 3IMPLIFYING!SSUMPTIONS0OSTULATED!NDOR$ATA 6ALUES!SSIGNED .     .O3OLUTION#ONSTRAINTS/R#ONDITIONS%ASED .O3OLUTION'OALS6ARIED 3OLUTION4O3UB PROBLEM2EADY 105 .O3OLUTION!SSIGNED6ALUES!NDOR3IMPLIFYING !SSUMPTIONS6ARIED .

0HASE#ONTINUED 3YNTHESIS#ONTINUED 2ESOLVE2EMAINING0ROBLEMS!BOUT%NDS#ONTINUED  0OSTULATE-EANS&OR2ECONCILING$IVERGENT$ESIDERATA)N0ERFORMANCE3PECIFICATION            N     N N  N       N   N   N N  N N  N     N       )TEM !CTIVITY !CTIVITY.O %VENT  )F!6ARIATION/R!SSUMPTION(AS"EEN-ADE5NDER !ND!3OLUTION(AS%MERGED.

2EFER4O3OURCE!ND#HECK0RIMA&ACIE!CCEPTABILITY/F6ARIATION/R!SSUMPTION3EE!LSO 6ALIDATION3TUDIES.

3ECTION 7HERE.ECESSARY.

ISTED5NDER!RE 2ESOLVED 5NITE3OLUTIONS0REPARED5NDER7ITH0ERFORMANCE3PECIFICATION0REPARED5NDER 4O&ORM!2EVISED3PECIFICATION .2EITERATE&ROM 2EITERATE&ROM5NTIL!LL/UTSTANDING0ROBLEMS!BOUT%NDS.

.

.

.

   0RIMA&ACIE6ALIDATION/F!SSUMPTIONS!ND6ARIATIONS #OMPLETE .

   !LL0ROBLEMS!BOUT%NDS2ESOLVED .

   2EVISED0ERFORMANCE3PECIFICATION2EADY    )NTER RELATED$ESIDERATA)DENTIFIED)NTERACTION-ATRIX      .IST/F)NTER RELATED$ESIDERATA2EADY  'ROUPS#ONTAINING$IVERGENT$ESIDERATA)DENTIFIED    $IVERGENT$ESIDERATA2EEXPRESSED!S'OALS                 .

  .

             %XPLORATION/F#OMBINATIONS/F3OLUTION%LEMENTS#OMPLETE  (YPOTHESIS3ELECTED  .O(YPOTHESIS .

   3OLUTIONS IN PRINCIPLE!SSEMBLED                    0OSTULATE-EANS&OR2ECONCILING$IVERGENT$ESIDERATA)N0ERFORMANCE3PECIFICATION %XAMINE4HE!UGMENTED0ERFORMANCE3PECIFICATION0REPARED5NDER.

IST4HE'ROUPS/F)NTER RELATED$ESIDERATA &ROM4HE.!ND)DENTIFY !ND'ROUP4HOSE$ESIDERATA7HICH!PPEAR4O"E)NTER RELATED .IST0REPARED5NDER.

3ELECT4HOSE'ROUPS#ONTAINING$ESIDERATA7HICH !PPEAR4O"E$IVERGENT/R#ONTRADICTORY &OR%ACH'ROUP3ELECTED5NDER.

ISTED5NDER.2EEXPRESS4HE$ESIDERATA!S4HE'OALS!ND #ONSTRAINTS/R#ONDITIONS&OR/NE/R-ORE0ROBLEMS!BOUT-EANS .IST4HE0ROBLEMS!BOUT-EANS4HUS)DENTIFIED &OR%ACH0ROBLEM!BOUT-EANS.

IST4HE&ACTORS)N4HE0ROBLEM )DENTIFY'OALS!ND#ONSTRAINTS/R#ONDITIONS)N4HE3UB PROBLEM %STABLISH4HE#ONNECTIONS"ETWEEN4HE&ACTORS'OALS!ND#ONSTRAINTS/R #ONDITIONS )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS(ANDLED%LSEWHERE #ATALOG4HE0ROPERTIES/F4HE.EAREST!NALOGOUS0ROBLEMS!ND4HE%LEMENTS/F4HEIR 2ESPECTIVE3OLUTIONS!ND0REPARE!0ROBLEM%LEMENTPROBLEM3OLUTION-ATRIX 2EEXPRESS4HE0RESENT0ROBLEM7ITHIN4HE3AME-ATRIX %XPLORE#OMBINATIONS/F3OLUTION%LEMENTS 3ELECT!0ROMISING#OMBINATION/F3OLUTION%LEMENTS!S!(YPOTHESIS&OR$EVELOPMENT 7HERE..O0ROMISING(YPOTHESIS%MERGES.

2EITERATE&ROM)N7IDER&IELDS 2EITERATE&ROM5NTIL!LL0ROBLEMS!BOUT-EANS!RISING&ROM$IVERGENT$ESIDERATA)N4HE 0ERFORMANCE3PECIFICATION!RE2ESOLVED !SSEMBLE(YPOTHETICAL3OLUTIONS 106 .IST/F&ACTORS)N4HE3UB PROBLEM2EADY .IST/F'OALS!ND#ONSTRAINTS/R#ONDITIONS2EAD #ONNECTION"ETWEEN&ACTORS!ND4HE'OALS!ND #ONSTRAINTS/R#ONDITIONS%STABLISHED !NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE)DENTIFIED !NALOGOUS0ROBLEMS(ANDLED%LSEWHERE)DENTIFIED 0ROBLEM%LEMENTSOLUTION-ATRIX2EADY 2E EXPRESSION/F3UB PROBLEM7ITH3AME-ATRIX#OMPLETE .IST/F0ROBLEMS!BOUT-EANS2EADY .

0HASE#ONTINUED 3YNTHESIS#ONTINUED  $EVELOP3OLUTIONS)N0RINCIPLE4O0ROBLEMS!BOUT-EANS!RISING&ROM0ERFORMANCE3PECIFICATION 0OSTULATE/UTLINE/VERALL3OLUTIONS                 OR    N  N  N  N  N   N  N   N N  N  N  N       N      )TEM !CTIVITY  $EVELOP3OLUTIONS)N0RINCIPLE4O0ROBLEMS!BOUT-EANS!RISING&ROM0ERFORMANCE 3PECIFICATION 2EFERRING4O4HE0ERFORMANCE3PECIFICATION0REPARED5NDER.

4HE.IST/F'ROUPS/F )NTERRELATED$ESIDERATA0REPARED5NDER.

.ISTED5NDER.OT9ET (ANDLED!DD!NY0ROBLEM!BOUT-EANS2EMAINING&ROM4HOSE5NDER &OR%ACH)TEM.IST4HOSE'ROUPS!ND3INGLE$ESIDERATA.

2EEXPRESS4HE'OALS!ND#ONSTRAINTS&OR/NE/R-ORE 0ROBLEMS!BOUT-EANS .ISTED5NDER.IST4HE0ROBLEMS!BOUT-EANS4HUS)DENTIFIED &OR%ACH0ROBLEM!BOUT-EANS.

.IST4HE&ACTORS)N4HE0ROBLEM )DENTIFY'OALS!ND#ONSTRAINTS/R#ONDITIONS)N4HE3UB PROBLEM %STABLISH4HE#ONNECTIONS"ETWEEN4HE&ACTORS'OALS!ND#ONSTRAINTS/R #ONDITIONS )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE )DENTIFY3IMILAR/R!NALOGOUS0ROBLEMS(ANDLED%LSEWHERE #ATALOG4HE0ROPERTIES/F4HE.EAREST!NALOGOUS0ROBLEMS!ND4HE%LEMENTS/F4HEIR 2ESPECTIVE3OLUTIONS!ND0REPARE!0ROBLEM%LEMENTPROBLEM3OLUTION-ATRIX 2EEXPRESS4HE0RESENT0ROBLEM7ITHIN4HE3AME-ATRIX %XPLORE#OMBINATIONS/F3OLUTION%LEMENTS 3ELECT!0ROMISING#OMBINATION/F3OLUTION%LEMENTS!S!(YPOTHESIS&OR$EVELOPMENT 7HERE.OT0ROMISING(YPOTHESIS&OR$EVELOPMENT%MERGES.

2EITERATE&ROM)N7IDER&IELD 2EITERATE&ROM5NTIL!LL0ROBLEMS!BOUT-EANS!RISING&ROM$ESIDERATA)N0ERFORMANCE 3PECIFICATION!RE2ESOLVED)N0RINCIPLE !SSEMBLE(YPOTHETICAL3OLUTIONS                    0OSTULATE/UTLINE/VERALL3OLUTIONS 5NITE4HE#OLLECTION/F(YPOTHETICAL3OLUTIONS5NDER7ITH4HOSE5NDER 5SING4HE0ERFORMANCE3PECIFICATION0REPARED5NDER!S!'UIDE.

ATER0ROVE4O"E)NCOMPATIBLE 2ANK4HE#OLLECTION/F(YPOTHETICAL3OLUTIONS)N/RDER/F0RECEDENCE 4AKING%VERY#OMBINATION/F0ARIS/F(YPOTHETICAL3OLUTIONS&ROM4HE.IST5NDER.4AKE%VERY #OMBINATION/F0AIRS/F(YPOTHETICAL3OLUTIONS!ND)DENTIFY7HICH)N%ACH0AIR3HOULD 4AKE0RECEDENCE)F4HEY3HOULD.

"EGINNING7ITH4HE0AIRS#ONTAINING4HE(IGHEST2ANKED3OLUTIONS.

IGHT/F 7HATEVER)NFORMATION)S2EADILY!VAILABLE.!ND)N4HE.

#HECK4HE0LAUSIBILITY/F%ACH0AIRgS0ROVING 4O"E#OMPATIBLE 7HERE0ROBABLE)NCOMPATIBILITIES!RE)DENTIFIED.

2EITERATE&ROM !CTIVITY.O %VENT .

.

.

   .IST/F/UTSTANDING)NTER RELATED$ESIDERATA2EADY    'OALS!ND#ONSTRAINTS&OR0ROBLEMS!BOUT-EANS)DENTIFIED                 .

IST/F0ROBLEMS!BOUT-EANS2EADY .IST/F'OALS!ND#ONSTRAINTS/R#ONDITIONS2EADY #ONNECTION"ETWEEN&ACTORS!ND4HE'OALS!ND #ONSTRAINTS/R#ONDITIONS%STABLISHED  !NALOGOUS0ROBLEMS)N0RIOR%XPERIENCE)DENTIFIED  !NALOGOUS0ROBLEMS(ANDLED%LSEWHERE)DENTIFIED  0ROBLEM%LEMENTSOLUTION-ATRIX2EADY .  .IST/F&ACTORS)N4HE3UB PROBLEM2EADY 2EVISED.

            .

   3OLUTIONS IN PRINCIPLE!SSEMBLED .

  .

IST/F(YPOTHETICAL3OLUTIONS2EADY  #OMPATIBILITY3TUDIES#OMPLETE 2E EXPRESSION/F3UB PROBLEM7ITH3AME-ATRIX#OMPLETE %XPLORATION/F#OMBINATIONS/F3OLUTION%LEMENTS#OMPLETE (YPOTHESIS3ELECTED .O(YPOTHESIS 107 .   #OMBINED#OLLECTION/F(YPOTHETICAL3OLUTIONS2EADY  2ANKING-ATRIX&OR0ROBLEMS!BOUT%NDS2EADY      2ANKED.

O %VENT  !SSEMBLE!LL4HE(YPOTHETICAL3OLUTIONS)NTO!3UGGESTED#OMPOSITE/VERALL3OLUTION.0HASE#ONTINUED 0HASE 3YNTHESIS#ONTINUED $EVELOPMENT  0OSTULATE/UTLINE/VERALL3OLUTIONS #ONTINUED 2ECEIVE)NSTRUCTIONS $EFINE$ESIGN)DEA %RECT!+EY-ODEL                                                   )TEM !CTIVITY !CTIVITY.

IGHT/F#RUCIAL)SSUES3ET/UT)N 7HERE2EQUIRED.IGHT/F4HE0ROBLEM!S3ET/UT)N 2EAPPRAISE4HE0ROPOSED3OLUTIONS )N4HE./R 2ANGE/F3OLUTIONS 2EAPPRAISE4HE0ROPOSED3OLUTIONS )N4HE.

OTE"ELOW 2EAPPRAISE!ND)F.0REPARE!ND3UBMIT3KETCH$ESIGNS3EE.ECESSARY2EFORMULATE!#OURSE/F!CTION.

0REVIOUSLY3ET/UT)N 2EAPPRAISE4IMETABLE 2EAPPRAISE&ACILITIES )F.ECESSARY.

0REPARE2EVISED0ROPOSALS "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE    #OMPOSITE/VERALL3OLUTIONS 2EADY .

  .

  .

        .

.

  .

              .

.

IGHT/F#RUCIAL)SSUES#OMPLETE 3KETCH$ESIGNS2EADY 2EAPPRAISAL!NDOR2EFORMULATION/F#OURSE/F!CTION#OMPLETE 2EAPPRAISAL/F4IMETABLE#OMPLETE 2EAPPRAISAL/F&ACILITIES#OMPLETE 2EVISED0ROPOSALS2EADY &ILES!ND0ROGRESS-ACHINERY5P4O$ATE .IGHT/F/RIGINAL0ROBLEM 2EAPPRAISAL)N.OTE)F3KETCH$ESIGNS-UST"E3UBMITTED&OR!PPROVAL!T4HIS3TAGE3EE.   #OMMISSION2ECEIVED4O%XECUTE0HASE  !CKNOWLEDGMENT$ISPATCHED  &ILES!ND0ROGRESS-ACHINERY5P4O$ATE          2EAPPRAISAL)N.

#ONTINUE7ITH 3ECTION!ND4HEN4HE7HOLE/F3ECTION&OR4HE3KETCH$ESIGN/NLY2EITERATE4HE7HOLE/F 3ECTION5NTIL!3KETCH$ESIGN)S!PPROVED!ND!#OMMISSION)S2ECEIVED4O%XECUTE0HASE 0ROCEED7ITH3ECTION)N2ESPECT/F4HE&INISHED$ESIGN $EVELOPMENT    2ECEIVE)NSTRUCTIONS 3END!CKNOWLEDGMENT "RING&ILES!ND0ROGRESS-ACHINERY5P4O$ATE   $EFINE$ESIGN)DEA 5SING4HE-OST!BSTRACT/R'ENERAL-EDIUM!VAILABLEEG.

!&ORM/F7ORDS .

#OMPLETELY $EFINE4HE%SSENTIAL'ERM/F4HE$ESIGN)DEA 5SING4HE3AME-EDIUM.

$EFINE4HE-AXIMUM6ARIATION%MBRACEABLE"Y4HE$ESIGN)DEA )N4HE#ASE/F3KETCH$ESIGNS"EING0REPARED5NDER.

EAST!BSTRACT-EDIUM7HICH7ILL%XHAUSTIVELY$ESCRIBE4HE6ARIANTS/F4HE $ESIGN)DEA3EE %RECT!+EY-ODEL/F4HE%SSENTIAL$ESIGN)DEA3HOWING!LL)TgS6ARIANTS 108 .IST2ANGE/F-EDIA&OR4HE2EPRESENTATION/F!N%MBODIMENT/F4HE$ESIGN)DEA 3ELECT4HE.OW7ITH3ECTION )N2ESPECT/F3KETCH$ESIGNS/NLY      %RECT!+EY-ODEL .0ROCEED.

.

.

   $EFINITION/F%SSENTIAL'ERM/F$ESIGN)DEA2EADY    $EFINITION/F2ANGE/F6ARIATION%MBRACEABLE"Y$ESIGN )DEA2EADY   .

   .IST/F!VAILABLE-EDIA2EADY  -EDIUM3ELECTED .

   +EY-ODEL%RECTED .

0HASE#ONTINUED $EVELOPMENT#ONTINUED         $EVELOP3UB PROBLEM-UTUAL3OLUTIONS                 N        N   N   N N N  N N  N   N N        )TEM !CTIVITY   $EVELOP3UB PROBLEM-UTUAL3OLUTIONS 4AKE4HE#OMBINED#OLLECTION/F(YPOTHETICAL3UB PROBLEM3OLUTIONS5NDER!ND.

)N 4HE.IGHT/F4HE)NFORMATION%MPLOYED)N4HEIR2ESPECTIVE2ESOLUTIONS3EE3ECTION!ND 3ECTION .

)DENTIFY!LL#OMBINATIONS/F0AIRS/F(YPOTHETICAL3OLUTIONS7HICH!PPEAR4O )NVOLVE)NTER ACTING$EVELOPMENT$ETAILS .IST/F(YPOTHETICAL3UB PROBLEM3OLUTIONS0REPARED5NDER!S!'UIDE.IST4HE)NTER ACTING0AIRS4HUS)DENTIFIED 5SING4HE2ANKED.

ETWORK.ETWORK4HE-OST$ESIRABLE3EQUENCE&OR$ETAILED $EVELOPMENT/F4HE#HAIN/F(YPOTHETICAL3UB PROBLEM3OLUTIONS 3ELECT4HE%ARLIEST5NDEVELOPED(YPOTHESIS)N4HE. )DENTIFY!ND0LOT)N4HE&ORM/F!.

ECESSARY4O 7ORKING0APERS0REPARED5NDER3ECTION.2EFERRING7HERE.

!ND.IST4HE&ACTORS)N$EVELOPING4HIS (YPOTHESIS)NTO!-ATERIAL%MBODIMENT 2EFERRING7HERE.ECESSARY4O7ORKING0APERS5NDER3ECTION.

ECESSARY4O7ORKING0APERS0REPARED5NDER3ECTION.)DENTIFY4HE'OALS!ND #ONSTRAINTS/R#ONDITIONS)N4HE3UB PROBLEM 2EFERRING7HERE.

%STABLISH4HE #ONNECTIONS"ETWEEN4HE&ACTORS'OALS!ND#ONSTRAINTS/R#ONDITIONS )DENTIFY4HOSE&ACTORS7HERE4HE$ATA6ALUES-AY"E6OLUNTARILY!SSIGNED"Y4HE$ESIGNER )DENTIFY4HOSE&ACTORS7HERE4HE$ATA6ALUES!RE&IXED"Y%XTERNAL)NFLUENCES )DENTIFY4HOSE&ACTORS7HERE4HE$ATA!RE$EPENDENT6ARIABLES&OR%XAMPLE.

7HERE4HE$ATA !RE(E3OLUTIONS4O/THER3UB PROBLEMS )F.ECESSARY.

2EVISE.ETWORK0REPARED5NDER3O4HAT0ROBLEMS7HICH0ROVIDE$ATA&OR /THER3UB PROBLEMS!RE$EALT7ITH)N4HE2IGHT/RDER.

/R3ELECT!NOTHER0ROBLEM!T #OLLECT.ECESSARY$ATA 7HERE3UFFICIENT.

!ND3UFFICIENTLY0RECISE.

$ATA)S!VAILABLE.

$EVELOP!-ODEL%MBODIMENT /F4HE(YPOTHETICAL3OLUTION 7HERE3UFFICIENT0RECISE$ATA)S.OT!VAILABLE.

0OSTULATE3IMPLIFYING!SSUMPTIONS"Y 0LAUSIBLE2EASONING!ND$EVELOP!-ODEL%MBODIMENT/F4HE(YPOTHETICAL3OLUTION 4EST4HE%MBODIMENT&OR&IT7ITHIN4HE&RAMEWORK/F4HE+EY-ODEL 7HERE%MBODIMENT)S&OUND4O"E)MPRACTICABLE.

2EVISE(YPOTHETICAL3OLUTION"Y 2EITERATING3ECTION&OR4HAT3UB PROBLEM.

!ND3ECTION&OR4HE%FFECT/F!.ETWORK0REPARED5NDER .EW (YPOTHESIS/N4HE/VERALL$ESIGN#ONCEPT 2EEXAMINE4HE)NTER ACTION-ATRIX0REPARED5NDER!ND4HE.

O %VENT    )NTERACTION-ATRIX2EADY   .ECESSARY!ND3ELECT!NOTHER3UB PROBLEM               !CTIVITY.ETWORK!S.2EVISE.

IST/F)NTER ACTING0AIRS/F(YPOTHETICAL  3UB PROBLEM3OLUTIONS2EADY .   .

   .IST/F&ACTORS)N3UB PROBLEM2EADY .

   .IST/F'OALS!ND#ONSTRAINTS/R#ONDITIONS2EADY .

.

ETWORK2EADY .   #ONNECTIONS"ETWEEN&ACTORS%STABLISHED        &ACTORS7HERE$ATA6ALUES!RE6OLUNTARILY!SSIGNABLE)DENTIFIED  &ACTORS7HERE$ATA6ALUES!RE&IXED"Y%XTERNAL)NFLUENCES)DENTIFIED  &ACTORS7HERE$ATA6ALUES!RE$EPENDENT6ARIABLES)DENTIFIED    2EVISED.

.

  .

   .ECESSARY$ATA2EADY .

   3IMPLIFYING!SSUMPTIONS0OSTULATED  -ATERIAL%MBODIMENT2EADY  4EST/F3UB PROBLEM3OLUTION%MBODIMENT7ITH+EY -ODEL#OMPLETE .

  .

.

   !LL(YPOTHETICAL3UB PROBLEM3OLUTIONS%MBODIED 109 .

     0HASE#ONTINUED 0HASE $EVELOPMENT#ONTINUED $EVELOPMENT#ONTINUED 6ALIDATE(YPOTHESES $EVELOP/VERALL3OLUTIONS                   N  N     N   N  N N        N  N  N      )TEM !CTIVITY      $EVELOP/VERALL3OLUTIONS 5NITE-ODEL3UB PROBLEM%MBODIMENTS)NTO/NE/R-ORE-ODEL/VERALL3OLUTIONS )DENTIFY5NDEVELOPED!REAS)N4HE$ESIGN 2EEXPRESS!S!3EQUENCE/F!DDITIONAL0ROBLEMS&OR#OMPLETION $EVELOP%ACH0ROBLEM5NDER"Y2EITERATING&ROM 2EITERATE3ECTION5NTIL/NE/R-ORE/VERALL3OLUTIONS!RE&ULLY$EVELOPED $EVELOP%ACH0ROBLEM5NDER"Y2EITERATING&ROM 2EITERATE3ECTION5NTIL/NE/R-ORE/VERALL3OLUTIONS!RE&ULLY$EVELOPED               6ALIDATE(YPOTHESES 3ELECT!ND.IST4HOSE0ROBLEMS!BOUT%NDS7HERE$ATA6ALUES7ERE6OLUNTARILY!SSIGNED 3EE.

IST4HOSE0ROBLEMS!BOUT%NDS7HERE3IMPLIFYING!SSUMPTIONS7ERE-ADE3EE .!ND 3ELECT!ND.

ISTED5NDER/R.!ND &OR%ACH0ROBLEM.

&ORMULATE(YPOTHESES#ALCULATED4O&ACILITATE 4HE6ALIDATION/F4HE3OLUTION4O4HE0ROBLEM3EE.

.

!ND &OR%ACH(YPOTHESIS5NDER.

OTE"ELOW #ONDUCT6ALIDATION%XPERIMENT/R3TUDY!S0LANNED5NDER 7HERE4HE%XPERIMENT/R3TUDY3HOWS4HAT4HE3OLUTION4O4HE0ROBLEM!BOUT%NDS)S )NVALID3EE .$ESIGN!N%XPERIMENT4O4EST4HE(YPOTHESIS!ND6ALIDATE 4HE3OLUTION3EE.

4HEN2EWORK4HE0ROBLEM!BOUT%NDS!ND!LL)TgS2AMIFICATIONS&ROM 7HERE4HE%XPERIMENT/R3TUDY)S)NCONCLUSIVE.

2EITERATE&ROM 7HERE4HE%XPERIMENT/R3TUDY)NDICATES4HAT4HE3OLUTION4O4HE0ROBLEM!BOUT%NDS)S 3UPPORTED.

IST4HOSE3TATEMENTS)N4HE0ERFORMANCE3PECIFICATION3EE 7HICH(AVE .2EITERATE&ROM5NTIL0ROBLEMS.OTE7HERE.OT"EEN%XAMINED5NDER .ECESSARY.ISTED5NDER!ND!RE6ALIDATED )DENTIFY!ND.

ISTED5NDER.4HE0ROBLEM/F$ESIGNING!N%XPERIMENT#AN"E(ANDLED"Y4HE 0ROCEDURES3ET/UT)N3ECTION!ND3ECTION4HESE0ROCEDURES)NCLUDE!PPRAISING4HE 3IGNIFICANCE/F4HE0ROBLEM5NDER)NVESTIGATION!ND4HE!MOUNT/F%FFORT7HICH#AN"E $EVOTED4O)TgS3OLUTION &OR%ACH3TATEMENT.

&ORMULATE(YPOTHESES#ALCULATED4O&ACILITATE 6ALIDATION/F4HE3TATEMENT &OR%ACH(YPOTHESIS5NDER.

$ESIGN!N%XPERIMENT4O4EST4HE(YPOTHESIS!ND6ALIDATE 4HE3TATEMENT3EE.O %VENT   .OTE/N0AGE #ONDUCT6ALIDATION%XPERIMENT/R3TUDY!S0LANNED5NDER 110 !CTIVITY.

  .

  .

      .

   /VERALL3OLUTION2EADY .

  .

IST/F0ROBLEMS!BOUT%NDS#ONTAINING3IMPLIFYING !SSUMPTIONS2EADY  (YPOTHESES2EADY    $ESIGN&OR%XPERIMENT/R4EST2EADY      %XPERIMENT/R3TUDY#OMPLETE  3OLUTION4O0ROBLEM!BOUT%NDS3HOWN4O"E)NVALID   .IST/F0ROBLEMS!BOUT%NDS#ONTAINING 6OLUNTARILY!SSIGNED6ALUES2EADY  .   .

IST/F5NTESTED3TATEMENTS)N0ERFORMANCE 3PECIFICATION2EADY .OW6ALIDATED  .   2ESULT/F%XPERIMENT/R3TUDY)NCONCLUSIVE  !LL3OLUTIONS4O0ROBLEMS!BOUT%NDS#ONTAINING !SSUMPTIONS.

  .

.

  -ODEL/VERALL3OLUTION2EADY 5NDERDEVELOPED!REA)DENTIFIED .ETWORKS2EADY /VERALL3OLUTION2EADY    (YPOTHESIS&ORMULATED    $ESIGN&OR%XPERIMENT/R3TUDY2EADY    %XPERIMENT/R3TUDY#OMPLETE .EW.

O %VENT  7HERE4HE%XPERIMENT/R3TUDY3HOWS4HAT4HE3TATEMENT)N4HE3PECIFICATION)S)NVALID.0HASE#ONTINUED $EVELOPMENT#ONTINUED      6ALIDATE(YPOTHESES#ONTINUED                  N  N     N  N N   N    N  N  N   N N     N     N N        )TEM !CTIVITY !CTIVITY.

4HEN 2EWORK4HE0ROBLEMS!BOUT%NDS%MBODIED)N4HE3TATEMENT.

!ND!LL4HEIR2AMIFICATIONS.

&ROM 7HERE4HE%XPERIMENT/R3TUDY)S)NCONCLUSIVE.

2EITERATE&ROM 7HERE4HE%XPERIMENT/R3TUDY)NDICATES4HAT4HE3PECIFICATION3TATEMENT)S3UPPORTED.

IST4HOSE$ESIGN$ETAILS7HERE$ATA6ALUES7ERE6OLUNTARILY!SSIGNED"Y4HE $ESIGNER3EE . 2EITERATE&ROM5NTIL!LL3TATEMENTS)N4HE0ERFORMANCE3PECIFICATION!RE6ALIDATED )DENTIFY!ND.

!ND7HERE3IMPLIFYING!SSUMPTIONS7ERE-ADE3EE &OR%ACH$ETAIL5NDER.

&ORMULATE(YPOTHESES4O&ACILITATE6ALIDATION/F4HE$ETAIL &OR%ACH(YPOTHESIS5NDER.

OTE!FTER #ONDUCT6ALIDATION%XPERIMENT/R3TUDY!S0LANNED5NDER 7HERE4HE%XPERIMENT/R3TUDY3HOWS4HAT4HE$ESIGN$ETAIL)S)NVALID.$ESIGN!N%XPERIMENT4O4EST4HE(YPOTHESIS!ND6ALIDATE 4HE$ETAIL3EE.

4HEN2EWORK4HE $ETAIL$EVELOPMENT&ROM 7HERE4HE%XPERIMENT/R3TUDY)S)NCONCLUSIVE.

2EITERATE&ROM 7HERE4HE%XPERIMENT/R3TUDY)NDICATES4HAT4HE$ESIGN$ETAIL)S3UPPORTED.

ISTED 5NDER3ECTION!ND4HE0ERFORMANCE3PECIFICATION3ET/UT5NDER.2EITERATE&ROM 5NTIL!LL$ESIGN$ETAILS"ASED5P/N6OLUNTARILY!SSIGNED$ATA!NDOR3IMPLIFYING !SSUMPTIONS!RE6ALIDATED 4AKING4HE'OALS)DENTIFIED5NDER3ECTION!ND4OGETHER7ITH4HE#ONSTRAINTS.

&ORMULATE (YPOTHESES#ALCULATED4O&ACILITATE6ALIDATION/F4HE/VERALL$ESIGNS 5NDER &OR%ACH(YPOTHESIS5NDER.

$EVISE!N%XPERIMENT4O4EST4HE(YPOTHESIS!ND 6ALIDATE4HE$ESIGN3EE.OTE!FTER !SSEMBLE4HE#OLLECTION/F0ROPOSED%XPERIMENTS/R3TUDIES0REPARED5NDER )NTO!6ALIDATION0ROGRAM $ISTINGUISH"ETWEEN6ALIDATION%XPERIMENTS/R3TUDIES4O"E#ARRIED/UT"EFORE #OMMUNICATION/F4HE&INAL$ESIGN3OLUTIONS !ND4HOSE7HICH-UST"E#ARRIED/UT/N -ANUFACTURED-ODELS/R0ROTOTYPES 3ELECT!N!PPROPRIATE6ALIDATION%XPERIMENT/R3TUDY&ROM4HE.IST/F4HOSE7HICH!RE4O"E #ARRIED/UT"EFORE#OMMUNICATION/F4HE&INAL$ESIGN3OLUTIONS .

!ND#ONDUCT%XPERIMENT 7HERE4HE%XPERIMENT/R3TUDY3HOWS4HAT4HE$ESIGN)S)NVALID.

4HEN2EWORK&ROM 7HERE4HE%XPERIMENT/R3TUDY)NDICATES4HAT4HE$ESIGN)S3UPPORTED.

2EITERATE&ROM 7HERE4HE$ESIGN)S3UPPORTED.

2EITERATE&ROM5NTIL!LL3TUDIES4O"E#ARRIED/UT "EFORE#OMMUNICATION/F4HE&INAL$ESIGN3OLUTIONS !RE#OMPLETE 0REPARE!2EPORT/N4HOSE6ALIDATION%XPERIMENTS/R3TUDIES7HICH!RE4O"E#ARRIED/UT/N -ODELS/R0ROTOTYPES    3PECIFICATION3TATEMENT3HOWN4O"E)NVALID   .

   %XPERIMENT/R3TUDY)NCONCLUSIVE  !LL3PECIFICATION3TATEMENTS6ALIDATED                   .

.

.

IST/F$ESIGN$ETAILS"ASED/N!SSUMPTIONS2EADY      (YPOTHESES&ORMULATED  $ESIGN&OR%XPERIMENT/R3TUDY2EADY      %XPERIMENT/R3TUDY#OMPLETE  $ESIGN$ETAIL3HOWN4O"E)NVALID   .   .

   %XPERIMENT/R3TUDY)NCONCLUSIVE  !LL$ESIGN$ETAILS"ASED5PON!SSUMPTIONS.OW 6ALIDATED .

.

.

.

OW2EADY 111 .    (YPOTHESES&ORMULATED    $ESIGN&OR%XPERIMENT/R3TUDY2EADY    6ALIDATION0ROGRAM2EADY    3TUDIES4O"E#ARRIED/UT"EFORE#OMMUNICATION/F 4HE&INAL$ESIGN3OLUTIONS )DENTIFIED  3TUDIES4O"E#ARRIED/UT/N0ROTOTYPES)DENTIFIED  %XPERIMENT/R3TUDY#OMPLETE              $ESIGN3HOWN4O"E)NVALID  %XPERIMENT/R3TUDY)NCONCLUSIVE  !LL6ALIDATION3TUDIES4O"E#ARRIED/UT"EFORE #OMMUNICATION/F4HE$ESIGN#OMPLETE  2EPORT/N6ALIDATION3TUDIES4O"E#ARRIED/UT/N -ANUFACTURED-ODELS/R0ROTOTYPES.

EEDS 3ELECT#OMMUNICATION-EDIUM 0REPARE#OMMUNICATION                     N         N  N   N         )TEM !CTIVITY  #OMMUNICATION   $EFINE#OMMUNICATION.EEDS 2EFERRING4O)NSTRUCTIONS3EE.0HASE #OMMUNICATION $EFINE#OMMUNICATION.

!ND!NY3UBSEQUENT!MENDMENTS!T.

.

 !NDOR.

$ETERMINE!DDRESSEE!ND#HANNEL&OR#OMMUNICATION/F$ESIGN 3IMILARLY2EFERRING4O)NSTRUCTIONS.

!ND!LSO4O#OURSE/F!CTION!DOPTED3EE!ND 3UBSEQUENT!MENDMENTS!T.

!ND .

$ETERMINE7HETHER4HE'ENERAL 3PIRIT.

4HE'EOMETRY!ND0ERFORMANCE/R4HE$ETAILED#ONSTRUCTION/F4HE$ESIGN)S4O"E #OMMUNICATED 2EFERRING4O4HE$EFINITION/F4HE$ESIGN)DEA !ND4HE3TATEMENT/F4HE2ANGE/F 6ARIATION%MBRACEABLE"Y4HE$ESIGN)DEA !ND!LSO4O4HE$EVELOPED/VERALL 3OLUTIONS .

EEDS3ECTION .!PPRAISE7HAT)S4O"E#OMMUNICATED                  3ELECT#OMMUNICATION-EDIUM .IST!LL#OMMUNICATION-EDIA!VAILABLE 2EFERRING4O#OMMUNICATION.

IST 0REPARED5NDER 2EFERRING4O4IMETABLE !ND&ACILITIES .3ELECT3UITABLE-EDIA&ROM4HE.

ECESSARY2EFORMULATE#OURSE/F!CTION0REVIOUSLY3ET/UT)N 0REPARE#OMMUNICATION 2EFERRING4O.3ELECT-EDIUM4O"E5SED)N #OMMUNICATING4HE$ESIGN 2EAPPRAISE!ND)F.

IST7HAT)S4O"E#OMMUNICATED 2EFERRING4O#OMMUNICATION..EEDS!ND .

!ND)N4ERMS/F4HE-EDIUM  .

$ESCRIBE%ACH)TEM5NDER 0REPARE!3CHEDULE/R+EY$IAGRAM/F!LL)TEMS$ESCRIBED 0REPARE!3CHEDULE/R+EY$IAGRAM/F!LL$OCUMENTS/R/THER-EDIA&ORMING0ART /F.

/R2EFERRED4O)N.

4HE#OMMUNICATION "OTH7ITHIN%ACH/F.

!ND"ETWEEN.

4HE4WO3CHEDULES!ND.

)NDEX!LL)TEMS3O 4HAT"OTH4HE#ORRELATION!ND4HE4RACING/F4HE#ONSEQUENCES/F!NY3UBSEQUENT 2EVISION!RE&ACILITATED #HECK%ACH$OCUMENT/R/THER-EDIUM &OR!NY$EFICIENCY)N4HE)TEMS$ESCRIBED #HECK%ACH$OCUMENT/R/THER-EDIUM &OR!NY$EFICIENCY)N4HE-EDIUM)TSELF 2EFERRING4O#OMMUNICATION.EEDS .

%XAMINE#OMPLETED #OMMUNICATION 2EAPPRAISE.

!ND)F.ECESSARY2EFORMULATE.

#OURSE/F!CTION2EAPPRAISED!T 112 !CTIVITY.O %VENT    !DDRESSEE!ND#HANNEL&OR#OMMUNICATION$ETERMINED    $EPTH/F$ETAIL&OR#OMMUNICATION$ETERMINED .

.

   -ATTER&OR#OMMUNICATION!PPRAISED .

.

  .

.

IST/F#OMMUNICATION-EDIA2EADY  .IST/F3UITABLE-EDIA2EADY .   .

.

   -EDIUM&OR#OMMUNICATION3ELECTED .

.

   #OURSE/F!CTION2EFORMULATED .

  .

.

.

    .

IST/F-ATTER&OR#OMMUNICATION  )TEM$ESCRIBED .   .

   3CHEDULES#ROSS)NDEXED .

    .

.

.

.

.

  .

   $OCUMENT#ONTENTS#HECKED  $OCUMENT1UALITY#HECKED  #OMPLETED#OMMUNICATION%XAMINED  )TEM3CHEDULE&OR+EY2EADY  $OCUMENT3CHEDULE/R+EY2EADY  #OURSE/F!CTION2EFORMULATED .

0HASE#ONTINUED #OMMUNICATION#ONTINUED 7INDING5P 0REPARE#OMMUNICATION#ONTINUED 7IND5P0ROJECT #LOSE2ECORDS                 )TEM !CTIVITY !CTIVITY.O %VENT   .

.

.

  .

   2ECORD#OPIES2EADY     4RANSMIT)NFORMATION -AKE3ECURITY!NDOR2ECORD#OPIES/F!LL$OCUMENTS /R/THER-EDIA #OMPILE4HE#OMMUNICATION3ET #HECK&OR#OMPLETENESS %NCLOSE.

!DDRESS!ND$ISPATCH4HE#OMMUNICATION !DVISE$ISPATCH/F#OMMUNICATION4HROUGH!N!LTERNATIVE#HANNEL )N4HE#ASE/F3KETCH$ESIGNS0REPARED5NDER.

#ONTINUE.OW&ROM )N4HE#ASE/F&INAL$ESIGN3UBMISSIONS.

!WAIT!UTHORITY4O4ERMINATE0ROJECT/R.

ECESSARY. 7HERE.

2EITERATE&ROM      #OMMUNICATION3ET$ISPATCHED  !DVICE.OTE$ISPATCHED  7INDING5P       7IND5P0ROJECT .ABEL!ND3TORE#OPY/F4HE#OMMUNICATION!S$ISPATCHED #OMPLETE#OPYRIGHT/R/THER!UXILIARY4RANSACTIONS #OMPLETE&INANCIAL4RANSACTIONS!ND"OOK+EEPING &ORMALLY$ISCHARGE/BLIGATIONS!ND#LOSE#ORRESPONDENCE $ISENGAGE&ROM0ROBLEM!ND#LOSE0ROJECT .

      .

.

         #OMMUNICATION&ILED !UXILIARY4RANSACTIONS#OMPLETE &INANCIAL4RANSACTIONS!ND"OOK+EEPING#OMPLETE #ORRESPONDENCE#LOSED 0ROJECT#LOSED      #LOSE2ECORDS 3TORE.

2ETURN.

$ISPOSE/F.

/R7RITE/FF!LL2EMAINING-ATERIALS!ND%QUIPMENT $ESTROY!LL/BSOLETE!ND4RANSITORY-ATERIAL #OLLATE.

.ABEL!ND3TORE!LL2ECORDS !PPRAISE%XPERIENCE'AINED!ND!DJUST3YSTEMS!ND3TANDARDS   .

          -ATERIALS!ND%QUIPMENT$ISPOSED/F 2EDUNDANT-ATERIAL$ISPOSED/F 2ECORDS3TORED !PPRAISAL/F%XPERIENCE#OMPLETE  #OMMUNICATION3ET#OMPILED 113 .

etc. It could be circular . Finally.” !CCEPT 3ITUATION !NALYZE $EFINE )DEATE 3ELECT )MPLIMENTATION %VALUATE 114 . . Koberg and Bagnall have added feedback to their seven-stage model. a continuum of sequential round trips that go on ad infinitum. It is also possible that the stages can be considered in other ways . . its ultimate model is the spiral. and then as a “horse race” where each stage proceeds concurrently rather than a “mule train” where each stage proceeds one after the next. they note.) They note “one stage need not follow another . and where the stages of the process advance somewhat concurrently until some strong determining variable terminates the process (time. “Process never ends . . . money. (See page 16. . Others see it as a constant feedback system where you never go forward without always looping back to check on yourself. . where one progresses by constant backward relationships.Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972) In this model. . energy.)” Koberg and Bagnall go on to describe alternatives: viewing the design process as a branching system. .

115 . and most design processes include feedback loops. But designers require feedback. In this section we examine models emphasizing feedback and continuous improvement.Cyclic models We tend to think of a process in terms of steps—as a sequence.

(See the previous spread. some of the output signal is split off and “fed back” into the input signal.) We should be careful not to mistake this schematic diagram (or circuit diagram) for the actual design process. 0ROCESS &EEDBACK 116 /UTPUT . (See page 12.Process with feedback (archetype) This simple model recalls our first process model. )NPUT This happens all the time in design—at many levels. More precisely. I include it here to underscore the importance of feedback in designing.) What’s added is a feedback loop.

We’ve seen several analogs of this process—define-prototype-evaluate and design-buildtest. and measure their results to see if they meet their goals—goal-action-feedback. By repeating the cycle. act to accomplish them. a boat pilot tacking to reach port or a thermostat turning a heater on and then off. the system converges on a goal or maintains a steady state. Feedback is the information loop flowing from the system through the environment and back into the system.) Feedback is a central subject of cybernetics.) Designers follow this cycle.Goal-action-feedback loops after Pangaro (2002) Paul Pangaro describes feedback loops in terms of a goalaction-effect-measurement cycle. the science of goal-directed systems. (For example. They have goals. In this model. (See pages 50-51. a system acts to accomplish a goal within its environment. The system measures the effect its actions have on the environment and compares the effect to its goal. Then the system looks for errors and acts (or re-acts) to correct them. 'OAL $ESIRED3TATE THROUGHSYSTEM -EASUREMENT 3YSTEMMEASURESITSPROGRESS COMPARINGCURRENTSTATETODESIREDSTATE DETERMININGTHEDIFFERENCE. Cybernetics has much to teach us about fundamental structures of design.

ANDATTEMPTINGTOCORRECTTHE@ERROR THROUGHENVIRONMENT !CTION 3YSTEMATTEMPTSTOREACHAGOAL BASEDONFEEDBACK.

ITMODIFIESITSACTIONS 3YSTEMACTSBOTHWITHINITSELF ANDONITSENVIRONMENT &EEDBACK TRANSFEROFINFORMATION %FFECT #URRENT3TATE 117 .

See the next page for an example. That is. Thus we may improve our model of designing by nesting our original feedback loop within a second feedback loop. 'OAL $ESIRED3TATE THROUGHBOTHSYSTEMS -EASUREMENT 3ECOND ORDERSYSTEMMEASURESTHE EFFECTOFTHEFIRST ORDERSYSTEMSACTION "ASEDONTHATINFORMATION.) The human creates a second loop in which the “action” is setting the goal of the first loop. defining the set-point for a thermostat. (For example. it provides no mechanism for changing or refining the system’s goal.) As we’ve seen. designing involves not only achieving goals but also defining them. (Like the thermostat. Typically.Second-order feedback loops after Pangaro (2002) The model on the previous page assumes a constant goal. such systems are mechanical (or electronic) and require humans to set their goals. the human also measures the room temperature and decides whether to raise or lower the set-point on the thermostat.

THESECOND ORDERSYSTEMMODIFIESITSACTIONn RESETTINGTHEGOALOFTHEFIRST ORDERSYSTEM THROUGHENVIRONMENT !CTION 3ECOND ORDERSYSTEMATTEMPTSTOREACHITSGOAL BYCONTROLLINGTHEGOALOFAFIRST ORDERSYSTEM 'OAL $ESIRED3TATE &EEDBACK.OOP TRANSFEROFINFORMATION THROUGHTHEFIRST ORDERSYSTEM -EASUREMENT 3YSTEMMEASURESITSPROGRESS COMPARINGCURRENTSTATETODESIREDSTATE DETERMININGTHEDIFFERENCE.

ANDATTEMPTINGTOCORRECTTHE@ERROR THROUGHENVIRONMENT &EEDBACK.OOP TRANSFEROFINFORMATION %FFECT #URRENT3TATE 118 !CTION &IRST ORDERSYSTEMATTEMPTSTOREACHAGOAL BASEDONFEEDBACK.

ITMODIFIESITSACTIONS 4HEFIRST ORDERSYSTEMACTSBOTHWITHINITSELF ANDONITSENVIRONMENT .

Bootstrap.org. His paper ‘Toward High-Performance Organizations: A Strategic Role for Groupware’ argues that highest payoff comes from engaging in that C-activity. Douglas Engelbart offered “an optimized bootstrapping approach for drastically improving on any organization’s already existing improvement processes. second-.Bootstrapping or improving improvement after Douglas Engelbart (1992) In 1992. he denotes bootstrapping as a C- activity. and third-order feedback loops.” Levels A. and C are analogous to first-. the process works as follows. “Referring to an organization’s principal work as an A-activity and to ordinary efforts at process improvement as a B-activity. GOALIMPROVEMEANSOFIMPROVEMENT OBSERVESUCCESS CODIFY ROLL OUT CORPORATEQUALITYMANAGEMENTPROCESS GOALIMPROVELOCALPROCESS OBSERVEPROBLEM PROTOTYPE TESTCHANGE LOCALQUALITYMANAGEMENTPROCESS GOALMAINTAINQUALITYOUTPUT INPUT PRODUCTION OUTPUT LOCALPROCESS 119 . which is an improving of the improvement process.” According to his foundation. B.

Product development process after Stuart Pugh (1990) Pugh published this model in his book. Total Design: Integrated Methods for Successful Product Engineering. His reasons for presenting it as a cylinder are not clear from the diagram itself. -ARKET #OMPETITION #OMPETITION!NALYSIS 3PECIFICATION )NFO!CQUISITION 3YNTHESIS #ONCEPT$ESIGN #ONCEPT3ELECTION $ATA(ANDLING $ETAIL$ESIGN /PTIMIZATION #OST0ATTERNS -ANUFACTURE -ARKET4RENDS 3ELL 120 .

there is a strong implication that the eventual synthesis of information in the form of some designed object follows in a straightforward fashion from analysis of the problem at hand together with likely performance criteria. Peter Rowe (1987) notes that Mesarovic’s model is similar in structure to Asimow’s. and with feedback loops among them. with a beginning and an end. that such distinctions have relevance to our understanding of design. Therefore. “The very maintenance of distinct phases of activity.Iconic model of the design process after Mihajlo D.” Rowe describes this view as “behaviorist” and also links it to “operations research”. Moreover.) “Throughout this kind of account runs the assumption that it is possible to discriminate distinct phases of activity and. Mesarovic employs a helix as the central structure. ! # 3 !BSTRACT $EFINITIONOF.EED % &EASIBILITY3TUDY 0RELIMINARY$ESIGN $ETAILED$ESIGN 0RODUCTION0LANNING #ONCRETE (OST%NVIRONMENT 0RODUCTION !NALYSIS #OMMUNICATION 3YNTHESIS %VALUATION 121 . once a problem has been defined.” Rowe continues. further more. requires that objective performance criteria can be explicitly stated in a manner that fundamentally guides the procedure. (See pages 92-95. Mesarovic (1964) In this model. suggesting both a repeated cycle of steps and progress through time. its solution is made directly accessible in terms of that definition.

The angular dimension represents the progress made in completing each cycle.Spiral model of software development after Barry Boehm (1986) Boehm represented repeating cycles of design with a spiral path moving away from a center starting point.Planning the next phases” $ETERMINE/BJECTIVES.Objective setting . One phase is split roughly into four sectors of major activities . “The radial dimension of the model represents the cumulative costs when finishing the steps. Boehm introduces a focus on risk reduction. Gary Schmidt of Washburn University offers this description of Boehm’s model.Development and validation . In addition to the spiral shape. Each loop of the spiral from x-axis clockwise through 360 represents one phase.Risk assessment and reduction .

!LTERNATIVESAND#ONSTRAINTS %VALUATE!LTERNATIVES.

)DENTIFYAND2ESOLVE2ISKS 2ISK!NAYLSIS 2ISK!NAYLSIS 2ISK!NAYLSIS 2ISK!NAYLSIS 0ROTOTYPE  3IMULATIONS.

-ODELS.

EXT0HASES 122 $EVELOPAND6ERIFY .AND"ENCHMARKS 2EQUIREMENT0LAN #ONCEPT $EVELOPMENT0LAN 2EQUIREMENTS6ALIDATION )NTEGRATIONAND4EST0LAN 0ROTOTYPE /PERATIONAL $ESIGN6ALIDATIONAND6ERIFICATION &INAL#ODE)MPLEMENTATIONAND4EST 0LAN.

MacDonald notes. What Is Web Design?. “The model requires that the product must be the right thing to make. BodyMedia.” Note also Pacione’s variation on the 4Ds—in this case define-design-delve-determine. posits designers as synthesizers and indicates the relationship with users is on-going. Nico MacDonald (2003) published a similar model Pacione developed for his company.BodyMedia product development process after Chris Pacione (2002) In his book. (See page 62.) 4HE"ODY-EDIA0RODUCT$EVELOPMENT0ROCESS-ODEL ISBASEDON$R"ARRY"OEHMS3PIRALMETHODANDIS DESIGNEDTOPROMOTE $ETERMINE $EFINE FLEXIBILITY PARALLELWORK CONSTANTANDCLEARCOMMUNICATION EFFICIENCY SERENDIPITYANDSYNERGY MULTIPLEITERATIONS RAPIDPROTOTYPING SMART.

HUMANCENTRICSOLUTIONS RISKMANAGEMENT PREDICTABILITY ( $ ' -OREGENERAL LESSSPECIFICISSUES NODETAILS ARCHITECTURE SKETCHES ROUGHDRAFTOFCONTENT QUICKPROTOTYPES .ESSGENERAL MORESPECIFICISSUES 5)DETAILS CODEDEBUGGING CONTENTTWEAKS ! # % ) " & .AUNCH $ESIGNAND CONTENTFREEZE * #ODEFREEZE $ELVE $ESIGN ! $EFINE "RAINSTORMAND+ICKOFF " $ESIGN THE)NFORMATION!RCHITECTUREANDQUICKINTERACTIVEPROTOTYPES " # $ELVE INTOPROTOTYPEANDTESTTHEUSEFULLNESSOFTHEIDEA # $ $ETERMINE THEWEAKNESS.

STRENGTHSANDRISKS.

TIMECONSTRAINTS $ % $EFINE NEWALTERNATIVES.

ANDSOLUTIONS % & $ESIGN UPDATEARCHITECTURE.

CONTENT.

CODEAND5)OFINTERACTIVEPORTOTYPE & ' $ELVE INTOREFINEDSOLUTION.

TESTFORUSABILITY.

ANDMAJORBUGS ' ( $ETERMINE SOLUTIONSWEAKNESSES.

STRENGHTS.

RISKS.

TIMECONSTRAINTS ( ) $EFINE WHATNEEDSTOCAN CHANGEWITHCODE.

5) ) * $ESIGN $ESIGNANDCONTENTFREEZES.

ALLSPECSDUE#ODEFREEZE ! * &INALTESTINGAND1!.

.AUNCH 123 .

In Boehm’s model.Design process after Paul Souza (1996) Souza also used a spiral path to represent repeating cycles in the design process. In Souza’s model. the path travels in toward the center suggesting the process converges on a goal. the spiral travels out from the center suggesting—though perhaps not intentionally—that the process diverges. Traveling outward could also suggest adding increasing amounts of detail. 124 .

his teaching and research includes a focus on understanding innovation. a hunch. 3YNTHESIS !BSTRACT &RAME )NSIGHTS h!HAv %XPLORE #ONCEPTS h%UREKAv -AKE 0LANS (YPOTHESIS  +NOW +NOW 5SER +NOW #ONTEXT -AKE 2EALIZE /FFERINGS [ 0ROTOTYPE 0ILOT . Technology.Innovation planning after Vijay Kumar (2003) Kumar presented this model at the 2003 HITS Conference (Humans.AUNCH )MPLEMENT  2ESEARCH 2EAL $ELIVERY 125 . He has also mapped tools and methods onto each of the modes. Kumar teaches at the Illinois Institute of Technology’s Institute of Design. genius. He spoke of innovation as the jump from insight !NALYSIS to concept—from aha to eureka—describing it as a revelation. Strategy) in Chicago. He described modes of planning (rather than steps) emphasizing the iterative and interconnected nature of the design process. magic. intuition. Interaction.

4. And each successive iteration builds on the work of previous iterations to evolve and refine the system until the final product is complete. “Each iteration includes some or most of the development disciplines (requirements.) 2EQUIREMENTS "USINESS-ODELING !NALYSISAND$ESIGN 0LANNING #ONFIGURATIONAND#HANGE -ANAGEMENT )MPLEMENTATION %NVIRONMENT )NITIAL0LANNING 4EST %VALUATION 126 $EPLOYMENT .Rational Unified Process iteration cycle after Per Kroll (2004) Iteration is a central principle of the Rational unified process. design. Baseline an executable architecture early on. later iterations emphasize implementation and testing. Divide the detailed design. Adopt an iterative and risk-driven management process. Each iteration also has a well-defined set of objectives and produces a partial working implementation of the final system. 2. 3. Build functional prototypes early. Kroll is director of the Rational Unified Process development and product management teams at IBM. analysis. implementation and test phases into iterations. Early iterations emphasize requirements as well as analysis and design.” Knoll suggests four principles: 1. Kroll notes. (For another model of RUP. see page 67. implementation and [testing activities].

The length of each loop increases from bottom to top of the model.org published this hypertext model depicting nested feedback loops within the XP development process. The model also serves as a sort of table of contents for key ideas in extreme programming. (For other models of extreme programming.) 2ELEASE0LAN -ONTHS )TERATION0LAN 7EEKS !CCEPTANCE4EST $AYS 3TAND5P-EETING /NE$AY 0AIR. see pages 70-71.EGOTIATION (OURS 5NIT4EST -INUTES 0AIR0ROGRAMMING 3ECONDS #ODE 127 .Extreme programming planning/feedback loops after Don Wells (2000) Extremeprogramming.

2ELIABILITY -AINTAINABILITY 3YNTHESIS !NALYSIS !VAILABILITY 4HE$ESIGN0ROCESS $EPENDABILITY 4ESTING -ATERIAL 3ELECTION #OST"ENEFIT -ANUFACTURABILITY 128 .Engineering design process after Atila Ertas and Jesse C. Did the authors intend to frame design as a mechanical process? It’s also unusual to see a model begin with synthesis— or include “materials selection” at the same level of abstraction. Jones (1996) This model is interesting in its use of the gear metaphor. The inclusion of the six considerations or constraints is also unusual.

Product development process: overview after Hewlett Packard (circa 2000) Loops or circular layouts are curiously rare in design process models—with the notable exception of the PDCA cycle on the next page. Koberg and Bagnall provide another example by simply turning their seven-step process into a circle. 0RODUCT2ELEASE 0LANNING 2EQUIREMENTS 3YSTEM4EST $EVELOPMENT /UR&OCUS n5SERANALYSIS.

REQUIREMENTS n0RODUCTDEFINITION.

DESIGN.

ANDDEVELOPMENTFOREASEOFUSE ANDUSEFULNESS $ESIGN /THER%LEMENTSOFTHE#USTOMER%XPERIENCE n/RDERING.

DELIVERY n$OCUMENTATION n)NSTALLATION n)NTEGRATIONWITHRDPARTYPRODUCTS n#USTOMERSUPPORT 129 .

It is also known as the Shewhart cycle or the Deming cycle. according to the American Society for Quality (ASQ). a standard principle of quality assurance and management.PDCA quality cycle after Walter A. Shewart (1939) PDCA stands for plan-do-check-act cycle of continuous improvement. $ETERMINETHEROOTCAUSEOFTHEPROBLEM THENPLANACHANGEORATEST AIMEDATIMPROVEMENT #ARRYOUTTHECHANGEORTHETEST. the first place he discussed the PDCA concept.” In 1939. The mathematician Walter A. Shewhart was concerned with what he called “the formulation of a scientific basis for securing economic control. he published Statistical Method from the Viewpoint of Quality Control.

PREFERABLYINAPILOTORONASMALLSCALE 0LAN $O !CT #HECK !DOPTTHECHANGE.

IFTHEDESIREDRESULTWASACHIEVED )FTHERESULTWASNOTDESIRED.

the focus of quality management has expanded from manufacturing processes to include a systemic view of customer satisfaction. REPEATTHECYCLEUSINGKNOWLEDGEOBTAINED 130 Edward Deming worked with Shewhart at Bell Laboratories and later popularized the PDCA cycle. the ISO 9001 standard includes the PDCA cycle. PDCA and PDSA have many incarnations and many definitions. Deming substituted “study” for “check”. #HECKIFTHEDESIREDRESULTWASACHIEVED. especially in Japan. Over the last 20 years. For example.

WHAT.

IFANYTHING.

WENTWRONG.

ANDWHATWASLEARNED .

But the options for action include changing goals and thus suggest a more complex process than is represented in the model. $EPLOYSPROBESANDGATHERAWIDERANGEOF SIGNALS. Haeckel (2003) Haeckel proposed this process for managing within a changing environment.Adaptability loop after Stephan H. At first. it appears to be a classic feedback-based control loop.

FROMHARDDATATOFINANCAILREPORTSTO CONVERSATIONSWITHCUSTOMERS.

TOSPOTIMPENDING CHANGEINYOURBUSINESSENVIRONMENT.

YOUR CUSTOMERSBUSINESSESANDTHEIRCUSTOMERS BUSINESSES)NTERNALLY.

TRACKBREAKDOWNSINYOUR ORGANIZATIONSPERFORMANCE.

ANDVIOLATIONSOF COMMITMENTSANDBASICRULES3CANFOR CAPABILITIESFIRMSINOTHERINDUSTRIESHAVETHATYOU MIGHTFINDUSEFUL!LLDATASHOULDBEVIEWABLEON 0#SANDHANDHELDS Haeckel’s model may also be interpreted as a variation on the classic PDCA cycle. (Some variations on the model include it.) The authors may have chosen a simpler representation to make it easy to communicate and remember. 5SEAVARIETYOFTECHNOLOGIESANDTECHNIQUETO UNDERSTANDTHEMEANINGOFWHATYOURPROBESARE SENSING. It’s interesting to note that the PDCA cycle also implies but does not represent a process for changing goals.

ANDWHYCOMMITMENTSBETWEENROLES BREAKDOWN&OREXAMPLE.

SCENARIOPLANNINGCAN HELPIDENTIFYANDPREPAREFORWAYSTHEFUTUREMAY UNFOLD.

WAR GAMINGHELPSLEADERSTHINKTHROUGH VARIOUSRESPONSESTOCHANGE.

ANDCOLLABORATIVE DECISION MAKINGHELPSLEADERSDECIDEHOWTO ALLOCATELIMITEDRESOURCESINUNPREDICTABLE ENVIRONMENTS4HISINFORMATIONSHOULDBE VIEWABLEONSCREEN 3ENSE )NTERPRET !CT $ECIDE !SLEADER.

PUBLICLYPROCLAIMTHENEWRAISONDÐTRE.

BASICRULESANDROLES.

ORˆIFNOCHANGEISREQUIRED ATTHETIMEˆAFFIRMTHEOLDONES7HENCHANGING ANYROLES.

MAKESURETHERIGHTPEOPLEEXECUTE THEMANDTHATTHEIRCOMMITMENTSTOOTHERSWITHIN THEORGANIZATIONAREADJUSTEDTOREFLECTANYNEW DESIREDOUTCOMES.

.IKEWISE.

INSTALLORUPGRADE ELECTRONICINFORMATIONSYSTEMSTODISPLAYTHE UPDATEDCOMMITMENTSASWELLASANYNEW hSENSEvANDhINTERPRETvINFORMATIONNOWREQUIRED 3HOULDORGANIZATIONSRAISONDÐTRE.

POLICIES ORROLEANDACCOUNTABILITYDESIGNCHANGE&OR EXAMPLE.

IFCOMMITMENTSAREREPEATEDLYBROKEN.

IFNEWCAPABILITIESARENTBEINGINCORPORATED.

ETC &REQUENTLYCHALLENGEDPOLICIESMIGHTNEEDTOBE RELAXED.

TIGHTENEDORELIMINATED4HERAISONDÐTRE MIGHTNEEDCHANGINGIFTHEREAREBIGORSUDDEN SHIFTSINTHEMARKETPLACEORINTHEVALUESAND PREFERENCESOFYOURMOSTIMPORTANTCUSTOMERS ANDOTHERCONSTITUENTS 131 .

Parshall (1969) 22 Diverge / Converge vs Narrow / Expand 23 Decomposition / recombination after VDI 2221 (from Cross 1990) 24 Dynamics of divergence and convergence after Bela H. French (1985) 32 VDI 2221: System Approach to the Design of Technical Systems and Products after Verein Deutscher Ingenieure (1987) 33 Design process after Gerhard Pahl and Wolfgang Beitz (1984) 34 Architect’s Plan of Work (schematic) after the Royal Institute of British Architects Handbook (1965) 35 Architect’s Plan of Work. a model of the scientific method . Synthesis after Koberg and Bagnall (1972) 15 Problem. Solution after JJ Foreman (1967) 16 Expanding the two-step process after Don Koberg and Jim Bagnall (1972) 17 Matching process to project complexity after Jay Doblin (1987) 18 Unself-conscious and self-conscious design after Christopher Alexander (1962) Analysis synthesis evaluation 20 Oscillation 21 Programming and designing after William M. Havlick (1976) 38 THEOC.Complete list of models Introducing process 10 Design Process after Tim Brennan (~1990) 12 Process archetype 13 On the infinite expandability of process models 25 Overall. (detailed) after the RIBA Handbook (1965) 36 Problem solving process after George Polya (1945) 37 Scientific problem solving process after Cal Briggs and Spencer W. Banathy (1996) 132 28 Walking process after Lawson (1980) 30 Four-stage design process after Nigel Cross (2000) 31 Engineering design process after Michael J. the design process must converge after Nigel Cross (2000) 26 Gradual shift of focus from analysis to synthesis after Bill Newkirk (1981) 27 Problem to solution: sequence or parallel process or loop? Academic models 14 Design process archetype: Analysis. Pena and Steven A.

Marcus (1969) and Thomas W Maver (1970) 47 Process of designing solutions after Clement Mok and Keith Yamashita (2003) 48 Case study. Ulrich (1995) 41 Design Process and Practice after Richard Buchannan (1997) 57 Design Process after John Chris Jones (1970) 42 Creative process after Bryan Lawson (1980) 58 Value analysis after John Chris Jones (1970) 43 Primary generator after Jane Darke (1978) 59 Man-machine system designing after John Chris Jones (1970) 44 Design process after Jane Darke (1978) Consultant models 45 Design process after Thomas A. build. test (1 of 3) after Alice Agogino 52 Design.39 Criteria of validation of scientific explanations (CVSE) after Humberto Maturana (1987) 54 Mechanical engineering design process after students at UC Berkeley Institute of Design (BID) 40 Comprehensive anticipatory design science after Buckminster Fuller (1978?) 55 New product development process after Steven D. build. using the AIGA process in Iraq by Nathan Felde (2003) 49 What the AIGA didn’t tell you by Nathan Felde (2003) 51 Design. build. test (2 of 3) after Alice Agogino 53 Design. Eppinger and Karl T. test (3 of 3) after Alice Agogino 60 Eight phases of a project Sometimes presented as six phases of a project 62 4D software process and variations 63 IT consulting process overview after Mindtree Consulting 65 IDEO (2004) 66 Trees Software development models 68 Waterfall lifecycle after Philippe Kruchten (2004) 69 Rational Unified Process (RUP) after Phillippe Kruchten (2003) 133 .

IABG (1992) 88 Goal-directed design process after Alan Cooper (2001) 73 Joint Application Development (JAD) after Jane Wood and Denise Silver (1995) 90 Idealized process of developing buildings after Alan Cooper (2004) 74 PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987) 91 Idealized process of developing software after Alan Cooper (2004) 75 ISO 13407 Human-centered design processes for interactive systems Tom Stewart et al. (1999) 93 Morphology of design after Morris Asimow (1962) 76 User-centered design process (UCD) after Karel Vredenburg (2003) 77 Relation of UCD to IPD and Business Management after Karel Vredenburg (2003) 78 Sun Sigma Framework DMADV methodology for new products 97 Biological sequence of problem solving after Bruce Archer (1963-1964) 98 Basic design procedure after Bruce Archer (1963-1964) 99 Check list for product designers Bruce Archer (1963-1964) Cyclic models 79 Sun Sigma Framework DMAIC methodology for improving existing products 80 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product instances 81 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product lines 114 Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972) 116 Process with feedback (archetype) 117 Goal-action-feedback loops after Pangaro (2002) Complex linear models 118 Second-order feedback loops after Pangaro (2002) 84 Web development process after Vanguard Group (circa 1999) 119 Bootstrapping or improving improvement after Douglas Engelbart (1992) 134 .Complete list of models continued 70 Extreme Programming (XP) Process after Don Wells (2000) 87 Evolution of the software development process after Alan Cooper (2001) 72 V model Paul Rock (~1980).

Mesarovic (1964) 122 Spiral model of software development after Barry Boehm (1986) 123 BodyMedia product development process after Chris Pacione (2002) 124 Design process Paul Souza (1999?) 125 Innovation planning after Vijay Kumar (2003) 126 Rational Unified Process iteration cycle Per Kroll (2004) 127 Extreme programming planning/feedback loops after Don Wells (2000) 128 Engineering design process after Atila Ertas and Jesse C. Jones (1996) 129 Product development process: overview Hewlett Packard (circa 2000) 130 PDCA quality cycle after Walter A.120 Product development process after Stuart Pugh (1990) 121 Iconic model of the design process after Mihajlo D. Shewart (1939) 131 Adaptability loop after Stephan H. Haeckel (2003) 135 .

Pena and Steven A. Marcus (1969) and Thomas W Maver (1970) 42 Creative process after Bryan Lawson (1980) 21 Programming and designing after William M. (detailed) after the RIBA Handbook (1965) 40 Comprehensive anticipatory design science after Buckminster Fuller (1978?) 15 Problem.Chronological list 130 PDCA quality cycle after Walter A. Mesarovic (1964) 43 Primary generator after Jane Darke (1978) 34 Architect’s Plan of Work (schematic) after the Royal Institute of British Architects Handbook (1965) 44 Design process after Jane Darke (1978) 35 Architect’s Plan of Work. Havlick (1976) 121 Iconic model of the design process after Mihajlo D. Shewart (1939) 57 Design Process after John Chris Jones (1970) 36 Problem solving process after George Polya (1945) 58 Value analysis after John Chris Jones (1970) 18 Unself-conscious and self-conscious design after Christopher Alexander (1962) 59 Man-machine system designing after John Chris Jones (1970) 93 Morphology of design after Morris Asimow (1962) 14 Design process archetype: Analysis. Synthesis after Koberg and Bagnall (1972) 97 Biological sequence of problem solving after Bruce Archer (1963-1964) 16 Expanding the two-step process after Don Koberg and Jim Bagnall (1972) 98 Basic design procedure after Bruce Archer (1963-1964) 114 Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972) 99 Check list for product designers Bruce Archer (1963-1964) 37 Scientific problem solving process after Cal Briggs and Spencer W. Solution after JJ Foreman (1967) 28 Walking process after Lawson (1980) 45 Design process after Thomas A. Parshall (1969) 26 Gradual shift of focus from analysis to synthesis after Bill Newkirk (1981) 136 .

Ulrich (1995) 87 Evolution of the software development process after Alan Cooper (2001) 137 . Banathy (1996) 122 Spiral model of software development after Barry Boehm (1986) 128 Engineering design process after Atila Ertas and Jesse C. Jones (1996) 17 Matching process to project complexity after Jay Doblin (1987) 41 Design Process and Practice after Richard Buchannan (1997) 39 Criteria of validation of scientific explanations (CVSE) after Humberto Maturana (1987) 124 Design process Paul Souza (1999?) 74 PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987) 75 ISO 13407 Human-centered design processes for interactive systems Tom Stewart et al. French (1985) 24 Dynamics of divergence and convergence after Bela H. (1999) 32 VDI 2221: System Approach to the Design of Technical Systems and Products after Verein Deutscher Ingenieure (1987) 84 Web development process after Vanguard Group (circa 1999) 10 Design Process after Tim Brennan (~1990) 129 Product development process: overview Hewlett Packard (circa 2000) 23 Decomposition / recombination after VDI 2221 (from Cross 1990) 25 Overall. Eppinger and Karl T.33 Design process after Gerhard Pahl and Wolfgang Beitz (1984) 73 Joint Application Development (JAD) after Jane Wood and Denise Silver (1995) 31 Engineering design process after Michael J. the design process must converge after Nigel Cross (2000) 120 Product development process after Stuart Pugh (1990) 30 Four-stage design process after Nigel Cross (2000) 119 Bootstrapping or improving improvement after Douglas Engelbart (1992) 70 Extreme Programming (XP) Process after Don Wells (2000) 72 V model Paul Rock (~1980). IABG (1992) 127 Extreme programming planning/feedback loops after Don Wells (2000) 55 New product development process after Steven D.

Haeckel (2003) 69 Rational Unified Process (RUP) after Phillippe Kruchten (2003) 125 Innovation planning after Vijay Kumar (2003) 76 User-centered design process (UCD) after Karel Vredenburg (2003) 77 Relation of UCD to IPD and Business Management after Karel Vredenburg (2003) 90 Idealized process of developing buildings after Alan Cooper (2004) 138 .Chronological list continued 88 Goal-directed design process after Alan Cooper (2001) 91 Idealized process of developing software after Alan Cooper (2004) 123 BodyMedia product development process after Chris Pacione (2002) 65 IDEO (2004) 117 Goal-action-feedback loops after Pangaro (2002) 126 Rational Unified Process iteration cycle Per Kroll (2004) 118 Second-order feedback loops after Pangaro (2002) 68 Waterfall lifecycle after Philippe Kruchten (2004) 47 Process of designing solutions after Clement Mok and Keith Yamashita (2003) 48 Case study. using the AIGA process in Iraq by Nathan Felde (2003) 49 What the AIGA didn’t tell you by Nathan Felde (2003) 131 Adaptability loop after Stephan H.

a model of the scientific method 63 IT consulting process overview after Mindtree Consulting 66 Trees 78 Sun Sigma Framework DMADV methodology for new products 79 Sun Sigma Framework DMAIC methodology for improving existing products 80 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product instances 81 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product lines 139 . build. build. test (3 of 3) after Alice Agogino 54 Mechanical engineering design process after students at UC Berkeley Institute of Design (BID) 60 Eight phases of a project Sometimes presented as six phases of a project 62 4D software process and variations 12 Process archetype 13 On the infinite expandability of process models 19 *Analysis synthesis evaluation 20 Oscillation 22 Diverge / Converge vs Narrow / Expand 27 Problem to solution: sequence or parallel process or loop? 38 THEOC. test (1 of 3) after Alice Agogino 52 Design.Dates not found Produced for this book (2004) 51 Design. test (2 of 3) after Alice Agogino 116 Process with feedback (archetype) 53 Design. build.

test (3 of 3) after Alice Agogino 90 Idealized process of developing buildings after Alan Cooper (2004) 18 Unself-conscious and self-conscious design after Christopher Alexander (1962) 91 Idealized process of developing software after Alan Cooper (2004) 97 Biological sequence of problem solving after Bruce Archer (1963-1964) 25 Overall. Ulrich (1995) 37 Scientific problem solving process after Cal Briggs and Spencer W. Eppinger and Karl T. build. test (1 of 3) after Alice Agogino 87 Evolution of the software development process after Alan Cooper (2001) 52 Design.Author list 51 Design. test (2 of 3) after Alice Agogino 88 Goal-directed design process after Alan Cooper (2001) 53 Design. the design process must converge after Nigel Cross (2000) 98 Basic design procedure after Bruce Archer (1963-1964) 30 Four-stage design process after Nigel Cross (2000) 99 Check list for product designers Bruce Archer (1963-1964) 43 Primary generator after Jane Darke (1978) 93 Morphology of design after Morris Asimow (1962) 44 Design process after Jane Darke (1978) 24 Dynamics of divergence and convergence after Bela H. Havlick (1976) 128 Engineering design process after Atila Ertas and Jesse C. using the AIGA process in Iraq by Nathan Felde (2003) 140 . build. Jones (1996) 41 Design Process and Practice after Richard Buchannan (1997) 48 Case study. Banathy (1996) 17 Matching process to project complexity after Jay Doblin (1987) 122 Spiral model of software development after Barry Boehm (1986) 119 Bootstrapping or improving improvement after Douglas Engelbart (1992) 10 Design Process after Tim Brennan (~1990) 55 New product development process after Steven D. build.

Synthesis after Koberg and Bagnall (1972) 47 Process of designing solutions after Clement Mok and Keith Yamashita (2003) 16 Expanding the two-step process after Don Koberg and Jim Bagnall (1972) 26 Gradual shift of focus from analysis to synthesis after Bill Newkirk (1981) 114 Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972) 123 BodyMedia product development process after Chris Pacione (2002) 141 .49 What the AIGA didn’t tell you by Nathan Felde (2003) 126 Rational Unified Process iteration cycle Per Kroll (2004) 131 Adaptability loop after Stephan H. French (1985) 125 Innovation planning after Vijay Kumar (2003) 40 Comprehensive anticipatory design science after Buckminster Fuller (1978?) 28 Walking process after Lawson (1980) 129 Product development process: overview Hewlett Packard (circa 2000) 42 Creative process after Bryan Lawson (1980) 65 IDEO (2004) 45 Design process after Thomas A. Solution after JJ Foreman (1967) 68 Waterfall lifecycle after Philippe Kruchten (2004) 31 Engineering design process after Michael J. Mesarovic (1964) 59 Man-machine system designing after John Chris Jones (1970) 63 IT consulting process overview after Mindtree Consulting 14 Design process archetype: Analysis. Marcus (1969) and Thomas W Maver (1970) 57 Design Process after John Chris Jones (1970) 39 Criteria of validation of scientific explanations (CVSE) after Humberto Maturana (1987) 58 Value analysis after John Chris Jones (1970) 121 Iconic model of the design process after Mihajlo D. Haeckel (2003) 69 Rational Unified Process (RUP) after Phillippe Kruchten (2003) 15 Problem.

(detailed) after the RIBA Handbook (1965) 72 V model Paul Rock (~1980). IABG (1992) 130 PDCA quality cycle after Walter A. Shewart (1939) 124 Design process Paul Souza (1999?) 75 ISO 13407 Human-centered design processes for interactive systems Tom Stewart et al. Pena and Steven A. Parshall (1969) 74 PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987) 36 Problem solving process after George Polya (1945) 120 Product development process after Stuart Pugh (1990) 34 Architect’s Plan of Work (schematic) after the Royal Institute of British Architects Handbook (1965) 35 Architect’s Plan of Work. (1999) 142 81 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product lines 84 Web development process after Vanguard Group (circa 1999) 76 User-centered design process (UCD) after Karel Vredenburg (2003) 77 Relation of UCD to IPD and Business Management after Karel Vredenburg (2003) 32 VDI 2221: System Approach to the Design of Technical Systems and Products after Verein Deutscher Ingenieure (1987) 23 Decomposition / recombination after VDI 2221 (from Cross 1990) 70 Extreme Programming (XP) Process after Don Wells (2000) 127 Extreme programming planning/feedback loops after Don Wells (2000) 73 Joint Application Development (JAD) after Jane Wood and Denise Silver (1995) .Author list continued 33 Design process after Gerhard Pahl and Wolfgang Beitz (1984) 78 Sun Sigma Framework DMADV methodology for new products 117 Goal-action-feedback loops after Pangaro (2002) 79 Sun Sigma Framework DMAIC methodology for improving existing products 118 Second-order feedback loops after Pangaro (2002) 80 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product instances 21 Programming and designing after William M.

a model of the scientific method 143 .Authors not identified Produced for this book (2004) 54 Mechanical engineering design process after students at UC Berkeley Institute of Design (BID) 116 Process with feedback (archetype) 60 Eight phases of a project Sometimes presented as six phases of a project 12 Process archetype 13 On the infinite expandability of process models 62 4D software process and variations 19 *Analysis synthesis evaluation 66 Trees 20 Oscillation 22 Diverge / Converge vs Narrow / Expand 27 Problem to solution: sequence or parallel process or loop? 38 THEOC.

Kruchten. Randall D. 2001. 2d ed. Scott. The Journal of Defense Software Engineering.Bibliography Alexander. Banathy. . Developments in Design Methodology. Cross.” IBM developerWorks web site. Don. The Tree of Knowledge: The Biological Roots of Human Understanding. 2000. Engineering Design Methods: Strategies for Product Design. Bela H. Vol. What Is Web Design? RotoVision. June. 2004. 1995. Van Nostrand Reinhold. Alan. Morris. About Face: The Essentials of User Interface Design IDG Books.” IBM developerWorks web site. Joey F. rev. 2004. Dubberly. Human-centered design processes for interactive systems. L. ISO 13407: 1999. “Alan Cooper and the Goal-directed Design Process. Universal Traveler. Lawson. Alan. “The Power of Design” Business Week. 4th ed. Archer. Jim and Koberg. Maturana. Number 2. Christopher. and Peña. Jesse C. 144 Kruchten.” CrossTalk. John Wiley & Sons. and Graham. 4. Cooper.1996. and Varela. John Wiley & Sons. Philippe. Design magazine. 2d ed. The Engineering Design Process. Prentice-Hall. Per. Morton. not harder: An interview with Kent Beck. rev. 1964. No. Philippe. John Wiley & Sons. Design Methods. 2002. Bruce.” Software Development. 3d ed. Cooper. Brian. and George. Nico. Bagnall. 2d ed. 2003.” Communications of the ACM. 2d ed. Crisp Publications.” IBM developerWorks web site. “Working smarter. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity SAMS. Goldsmith. Cross. Nigel. 1992. Dorothy. May 17. 1962. “Systematic Method for Designers”. William M.. Introduction to Design. 1996. 1984. July. 2001 Ertas. PMI. 2000. 2004.” AIGA Gain. 1999. “Going Over the Waterfall with the RUP. John Wiley & Sons. 1963-1964. Asimow. Hugh. 2003. “The V Model. Robin F. Whitaker. Francisco J. Steven A. Hirschberg. Plenum Press.. Kroll. MacDonald. Plamondon.. 1991. Nassbaum. 2003. Notes on the Synthesis of Form MIT Press. “Transitioning from waterfall to iterative development. “What Is thee Rational Unified Process?” The Rational Edge e-zine. 36. 1990. The University Press: Cambridge. June 1993. and Jones. Nigel. Carmel. Bruce. Shambhala Publications. 1996. Jones. Parshall. Designing Social Systems in a Changing World. Erran. Volume 1. “The Forgotten Phase. Atila . John Chris. Problem Seeking: An Architectural Programming Primer.. “PD and Joint Application Design: A Transatlantic Comparison. Humberto R. How Designers Think: The Design Process Demystified. PMI Standards Committee A guide to the project management body of knowledge. 1998.

1994 Vredenburg. The Sciences of the Artificial. Peter G. The MIT Press. Rowe. Simon. How to Solve It: A New Aspect of Mathematical Method. Denise and Wood. 4.” IBM Systems Journal. Silver. “Building ease of use into the IBM user experience. Joint Application Development. Karel. 1995. George. Herbert. Princeton University Press. 42. 1988. 1987. Design Thinking. Extreme Programming: A gentle introduction Extremeprogramming.Poyla. No. Wells. 2d ed.org web site. Jane. Vol. John Wiley & Sons. 145 . 2004. 2003. Don. 2d ed. The MIT Press.

Sun’s Noel Franus and Cindy Yepez were infinitely patient with the slow pace of work and politely pushed us to add descriptions to each model. It began as a manilla folder with copies of processes. We completed the first “book” version as part of a project undertaken for Elaine Coleman and Sun’s Virtual Center for Innovation. We present this version for educational purposes only. Greg Baker.Dubberly Design Office developed this book over many months. Copyright © 2004 Dubberly Design Office 146 . Copyrights remain with their owners. and Hugh Dubberly drew the models. Ryan Reposar. Audrey Crane. We have obtained no permissions to reproduce any of the models. It was Greg who patiently redrew Archer’s huge model bringing the diagram and Archer’s descriptive text together for the first time. Ryan assembled the book and handled the many changes.

147 .