(OW DO YOU DESIGN
! #OMPENDIUM OF -ODELS
BY (UGH $UBBERLY
$UBBERLY $ESIGN /FFICE (ARRISON 3TREET 3AN &RANCISCO #!
Everyone designs. The teacher arranging desks for a discussion. The entrepreneur planning a business. The team building a rocket.
3 Their results differ. So do their goals. So do the scales of their projects and the media they use. Even their actions appear quite different. What’s similar is that they are designing. What’s similar are the processes they follow.
4 Our processes determine the quality of our products. If we wish to improve our products, 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 know what we do and how we do it. To understand it and improve it.
To become better designers.
5 Introduction
In this book, I have collected over one-hundred descriptions Asking these questions has practical goals: of design and development processes, from architecture, - reducing risk (increasing the probability of success) industrial design, mechanical engineering, quality - setting expectations (reducing uncertainty and fear) management, and software development. They range from - increasing repeatability (enabling improvement) short mnemonic devices, such as the 4Ds (defi ne, design, develop, deploy), to elaborate schemes, such as Archer’s Examing process may not benefi t everyone. For an individual 9-phase, 229-step “systematic method for designers.” designer—imagine someone working alone on a poster— Some are synonyms for the same process; others represent focusing on process may hinder more than it helps. But differing approaches to design. teaching new designers or working with teams on large projects requires us to refl ect on our process. Success By presenting these examples, I hope to foster debate about depends on: design and development processes. - defi ning roles and processes in advance - documenting what we actually did How do we design? - identifying and fi xing broken processes Why do we do it that way? Ad hoc development processes are not effi cient and not How do we describe what we do? repeatable. They constantly must be reinvented making Why do we talk about it that way? improvement nearly impossible. At a small scale, the costs may not matter, but large organizations cannot sustain them. How do we do better? From this discussion, 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 suffi ce?
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 Origins
The oldest development process model I’ve seen dates In the software world, interest in the development process from about 1920 and describes how to develop a dates back at least to the IBM System 360, released in 1964. battleship for the Royal Navy. Discussions about design In 1975, Fred Brooks, manager of OS/360, published The and development processes began in earnest shortly after Mythical Man Month, his “belated answer to [IBM Chairman] the second world war. They grew out of military research Tom Watson’s probing question as to why programming is so and development efforts in at least three fi elds, operations hard to manage.” research, cybernetics, and large-scale engineering project management. Today, software developers are still actively discussing the question. Consultants seek to differentiate themselves Pre-war efforts to make radar an effective part of the British with proprietary processes. Software tools makers seek air-defense system led to operations research, which standards around which they can build tools—a new twist on then matured into an academic discipline. Development codifying the design process. of automatic piloting devices and fi re-control systems for aiming large guns led to servo-mechanisms and computing Curious ties exists between the design methods world and devices, anticipating the emergence of cybernetics, one of the software development world. One of the founders of the roots of artifi cial intelligence. Large engineering projects the design methods movement, Christopher Alexander, undertaken during the war and later cold-war projects, such co-wrote A Pattern Language. Alexander’s work on design as the Atlas and Titan missile projects, demanded new patterns in architecture contributed to thinking on design techniques to deal with increased scale and complexity. patterns in software. In the 1970s, another important fi gure in the movement, Horst Rittel, developed IBIS (Issues-Based The excitement of these new disciplines and the success of Information System) to support the design process. Rittel’s these huge engineering projects captivated many people. research into IBIS is a precursor of today’s work on design From operations research, cybernetics, and large-scale rationale. engineering project management, academic designers imported both methods and philosophy in what became But for the most part, designers, business managers, and known as the design methods movement (1962-1972). Work software developers appear to be unaware of practices and in the UK, at Ulm in Germany, and MIT and Berkeley in the thinking about process in the other disciplines. Even within US sought to rationalize and systemize the design process. their own fi elds, many are unaware of much prior art. Several designers attempted to codify the design process and present it as a scientifi c method. The fi elds overlap, but so far as I know, no one has attempted to bring together work from these three areas. Somewhat parallel efforts occurred in the business world. One of my goals is to cast each of these activities as design, Stafford Beer and others applied systems thinking and to show how their processes are similar, and to encourage especially operations research to business problems. sharing of ideas between the disciplines. During the 1950s, W. Edward Deming examined business processes. His work led to the quality management movement, which became popular in Japan and something of a fad in the US in the 1980s. Its principles became standard operating procedures in much of the business world, becoming enshrined in ISO and six-sigma standards.
7 Measure twice Ready Cut once Aim Fire
Lab study Research Pilot plant Development Full-scale plant Manufacturing Sales
8 Contents
The carpenter’s adage, 11 Introducing process the captain’s command, the chemical engineer’s “scale-up” process, 19 Analysis versus synthesis the corporation’s departments— the four phrases on the previous page— 29 Academic models have something in common. 61 Consultant models Each is a sequence of steps. 67 Software development Each is a process focused on achieving a goal. 82 Complex linear models Each suggests iteration and convergence. 115 Cyclic models Each is an analog of the design process. 132 Complete list of models This book presents many other descriptions of design and development processes. I call these descriptions design 136 Chronological list process models, distinguishing the description from the activity it describes. I also combine design and development 140 Author list into one category, because the distinction is without a difference.
This collection is not exhaustive. Even so, organizing it presents a challenge. At the end of the book are indices organized by title, date, and author. In the body of the book are threads but no strong narrative. I have paired models where I see a connection. These pairings—and the entire structure—are idiosyncratic. Thus, the book is more a reference work than a primer.
9 Design process after Tim Brennan (~1990)
At an off-site for Apple Computer’s Creative Services de- Brennan captures important aspects of the process: partment, Tim Brennan began a presentation of his group’s - the potential for play work by showing this model. “Here’s how we work,” he said. - its similarity to a “random walk” “Somebody calls up with a project; we do some stuff; and - the importance of iteration the money follows.” - its irreducible “black-box” nature
10 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.
11 Process archetype
A process must have input and output. Garbage in; garbage of using Photoshop’s curves function to lighten a photo. out. (Good in; good out?) In between, something may hap- One risk in using this framework is that it neatens a messy pen—the process—a transformation. Sometimes, the trans- world. It may promote an illusion of linearity and mecha- formation is reducible to a mathematical function. Think nism—of cause and effect.
)NPUT 0ROCESS /UTPUT
12 On the infi nite expandability of process models
An important step in managing any process is document- Processes have a fractal quality. You can zoom in or out, ing it. That truism implies a process merely needs recording. increasing or decreasing abstraction or specifi city. You can But documenting a process is like taking a photograph. The add more detail—dividing phases into steps and steps into author chooses where to point the camera—where to begin sub-steps, almost infi nitely. Processes rarely have fi xed mapping the process, where to end, what to put in, what to beginnings or endings. You can almost always add steps leave out, how much detail to include. upstream or downstream.
0ROCESS
0ROCESS
)NPUT 0ROCESS /UTPUT
13 Design process archetype: Analysis, Synthesis after Koberg and Bagnall (1972)
“When comparing many different problem-solving approach- of design, two basic stages are necessary. First, we break es it becomes necessary to search for their basic abstrac- the situation or whole problem into parts for examination tions or common-denominators,” write Koberg and Bagnall. (Analysis) and Second, we reassemble the situation based “If you’ll try it yourself, we’re sure that the two “basic” stages on our understanding of improvements discovered in our of analysis and synthesis will emerge; i.e., when consciously study (Synthesis).” solving problems or when creatively involved in the activity
0ROCESS
)NPUT !NALYSIS 3YNTHESIS /UTPUT
14 Problem, Solution after JJ Foreman (1967)
Foreman, like Koberg and Bagnall, casts design as problem- solving. This stance is typical of the fi rst generation of the design methods movement. Foreman introduces the idea of needs. He also begins to sub-divide the process.
0ROBLEM %STABLISHING .EEDS 3ATISFYING .EEDS 3OLUTION
&ACTORS 2ELATIONSHIPS 0RINCIPLES &ORMS
15 Expanding the two-step process after Don Koberg and Jim Bagnall (1972)
In their classic book, The Universal Traveler, Koberg and Ba- ing or Synthesis stage.” Within the book’s “problem-solving” gnall (who taught in the College of Environmental Design at frame, defi nition becomes problem defi nition, and they never Cal Poly in San Luis Obisbo) expand the archtypal two-step follow up on the idea of defi nition as concept or parti. process to three, then fi ve, and fi nally to seven steps. The synthesis phase becomes “ideate, select, implement,” They note “that ‘out of Analysis’ we derive an understanding while the analysis phase remains intact. Finally, they add a or concept that is then followed as a guideline in the rebuild- new phase at the beginning and another at the end.
ANALYSIS SYNTHESIS
ANALYSIS DEFINITION SYNTHESIS
ANALYZE DEFINE IDEATE SELECT IMPLEMENT
ACCEPT ANALYZE DEFINE IDEATE SELECT IMPLEMENT EVALUATE
16 Matching process to project complexity after Jay Doblin (1987)
In his article, “A Short, Grandiose Theory of Design,” Doblin presents a similar series of expanding processes. Dobin’s notion of direct and indirect design echos Alexan- der’s (1962) model of unselfconscious and self-conscious design. Doblin’s third and fourth processes correspond to Alexander’s third type of design, mediated design (my title). (For more on Alexander’s model, see the next page.)
$IRECT $ESIGN
3TATE 0ROCESS 3TATE
)NDIRECT $ESIGN
3TATE !NALYSIS 'ENESIS 3YNTHESIS 3TATE
!NALYSIS 'ENESIS 3YNTHESIS
3TATE ,IST -ATRIX 3EMILATTICE 3CHEMATIC -ECHANICAL -ODEL 3TATE $RAWING
!NALYSIS 'ENESIS 3YNTHESIS
3TATE )NFORMATION )NFORMATION 0LAN %VALUATE $ESIGN %VALUATE )MPLEMENT 3TATE 'ATHERING 3TRUCTURING 0LAN $ESIGN
0ROCESSES 3UPERSETS )SSUES 3PECIALISTS $EPARTMENTS )NTERVIEWS #OMPETITION 0OSITION %NGINEERING %NGINEERING 0RIMARY #HANNELS #ONTENT 3TYLING 3TYLING 3ECONDARY 4ECHNOLOGY .OMENCLATURE %RGONOMICS #ATALOG $ATA 3EARCHES #ONSUMERS $ESIGN !DVERTISING 0ACKAGING &IELD 2ESEARCH )MPLEMENTATION "ROCHURES !DVERTISING #ATALOGS 0UBLIC 2ELATIONS $IRECT -AIL 4RADE 3HOWS 'RAPHIC &ORMATS 5SER -ANUALS )DENTITY %LEMENTS $IRECT -AIL #ONTROL5SER -ANUALS #ORPORATE )TEMS ,ANGUAGE %TC .OMENCLATURE 0ACKAGING 0OINT /F 0URCHASE 4RADESHOWS %TC
17 Unself-conscious and self-conscious design after Christopher Alexander (1962)
In Notes on the Synthesis of Form, Alexander (1962) the designer has learned and invented, on the one hand, described three situations in which designing may take and ideas and diagrams and drawings which stand for place. In the fi rst, a craftsman works directly and unself- forms, on the other.” In the third, the designer also works consciously through “a complex two-directional interaction self-consciously, this time abstracting and formalizing between the context C1 and the form F1, in the world itself.” representations of the problem and solution so that he and In the second, designing is separate from making. Form is others may inspect and modify them. shaped “by a conceptual picture of the context which
5N SELF CONSCIOUS
#ONTEXT &ORM
# & !CTUAL WORLD
3ELF CONSCIOUS
#ONTEXT &ORM
# & !CTUAL WORLD
# & -ENTAL PICTURE
-EDIATED
#ONTEXT &ORM
# & !CTUAL WORLD
# & -ENTAL PICTURE
# & &ORMAL PICTURE OF MENTAL PICTURE
18 Analysis synthesis evaluation
In 1962, Jones proposed this procedure as a basic framework for design processes. But what relationship do the steps have? Are they discrete? Sequential? Overlapping? This section compares several models. 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 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 Programming and designing after William M. Pena and Steven A. Parshall (1969)
This model comes from architecture, where programming They note, “Programming IS analysis. Design IS synthesis.” refers not to computers but to a phase of planning that precedes design of a building. Pena and Parshall quote Web- Pena and Parshall recommend “a distinct separation of pro- ster, “[Programming is] a process leading to the statement of gramming and design.” “The separation of the two is impera- an architectural problem and the requirements to be met in tive and prevents trial-and-error design alternatives.” offering a solution.” They describe programming as “problem seeking” and design as “problem solving.”
3CHEMATIC 0ROGRAM 0ROGRAM $EVELOPMENT
3CHEMATIC $ESIGN $ESIGN $EVELOPMENT
0ROGRAMMING CONCERNS FIVE STEPS
%STABLISH 'OALS 7HAT DOES THE CLIENT WANT TO ACHIEVE AND 7HY #OLLECT AND ANALYZE &ACTS 7HAT DO WE KNOW 7HAT IS GIVEN 5NCOVER AND TEST #ONCEPTS (OW DOES THE CLIENT WANT TO ACHIEVE THE GOALS $ETERMINE .EEDS (OW MUCH MONEY AND SPACE 7HAT LEVEL OF QUALITY 3TATE THE 0ROBLEM 7HAT ARE THE SIGNIFICANT CONDITIONS AFFECTING THE DESIGN OF THE BUILDING 7HAT ARE THE GENERAL DIRECTIONS THE DESIGN SHOULD TAKE
21 Diverge / Converge vs Narrow / Expand
Often designers describe themselves as creating many We may just as easily describe the process by reversing options (diverging) and then narrowing down their options the sequence (narrowing down, expanding out). Analyzing (converging). Alexander (1962) and other designers have a problem leads to agreement—to defi nition—a convergent described analysis as a process of breaking a problem into process. At that point, hopefully, the “miracle” of transfor- pieces—of “decomposing” it. Synthesis follows as re-or- mation occurs in which the solution concept arises. Then, dering the pieces based on dependencies, solving each the designer elaborates that concept in greater and greater sub-piece, and fi nally knitting all the pieces back together— detail—a divergent process. “recombining” the pieces. This decomposition-recombination process also diverges and then converges. Later, we see this question arise again in the section on spiral models. Some (Souza) converge on a solution. Others (Boehm) diverge from a center, suggesting the accumulation of detail. (See pages 122-125.)
!NALYSIS 3YNTHESIS
)NPUT /UTPUT
"REAKING 2EASSEMBLING INTO PARTS IN A NEW WAY
#ONVERGE 4RANSFORM $IVERGE
22 Decomposition / recombination after VDI 2221 (from Cross 1990)
VDI 2221 mirrors Alexander’s decomposition-recombination “This kind of procedure has been criticized in the design process. Cross wrote, “The VDI Guideline follows a general world because it seems to be based on a problem-focused, systemic procedure of fi rst analyzing and understanding the rather than a solution-focused approach. It therefore runs problem as fully as possible, then breaking this into sub- counter to the designer’s traditional ways of thinking.” (For problems, fi nding suitable sub-solutions and combining another view of VDI 2221, see page 32.) these into an overall solution.”
/VERALL PROBLEM
3UB PROBLEMS
)NDIVIDUAL PROBLEMS )NDIVIDUAL SOLUTIONS
3UB SOLUTIONS
/VERALL SOLUTION
23 Dynamics of divergence and convergence after Bela H. Banathy (1996)
Banathy’s model illustrates the iterative nature of the design as we make choices and create an image of the future process, repeating the process of divergence and conver- system. The same type of divergence-convergence operates gence, analysis and sysnthesis. in the design solution space. For each of the substantive design domains (core defi nition, specifi cations, functions, In Banathy’s view, “We fi rst diverge as we consider a number enabling systems, systemic environment) we fi rst diverge of inquiry boundaries, a number of major design options, and as we create a number of alternatives for each, and then sets of core values and core ideas. Then we converge, converge as we evaluate the alternatives and select the most promising and most desirable alternative.”
4RANSCEND%NVISION 4RANSFORM "Y $ESIGN
!LTERNATIVE )MAGES !LTERNATIVE 3OLUTIONS
'ENESIS 4HE )MAGE 4HE -ODEL OF THE OF THE &UTURE &URTURE 3YSTEM 3YSTEM
$IVERGENCE #ONVERGENCE $IVERGENCE #ONVERGENCE
24 Overall, the design process must converge after Nigel Cross (2000)
Cross notes, “Normally, the overall aim of a design strategy The overall process is therefore convergent, but it will contain will be to converge on a fi nal, evaluated and detailed design periods of deliberate divergence.” proposal, but within the process of reaching that fi nal design there will be times when it will be appropriate and necessary Banathy’s and Cross’s models suggest cycles and are similar to diverge, to widen the search or to seek new ideas and to the iterative process of Marcus and Maver (see page 45) starting points. and to the spirals of Boehm and others (see pages 122-125).
4RACK OF DESIGNERS ATTENTION
3OLUTION
$IVERGENCE #ONVERGENCE $IVERGENCE #ONVERGENCE
25 Gradual shift of focus from analysis to synthesis after Bill Newkirk (1981)
Bill Newkirk fi rst taught me that synthesis begins at the architects: fi rst analysis then synthesis. For the designers it very beginning of a design project. Koberg and Bagnall seems, analysis, or understanding the problem is much more (1972) suggested that both analysis and synthesis continue integrated with synthesis, or generating a solution.” He re- throughout a project. Designers may begin by focusing on ports studies by Eastman (1970) and Akin (1986) confi rming analysis and gradually shift their focus to synthesis. this view. “Akin actually found that his designers were con- stantly both generating new goals and redefi ning constraints. Lawson (1990) notes, “Most of the maps of the design Thus, for Akin, analysis is a part of all phases of design and process which we have looked at seem to resemble more synthesis is found very early in the process.” closely the non-designer, scientist approach than that of the
!NALYSIS )NPUT /UTPUT
3YNTHESIS
26 Problem to solution: sequence, parallel process or loop?
Pena and Parshall (1969), Briggs and Havlick (1976), and defi ned or at least outlined the solution. Rittel and Webber others, particularly in the early phases of the design methods (1973) note, “The information needed to understand the movement, described problem solving as a sequential activ- problem depends upon one’s idea for solving it.” (Italics are ity. In this model, we must defi ne a problem before we can theirs.) “Problem understanding and problem resolution are solve it. concomitant to each other.” Attempting to solve a problem (prototyping) may even improve our understanding of a prob- On the other hand, most people agree that a solution is lem—and thus change our defi nition. inherent in a problem. Having defi ned a problem, we’ve
0ROBLEM 3OLUTION
VS
0ROBLEM 3OLUTION
VS
0ROBLEM
3OLUTION
27 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 prescrip- tive” rather than descriptions of actual behavior.
,IFT FOOT -OVE LEG ,OWER FOOT
,EFT FOOT
,IFT FOOT -OVE LEG ,OWER FOOT
2IGHT FOOT
28 Academic models
Many teachers in the design fi elds, engineering, and architecture have developed models of the design process to help their students learn to design.
29 Four stage design process after Nigel Cross (2000)
Writing from an engineering perspective, Cross developed generation of a concept by the designer, usually after some this “simple descriptive model of the design process, based initial exploration of the ill-defi ned problem space.” on the essential activities that the designer performs. The end-point of the process is the communication of a design, Cross’s model includes communication as a fi nal stage. ready for manufacture. Prior to this, the design proposal is Archer (1963) may have been the fi rst to include communi- subject to evaluation against the goals, constraints and crite- cation as an explicit stage in a design process model. (See ria of the design brief. The proposal itself arises from the page 98.)
%XPLORATION
'ENERATION
%VALUATION
#OMMUNICATION
30 Engineering design process after Michael J. French (1985)
.EED
!NALYSIS OF 0ROBLEM French also wrote from an engineering perspective. He sug- gested, “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 3TATEMENT - limitations placed up the solution, OF 0ROBLEM e.g. codes of practice, statutory requirements, customers’ standards, date of completions - the criterion of excellence to be worked to.”
#ONCEPTUAL $ESIGN The conceptual design phase “takes the statement of the problem and generates broad solutions to it in the form of &EEDBACK schemes. It is the phase that makes the greatest demands on the designer, and where there is the most scope for strik- ing improvements. It is the phase where engineering science, practical knowledge, production methods and commercial 3ELECTED 3CHEMES 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 fi nal choice between them %MBODIMENT OF 3CHEMES is made. The end product is usually a set of general ar- rangement drawings. There is (or should be) a great deal of feedback from this phase to the conceptual design phase.
$ETAILING In the detailing phase, “a very large number of small but es- sential 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 The full process contains much more detail than the diagram engineering society of Germany. Their guideline 2221 sug- below shows. In practice, the process is less linear than the gests, “The design process, as part of product creation, is diagram implies. “It is important to note that the stages do subdivided into general working stages, making the design not necessarily follow rigidly one after the other. They are approach transparent, rational and independent of a specifi c often carried out iteratively, returning to preceding ones, thus branch of industry.” achieving a step-by-step optimization.”
3TAGES 2ESULTS
4ASK
#LARIFY DEFINE THE TASK
3PECIFICATION
$ETERMINE FUNCTIONS THEIR STRUCTURES
&UNCTION STRUCTURE
3EARCH FOR SOLUTION PRINCIPLES THEIR COMBINATIONS
0RINCIPLE SOLUTION
$IVIDE INTO REALIZABLE MODULES
-ODULE STRUCTURE
$EVELOP LAYOUTS OF KEY MODULES
0RELIMINARY LAYOUTS
#OMPLETE OVERALL LAYOUT
$EFINITIVE LAYOUT
0REPARING PRODUCTION OPERATING INSTRUCTIONS
0RODUCT DOCUMENTS
4ASK
32 Design process after Gerhard Pahl and Wolfgang Beitz (1984)
Cross recommends this model as “reasonably comprehen- tasks and activities that are necessary in all practical design sive” but not obscuring “the general structure of the design work.” He seems to refer to Archer’s “Systematic method for process by swamping it in the fi ne detail of the numerous designers”. (See page 98.)
4ASK
#LARIFY THE TASK %LABORATE THE SPECIFICATION OF THE TASK #LARIFICATION 3PECIFICATION
)DENTIFY ESSENTIAL PROBLEMS %STABLISH FUNCTION STRUCTURES 3EARCH FOR SOLUTION PRINCIPLES #OMBINE AND FIRM UP INTO CONCEPTUAL VARIANTS %VALUATE AGAINST TECHNICAL AND ECONOMICAL CRITERIA
#ONCEPT /PTIMIZATION OF THE PRINCIPLE
$EVELOP PRELIMINARY LAYOUTS AND FORM DESIGNS 3ELECT BEST PRELIMINARY LAYOUTS 2EFINE AND EVALUATE AGAINST TECHNICAL AND ECONOMIC CRITERIA 5PGRADE AND IMPROVE 0RELIMINARY LAYOUT )NFORMATION ADAPT THE SPECIFICATION
/PTIMIZE AND COMPLETE FORM DESIGNS #HECK FOR ERRORS AND COST EFFECTIVENESS 0REPARE THE PRELIMINARY PARTS LIST AND PRODUCTION DOCUMENTS /PTIMIZATION OF THE LAYOUT AND FORMS
$EFINITIVE LAYOUT
&INALIZE DETAILS #OMPLETE DETAIL DRAWINGS AND PRODUCTION DOCUMENTS #HECK ALL DOCUMENTS $ETAIL DESIGN %MBODIMENT DESIGN #ONCEPTUAL DESIGN
$OCUMENTATION
3OLUTION 33 Architect’s plan of work (schematic) after the RIBA Handbook (1965)
Lawson presents this model from the RIBA (Royal Institute of Communication involves describing “one or more potential British Architects) practice and management handbook. Ac- solutions to people inside or outside the design team.” cording to the handbook, assimilation is “The accumulation and ordering of general information specifi cally related to the Lawson is critical, “it is hardly a map at all. . . . In short, all problem in hand.” General study is “The investigation of the this map does is to tell us that designers have to gather nature of the problem. The investigation of possible solutions information about a problem, study it, devise a solution and or means of solution.” Development is “refi nement of one draw it, though not necessarily in that order.” or more of the tentative solutions isolated during phase 2.”
!SSIMILATION 'ENERAL STUDY $EVELOPMENT #OMMUNICATION
34 Architect’s plan of work, (detailed) after the RIBA Handbook (1965)
The handbook also contains another, more detailed plan of how it is done. In the detailed description of each section work occupying 27 pages. The 12 main stages are described the Plan of Work also describes what each member of the below. Lawson criticizes this model as “a description not of design team (quantity surveyor, engineers etc) will do, and the process but of the products of that process. . . . It’s also how he will relate to the architect; with the architect clearly worth noting that the stages in the Plan of Work are closely portrayed as the manager and leader of this team. This related to the stages of fee payment in the Conditions of further reveals the Plan of Work to be part of the architectural Engagement for Architects. So the Plan of Work may also profession’s propaganda exercise to stake a claim as leader seen as part of a business transaction; it tells the client what of the multi-disciplinary building design team.” he will get, and the architect what he must do rather than
"RIEFING )NCEPTION &EASIBILITY
3KETCH PLANS /UTLINE PROPOSALS 3CHEME DESIGN
7ORKING DRAWINGS $ETAIL DESIGN 0RODUCTION INFORMATION "ILLS OF QUANTITIES 4ENDER ACTION
3ITE OPERATIONS 0ROJECT PLANNING /PERATIONS ON SITE #OMPLETION &EED BACK
35 Problem solving process after George Polya (1945)
In 1945, George Polya wrote How to Solve It, an excellent tions Polya in his booklet, Systemic method for designers. little book for students and teachers of mathematics. In it, he Likewise, Maldonado and Bonsiepe (1964) also mention describes a process for solving math problems, though one Polya in their article “Science and Design.” might apply his process more generally. Thus Polya seems to have infl uenced the teaching of archi- Many in the design methods movement seem to have been tecture, as may be seen in the “scientifi c problem solving familiar with Polya’s book. Bruce Archer (1963-1964) men- process” described on the following page.
5NDERSTANDING THE PROBLEM 7HAT IS THE UNKNOWN 7HAT ARE THE DATA 7HAT IS THE CONDITION $RAW A FIGURE )NTRODUCE SUITABLE NOTATION 3EPARATE THE VARIOUS PARTS OF THE CONDITION #AN YOU WRITE THEM DOWN
$EVISING A PLAN &IND THE CONNECTION BETWEEN THE DATA AND THE UNKNOWN $O YOU KNOW A RELATED PROBLEM ,OOK AT THE UNKNOWN (ERE IS A PROBLEM RELATED TO YOURS AND SOLVED BEFORE #OULD YOU USE IT #OULD YOU RESTATE THE PROBLEM #OULD YOU RESTATE IT STILL DIFFERENTLY 'O BACK TO DEFINITIONS 9OU SHOULD OBTAIN EVENTUALLY A PLAN OF THE SOLUTION
#ARRYING OUT THE PLAN #HECK EACH STEP #AN YOU SEE CLEARLY THAT THE STEP IS CORRECT #AN YOU PROVE THAT IT IS CORRECT
,OOKING BACK #HECK THE RESULT #AN YOU DERIVE THE RESULT DIFFERENTLY #AN YOU USE THE RESULT OR THE METHOD FOR SOME OTHER PROBLEM
36 Scientifi c problem solving process after Cal Briggs and Spencer W. Havlick (1976)
Briggs and Havlick used this model for teaching design to They write, “the role of the environmental designer is to solve undergraduates at the University of Colorado’s College of human environmental problems by the creation and imple- Environmental Design. The college’s name implies links to mentation of optimal physical form. . . . The scientifi c method environmental design faculties at Berkeley, San Luis Obispo, is the central process. [We have] borrowed the scientifi c and Ulm and thus to the design methods movement. Briggs method from the traditional sciences and adapted it for the and Havlick shared the early movement’s desire to cast development of optimal solutions. Termed the scientifi c design as a science. problem solving design process, it has been utilized to insure an analytic, systematic, and precise approach to the solution of man’s environmental malfunctions.”
5NFULFILLED NEED AND UNSATISFIED NEED
4HE DELINEATION OF A MALFUNCTION IN THE HUMAN ENVIRONMENT WHICH 0ROBLEM STATEMENT WAS CREATED BY THE INABILITY TO PERFORM A NEEDED HUMAN ACTIVITY
4HE INVESTIGATION INTO BACKGROUND RESEARCH WHICH ANSWERS "ACKGROUND STATEMENT THE WHO WHAT WHERE HOW WHEN AND WHY A "ACKGROUND RESEARCH OF THE PROBLEM 4HIS STAGE ALSO EXPLORES A PREVIOUSLY ATTEMPTED PHYSICAL FORM SOLUTIONS AND B ALL CONTRIBUTING CAUSES TO THE PROBLEM
! STATEMENT WHICH DEMONSTRATES THE SIGNIFICANCE OF THE )MPORTANCE STATEMENT ENVIRONMENTAL MALFUNCTION IN TERMS OF CRITICAL HUMAN NEEDS AND WHAT CONSEQUENCES MIGHT RESULT IF THE PROBLEM WAS NOT SOLVED
! STATEMENT OF THE INTENDED GOALS THAT WILL BE FULFILLED BY THE /BJECTIVE SOLUTION OF THE PROBLEM
! RESEARCHED ASSUMPTION WHICH ASSERTS THAT IF A CERTAIN PHYSICAL A !LTERNATIVE HYPOTHESIS FORM APPROACH IS TAKEN CERTAIN RESULTS WILL ENSUE THE SATISFACTION OF UNMET NEED
B 3ELECTED HYPOTHESIS
4HE DEFINITION AND ORDERING OF ALL DESIGN CONSIDERATIONS 0ARAMETER DEVELOPMENT NECESSARY FOR THE DEVELOPMENT OF AN OPTIMAL SOLUTION TO A STATED PROBLEM IE LEGALITY ECONOMIC FEASIBILITY ECOLOGICAL IMPLICATIONS A ?????????????????????? SHAPE COLOR WEIGHT ETC 0ARAMETERS OR VARIABLES ARE THE FORM B ?????????????????????? DETERMINING COMPONENTS WHICH COMPRISE THE PROPOSED C ?????????????????????? HYPOTHESIS D ??????????????????????
4HE SYSTEMATIC OPTIMIZING AND COMPROMISING OF ORDERED DESIGN 0ARAMETER SYNTHESIS PARAMETERS INTO A RESULTANT PHYSICAL FORM SOLUTION WHICH OPTIMALLY ACHIEVES THE STATED OBJECTIVES )T SHOULD BE STATED HERE THE hPHYS ICAL FORMv COULD BE THE WRITING OF ENVIRONMENTAL LEGISLATION REDESIGN OR CREATION OF A PRODUCT OR THE FORMULATION OF HOW A SERVICE COULD BE BEST PROVIDED
3OLUTION EVALUATION 4HE IMPLEMENTATION AND TESTING OF THE GENERATED DESIGN SOLUTION TO DELINEATE THE NEED FOR ANY FURTHER MODIFICATIONS OR RECYCLING BACK THROUGH THE SCIENTIFIC PROBLEM SOLVING PROCESS 4HIS EVALUATION PROCESS PRECEDES IMPLEMENTATION OF A SOLUTION
4HE ARROWS IN THE FLOWCHART REVEAL AN IMPORTANT DIMENSION OF THE &ULFILLED ACTIVITY AND SATISFIED NEED PROBLEM SOLVING DESIGN PROCESS !T EVERY PROCEDURAL STAGE THE %NVIRONMENTAL $ESIGNER IS ABLE TO RECYCLE BACK THROUGH THE PROCESS ONE OR MORE STAGES IF MODIFICATIONS ARE NECESSARY TO IMPROVE THE EVOLUTION OF THE FINAL DESIGN
37 THEOC, a model of the scientifi c method
THEOC is an acronym for theory, hypothesis, experiment, - within a framework of a Theory observation, conclusion — an easy way to remember an - generate a Hypothesis about a phenomenon outline of the scientifi c method. It approximates the process - run an Experiment to test the hypothesis with these steps: - Observe and record the results - form a conclusion based on the relation of the observations to the hypothesis. - repeat as necessary
4HEORY
(YPOTHESIS
%XPERIMENT
/BSERVATION
#ONCLUSION
38 Criteria of Validation of Scientifi c Explanations (CVSE) after Humberto Maturana (1987)
Claudia L’Amoreaux contributed the models below compar- “What do we explain? ing Maturana’s view of scientifi c explanation with his view of We explain our experiences. . . .” the scientifi c method. L’Amoreaux points out that “Maturana shows you not only don’t need objectivity to do science, you “What do we explain? can’t be objective. While the traditional pose of scientifi c We explain our experiences objectivity may be fi ne in some areas, we cannot understand with the coherences of our experiences. perception and the nervous system within that framework.” We explain our living with the coherences of our living. Nor can we understand design that way. Explanations are not so in themselves; Maturana writes, “scientifi c explanations are not valid in explanations are interpersonal relations.” themselves, they are generative mechanisms accepted as valid as long as the criterion of validation in which they are embedded is fulfi lled.”
#63% 3CIENTIFIC METHOD
4HE DESCRIPTION 4HE DESCRIPTION OF WHAT AN OBSERVER SHOULD DO OF THE PHENOMENON TO LIVE THE EXPERIENCE TO BE EXPLAINED TO BE EXPLAINED
4HE PROPOSITION 4HE PROPOSITION OF A GENERATIVE MECHANISM OF THE HYPOTHESIS OR MODEL OF THE REALITY THAT UNDERLIES THE PHENOMENON BEING EXPLAINED
4HE DEDUCTION 4HE PREDICTION OF OTHER PHENOMENA FROM ALL THE EXPERIENTIAL COHERENCES ASSUMING THAT IS VALID OF THE OBSERVER IMPLIED IN TOGETHER WITH THE PROPOSITION OF OTHER POSSIBLE EXPERIENCES OF WHAT TO DO THAT HE OR SHE MAY LIVE TO SHOW THEM AND OF WHAT HE OR SHE SHOULD DO TO HAVE THEM
$OING WHAT HAS BEEN DEDUCTED IN $OING WHAT HAS BEEN DEDUCED IN AND IF THE OBSERVER LIVES THE EXPERIENCES THERE DEDUCED AND IF THE PREDICTED NEW PHENOMENA OCCUR THEN IS ACCEPTED AS SCIENTIFIC EXPLANATION THE HYPOTHESIS OR MODEL PRESENTED IN IS CONFIRMED
39 Comprehensive anticipatory design science after Buckminster Fuller (1950?)
According to the Buckminster Fuller Institute, Fuller began The assertion that design is a science was most power- formulating his theory of a comprehensive anticipatory de- fully articulated by Carnegie vv Herbert Simon (1969) in The sign science as early as 1927. In 1950, he outlined a course, Sciences of the Artifi cial. Simon’s view is no longer fashion- which he taught at MIT in 1956 as part of the Creative Engi- able. Most academic designers remain within Schools of Art. neering Laboratory. Students included engineers, industrial Some, such as Banathy (1996), suggest design is a third way designers, materials scientists, and chemists, representing of knowing distinct from the humanities and the sciences. research and development corporations from across the country.
)NVENTORY $EVELOP ARTIFACTS ALTERNATIVES
#OMMUNICATE PLAN #HOOSE $EFINE $EFINE $ESCRIBE $ESIGN $EVELOP $OCUMENT PROBLEM PROBLEMS PREFERED PRESENT PREFERED IMPLEMENTATION PROCESS SITUATION STATE STATE SYSTEM STRATEGIES )NITIATE LARGER PLANNING PROCESS
$EVELOP EVALUATION CRITERIA
40 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. Below, he pro- vides a practical model for students. Note the repetition of research, scenario building, and visualization in the three middle phases.
0HASES /BJECTIVES #HARACTERISTIC ACTIVITIES
6ISION $ISCOVER GOVERNING IDEAS AND CIRCUMSTANCES STRATEGY IDENTIFY ORGANIZATIONAL VISION STRATEGY $IALOGUE PREPARE DESIGN BRIEF 3TRATEGIC PLANNING 3TRATEGIC DESIGN PLANNING WITH VISION /F THE PRODUCT DEVELOPMENT PROCESS
"RIEF )NDENTIFICATION AND SELECTION IDENTIFY AND SELECT THE INITIAL ISSUES FUNCTION AND FEATURES TO BE ADDRESSED $ISCUSSION 2ESEARCH /BSERVATION ETC 3CENARIO BUILDING 6ISUALIZATION 3CRIBING 0ROJECT PLANNING #ONCEPT MAPPING $OCUMENTATION
#ONCEPTION )NVENTION AND JUDGMENT INVENT POSSIBLE CONCEPTS OF THE PRODUCT 2ESEARCH /BSERVATION JUDGE WHICH CONCEPTS ARE VIABLE "RAINSTORMING #ONCEPT MAPPING 3CENARIO BUILDING %ARLY FREQUENT VISUALIZATION 3KETCHING $OCUMENTATION -ODELLING
2EALIZATION $ISPOSITION AND EVALUATION PLAN AND MAKE PROTOTYPE OF THE PRODUCT 2ESEARCH EVALUATE BY USER TESTING 3CENARIO BUILDING REFINEMENT 6ISUALIZATION #ONSTRUCTION 0ROTOTYPE $OCUMENTATION %VALUATE 0ROTOTYPE %VALUATE 0ROTOTYPE %VALUATE
$ELIVERY 0RESENTATION PRESENT PROTOTYPE DOCUMENTATION /RAL PRESENTATION AND PRODUCTION SPECIFICATIONS 7RITTEN PRESENTATION 0ROTOTYPE DEMONSTRATION
41 Creative process after Bryan Lawson (1980)
Lawson, an architect, compares the creative process to the design process. “The period of ‘fi rst insight’ (Kneller 1965) &IRST INSIGHT &ORMULATION OF PROBLEM simply involves the recognition that a problem exists and a commitment is made to solving it. This period may itself last for many hours, days or even years. The formulation of the problem may often be a critical phase in design situations. As we have seen, design problems are rarely initially entirely clear and much effort has to be expended in understanding them thoroughly. 0REPARATION #ONSCIOUS ATTEMPT AT SOLUTION The next phase of ‘preparation’ involves much conscious effort to develop an idea for solving the problem. (MacKinnon 1976) As with our maps of the design process it is recog- nized that there may be much coming and going between these fi rst two phases as the problem is reformulated or even completely redefi ned.
)NCUBATION .O CONSCIOUS EFFORT Yet all these writers emphasize here that this period of prepa- ration involves deliberate hard work and is then frequently followed by a period of ‘incubation’ which involves no appar- ent effort, but which is often terminated by the emergence of an idea (‘illumination’).
Some authors (MacKinnon 1976) explain this as unconscious )LLUMINATION 3UDDEN EMERGENCE OF IDEA cerebration during the incubation period. The thinker is unwittingly reorganizing and re-examining all his previous de- liberate thoughts. 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.
Once the idea has emerged all writers agree upon a fi nal 6ERIFICATION #ONSCIOUS DEVELOPMENT period of conscious verifi cation in which the outline idea is tested and developed.”
42 Primary generator after Jane Darke (1978)
Lawson (1990) reports on Darke’s fi nding that at least some Lawson suggests Darke’s model was anticipated by Hiller architects begin the design process with a simple idea or et al (1972). Lawson summarizes Darke’s model, “In plain “primary generator”. “Thus, a very simple idea is used to nar- language, fi rst decide what you think might be an important row down the range of possible solutions, and the designer aspect of the problem, develop a crude design on this basis is then able rapidly to construct and analyze a scheme. Here and examine it to see what else you can discover about the again, we see this very close, perhaps inseparable, relation problem.” Note the similarity to “hacking” in software devel- between analysis and synthesis.” opment.
'ENERATOR #ONJECTURE !NALYSIS
43 Design process after Jane Darke (1978)
Based on Darke’s research, Lawson suggests a looping start designing and briefi ng simultaneously, because these relationship between brief and analysis. One of the architects two activities are completely interrelated.” (For another take Darke interviewed described the process, “. . . a brief comes on this idea, see page 26.) Lawson points out that this may about through essentially an ongoing relationship between be one reason “clients often seem to fi nd it easier to commu- what is possible in architecture and what you want to do, nicate their wishes by reacting to and criticizing a proposed and everything you do modifi es your idea of what is possible design, than by trying to draw up an abstract comprehensive . . . you can’t start with a brief and [then] design, you have to performance specifi cation.”
"RIEFING !NALYSIS 3YNTHESIS %VALUATION
44 Design process after Thomas A. Marcus (1969) and Thomas W Maver (1970)
Typically, in design process models evaluation follows (See pages 24 and 25.) It’s also similar to Boehm’s spiral. analysis and synthesis. Marcus and Maver substitute deci- (See page 122.) The three-level, four-step structure of this sion, casting the design process as a series of decisions. model anticipates the structure of the AIGA model on the They layer these decisions in three levels, outline proposals, next spread. scheme design, and detail design. This iterative structure is similar to that proposed by Banathy (1996) and Cross (2000).
!NALYSIS 3YNTHESIS !PPRAISAL $ECISION
/UTLINE PROPOSAL
!NALYSIS 3YNTHESIS !PPRAISAL $ECISION
3CHEME DESIGN
!NALYSIS 3YNTHESIS !PPRAISAL $ECISION
$ETAIL DESIGN
45 AIGA
46 Process of designing solutions after Clement Mok and Keith Yamashita (2003)
American Institute of Graphic Arts (AIGA) president Clement The book casts design in terms of problem solving, Mok enlisted Keith Yamashita to help the organization help yet it also promises innovation. 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.
$EFINING THE PROBLEM
$EFINING THE %NVISIONING THE $EFINING THE )NCITING SUPPORT PROBLEM DESIRED END STATE APPROACH BY WHICH AND THEN ACTION KNOWING WHAT VICTORY CAN VICTORY LOOKS LIKE BE ACHIEVED
)NNOVATING
3EEKING INSIGHT 0ROTOTYPING $ELINEATING THE %NABLING THE TEAM TO INFORM POTENTIAL TOUGH CHOICES TO WORK THE PROTOTYPING SOLUTIONS AS A TEAM OF THE SOLUTION
'ENERATING VALUE
#HOOSING THE -AKING SURE 3ELLING 2APIDLY LEARNING BEST SOLUTION PEOPLE KNOW ABOUT THE SOLUTION AND hTACKINGv THEN ACTIVATING IT YOUR SOLUTION BASED ON YOUR SUCCESSES AND FAILURES
47 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. Nathan Felde provided an example.
$EFINING THE PROBLEM
$EFINING THE %NVISIONING THE $EFINING THE )NCITING SUPPORT PROBLEM DESIRED END STATE APPROACH BY WHICH AND THEN ACTION KNOWING WHAT VICTORY CAN VICTORY LOOKS LIKE BE ACHIEVED
.EED OIL 'OT OIL #ONTROL )RAQ #REATE hAXIS OF EVILv AND CLIMATE OF FEAR
)NNOVATING
3EEKING INSIGHT 0ROTOTYPING $ELINEATING THE %NABLING THE TEAM TO INFORM POTENTIAL TOUGH CHOICES TO WORK THE PROTOTYPING SOLUTIONS AS A TEAM OF THE SOLUTION
!SK DAD 'RENADA 0ANAMA )NSPECTIONS VERSUS h9OU ARE EITHER WITH US +UWAIT !FGHANISTAN OVERWHELMING FORCE OR AGAINST USv
'ENERATING VALUE
#HOOSING THE -AKING SURE 3ELLING 2APIDLY LEARNING BEST SOLUTION PEOPLE KNOW ABOUT THE SOLUTION AND hTACKINGv THEN ACTIVATING IT YOUR SOLUTION BASED ON YOUR SUCCESSES AND FAILURES 7AR #ALL 2UPERT 7EAPONS OF ,IBERATING THE h"OMBS AWAYv AND (ALLIBURTON MASS DESTRUCTION PEOPLE OF )RAQ
48 What the AIGA didn’t tell you by Nathan Felde
Felde also offered an alternative version of the 12-step process, acknowledging aspects of the AIGA’s function (and that of other professional organizations) which few bring up in public.
$ISCOVERING THE OPPORTUNITY
!CQUIRING 0RACTICING #IRCULATING ,ISTENING FOR A DISTINCTIVE CHARM UNTIL AMONGST THE DEVELOPING PERSONA CHARISMA RIGHT PEOPLE CHANGES IN IS ACHIEVED STATUS QUO
/BTAINING THE CONTRACT
2AISING QUESTIONS %LIMINATING OPTIONS 0RESENTING 0ROMISING MORE THAT ONLY YOU OTHER THAN THE PROPOSAL THAN THE CONTRACT CAN ANSWER YOUR SERVICES WHILE APPEARING REQUIRES UNAVAILABLE
'ETTING PAID
$ISCOVERING &INDING SOMEONE 2ESCUING !NNOUNCING INSURMOUNTABLE ON CLIENT SIDE CLIENT WITH SUCCESS WITH DIFFICULTIES TO BLAME BIGGER PROPOSAL FIRST STAGE
49 Alice Agogino
$EFINE 0ROTOTYPE
%VALUATE
50 Design, build, test after Alice Agogino (1 of 3)
This model is the fi rst in a series of three developed by In the fi rst step, Agogino presents a variation on the Alice Agogino for NASA’s Jet Propulsion Laboratory (JPL) at classic goal-action feedback loop. (See page 117.) California Institute of Technology. Agogino is a professor of Of course, design-build-test is also analogous to defi ne- mechanical engineering at UC Berkeley. prototype-evaluate. (See facing page.)
$ESIGN "UILD 4EST
&AB %RRORS
$ESIGN %RRORS
51 Design, build, test after Alice Agogino (2 of 3)
In the second step, Agogino places the original design-build- test process in the context of a larger project.
#ONCEIVE 3ELL $ESIGN "UILD 4EST /PERATE
&AB %RRORS
$ESIGN %RRORS
3CIENCE 5SE 3CENARIO
52 Design, build, test after Alice Agogino (3 of 3)
In the last step, Agogio adds feedback loops with early tests of models in order to “fi nd errors faster.”
!RCHI TECTURAL $ESIGN %RRORS %RRORS -ODEL -ODEL 4EST -ODEL 4EST -ODEL
#ONCEIVE 3ELL $ESIGN "UILD 4EST /PERATE
&AB %RRORS
$ESIGN %RRORS
3CIENCE 5SE 3CENARIO
53 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 stu- dents (and others) understand things. Below is an example from one of her classes.
4ASK
-ECHANICAL %NGINEERING
4ASK &ORMULATION 0HASE 3PECIFICATION !NALYSIS OF 0RODUCT %NVIRONMENT
4ECHNICAL 2EQUIREMENTS 3IMPLIFIED &UNCTION AND 3PECIFIED #OSTS
&UNCTIONAL 0HASE $ETERMINATION OF /VERALL &UNCTION 3TRUCTURE
$ETERMINATION OF 3PECIAL &UNCTION 3TRUCTURE
!CTUAL &UNCTION
#OMPARISON OF 3PECIFIED AND !CTUAL &UNCTIONS
&ORM $ESIGN 0HASE &ORM $ESIGN AND -ATERIAL 3ELECTION
$ESIGN FOR 0RODUCTION
!CTUAL &UNCTION !CTUAL #OST
#OMPARISON !CTUAL 3PECIFIED &UNCTION VS !CTUAL 3PECIFIED #OST
2ESULT 0RODUCTION $RAWINGS
0RODUCT
54 New product development process after Steven D. Eppinger and Karl T. Ulrich (1995)
Alice Agogino introduced me to Eppinger and Ulrich’s model of the product development process. It provides a useful outline, but does not capture the “messy” iteration typical of much product development work.
-ISSION )DENTIFY %STABLISH 'ENERATE 3ELECT 4EST 0RODUCT 3ET &INAL 0LAN $EVELOPMENT 3TATEMENT #USTOMER 4ARGET 0RODUCT 0RODUCT #ONCEPTS 3PECIFICATIONS $OWNSTREAM 0LAN .EEDS 3PECIFICATIONS #ONCEPTS #ONCEPTS $EVELOPMENT
0ERFORM %CONOMIC !NALYSIS
"ENCHMARK #OMPETITIVE 0RODUCTS
"UILD AND 4EST -ODELS AND 0ROTOTYPES
4ECHNICAL 0OSSIBILITIES
0ROTOTYPING #YCLES
#USTOMER 0REFERENCES
56 Design process after John Chris Jones (1970)
Along with Christopher Alexander and Bruce Archer, John ods to move from one step to another. Jones notes that Chris Jones was one of the pioneers of the design methods the steps decrease in generality and increase in certainty. movement. Jones fi rst published Design Methods in 1970. Jones also provides a scale for describing the applicable He included several models of design and the design pro- range of a method. (See the left side of the diagram.) We cess. I have included three in this section. may also apply his scale to the scope of problem being un- dertaken. In this way, Jones’s scale is similar to the models Jones used the model below for classifying and selecting of design scope described by Doblin and Alexander. (See design methods. Designers might use one or more meth- pages 17-18.)
4ECHNOLOGICAL #HANGE OR 3OCIO TECHNICAL INNOVATION "RIEF ISSUED
$ESIGN SITUATION EXPLORED
3YSTEM $ESIGNING 0ROBLEM STRUCTURE PERCEIVED OR TRANSFORMED
$ESIGN BY $RAWING "OUNDRIES LOCATED SUB SOLUTIONS DESCRIBED AND CONFLICTS IDENTIFIED
#RAFT %VOLUTION 3UB SOLUTIONS COMBINED INTO ALTERNATIVE DESIGNS
!LTERNATIVE DESIGNS EVALUATED AND FINAL DESIGN SELECTED
57 Value analysis after John Chris Jones (1970)
Jones described value analysis as a design method, one grammed it) is itself a sort of design process—albeit with a aimed “to increase the rate at which designing and manufac- special emphasis on cost. This example of a design process- turing organizations learn to reduce the cost of a product.” nested within a design process nicely illustrates the recursive He saw it as applying to the design of an element within a nature of designing. larger system. Yet his value analysis process (as he dia-
$EFINITION 0HASE $EFINE %LEMENT %XISTING )DEA
$EFINE &UNCTION
%LIMINATE &UNCTION .OT 2EQUIRED !NALYSIS OF #OST
!NALYSIS OF 6ALUE
#REATIVE 0HASE #ONSIDER !LTERNATIVES .EW )DEAS
#OMBINE 7ITH .EW #ONCEPTS 0ARTIAL 3UBSTITUTION 2EDUCTION !NALYSIS OF #OST /THER %LEMENTS
0RELIMINARY 3ORTING
2EJECT 3OME .OT &EASIBLE
!NALYSIS AND 3ELECTION 4ECHNICAL !NALYSIS &INAL !NALYSIS "EST )DEA OF #OST
2EJECT 3OME 4ECHNICAL 2EASONS
3ELECTION 2EJECT 3OME #OST 2EASONS
0RESENTATION 0RESENTATION 3ELLING THE )DEA
58 Man-machine system designing after John Chris Jones (1970)
Jones also described man-machine system designing as a of stages. The specifi cations in each box can be attended to design method, one aimed “to achieve internal compatibility in any order and will require many cross-references before between the human and machine components of a system, they are complete.” He suggests deliberately reversing “the and external compatibility between the system and the envi- traditional sequence of machine-fi rst-people-second” design. ronment in which it operates.” He proposes beginning with training procedures, working out the man-machine interface, and then designing the machine This method, too, is a sort of design process. Jones notes to support the desired training and interface. “the diagram should not be taken to imply a linear sequence
3PECIFY )NPUTS AND /UTPUTS OF 3YSTEM
3PECIFY &UNCTIONS OF 3YSTEM #OMPONENTS
!LLOCATE &UNCTIONS TO -ACHINES OR TO (UMANS
(UMAN &ACTORS $ESIGN 3PECIFY -ACHINE 3PECIFY (UMAN 0ERFORMANCE 0ERFORMANCE
$ESIGN -ACHINE $ESIGN -AN -ACHINE $ESIGN *OB $ESIGN 4RAINING #OMPONENTS )NTERFACES !IDS 0ROCEDURES
#HECK 3YSTEM FOR )NTERNAL AND %XTERNAL #OMPATIBILITY
59 Eight phases of a project Sometimes presented as six phases of a project
People have passed variations of this project parody around for years. Lawson sites an example seen on a wall of the Greater London Council Architects Department in 1978. More recently, Harold Kerzner offered the variation below. One reason these parodies are popular may be that they contain a large measure of truth.
0ROJECT )NITIATION 7ILD %NTHUSIASM $ISILLUSIONMENT #HAOS 3EARCH FOR THE 'UILTY 0UNISHMENT OF THE )NNOCENT 0ROMOTION OF .ON 0ARTICIPANTS $EFINITION OF 2EQUIREMENTS
60 Consultant models
A few consultancies publish their processes. Some fi rms see their processes as a competitive advantage and thus keep them proprietary. Some fi rms operate without processes, but who would admit such a thing?
61 4D software process and variations
The 4D software process, (defi ne, design, develop, deploy) four steps. The phrase is useful as a mnemonic device, gained wide popularity among consultants developing web- but the wide range of variations suggests something is sites during the internet boom. One company, Information missing, for example, feedback and iteration. Author and Systems of Florida (SF) claims to have trademarked the date unknown.
Defi ne Design Develop Deploy
Defi ne Design Develop Deploy Debrief Imirage
Defi ne Design Develop Deploy Dedicate Bonns
Defi ne Design Develop Deploy Do Business Q4-2
Defi ne Design Develop Deploy Enhance Satoria
Defi ne Design Develop Deploy Maintain Chris Brauer
Diagnose Defi ne Design Develop Deploy Muirmedia
Discover Defi ne Design Develop Deploy D5tech et al.
Discover Defi ne Design Develop Deploy Defend Dillon Group
Discover Defi ne Design Develop Deploy Denouement Cris Ippolite
Engagement Discovery Defi ne Design Develop Deploy Team 1
Plan Defi ne Design Develop Deploy Conclude Proxicom
Analyze Defi ne Design Develop Deploy Assess Maintain Hbirbals
Defi ne Design Develop Test Deploy Manage Borland
Inform Defi ne Detail Design Develop Deploy Phoenix Pop
62 IT consulting process overview after Mindtree Consulting
Mindtree places the 4D process in a larger context, linking each step to deliverables and related processes. The pairing of process steps and deliverables in a matrix is an important and recurring framework or archetype.
3COPE $OCUMENT 2EQUIREMENTS 5SER 2EVIEWED 4ESTED 0RODUCT !RCHITECTURE 4ECHNICAL $ESIGN 5NIT 4ESTED 2OAD -AP 3OURCE #ODE -AJOR $ELIVERABLES
#ONTINUOUS )NNOVATION
$ISCOVERY
$EFINITION !PPLICATION -ANAGEMENT $ESIGN
$EVELOPMENT
4ESTING ,IFE #YCLE 0ROCESSES
#ONTINUOUS 2EFINEMENT
0ROJECT -ANAGEMENT 2EQUIREMENTS 3COPE #HANGE -ANAGEMENT #ONFIGUREMENT -ANAGEMENT #ONTINUOUS 0ROCESSES
63 Other models
This page presents a sampling of design process models from leading consultancies. They resemble the 4D model.
On the facing page is IDEO’s design process as described in Business Week. IDEO is a large (by design standards) multidisciplinary design consultancy.
Studio Archetype, 1998 Defi nition Concept Creation Implementation
Cheskin, 2004 Discover Identify Validate Articulate
Frog, 2004
Product Lifecycle Phases Conceptual Design Detailed Design Procurement/Production Operations/Support
Product Design Project Defi nition Product Defi nition Product Development Product Engineering Production
Brand & Space Process Investigation Concept Development Concept Refi nement/Validation Implementation
Digital Media Process Investigation Exploration Defi nition Implementation Integration/Testing Launch
64 IDEO (2004)
/BSERVATION 3OME OF )$%/S TECHNIQUES )$%/S COGNITIVE PSYCHOLOGISTS ANTHROPOLOGISTS AND SOCIOLOGISTS TEAM UP WITH CORPORATE CLIENTS TO 3HADOWING /BSERVING PEOPLE USING PRODUCTS SHOPPING GOING TO HOSPITALS TAKING A TRAIN USING THEIR CELL PHONES UNDERSTAND THE CONSUMER EXPERIENCE "EHAVIORAL MAPPING 0HOTOGRAPHING PEOPLE WITHIN A SPACE SUCH AS A HOSPITAL WAITING ROOM OVER TWO OR THREE DAYS #ONSUMER JOURNEY +EEPING TRACK OF ALL THE INTERACTIONS A CONSUMER HAS WITHIN A PRODUCT SERVICE OR SPACE #AMERA JOURNALS !SKING CONSUMERS TO KEEP VISUAL DIARIES OF THEIR ACTIVITIES AND IMPRESSIONS RELATING TO A PRODUCT %XTREME USER INTERVIEWS 4ALKING TO PEOPLE WHO REALLY KNOWOR KNOW NOTHING ABOUT A PRODUCT OR SERVICE AND EVALUATING THEIR EXPERIENCE USING IT 3TORYTELLING 0ROMPTING PEOPLE TO TELL PERSONAL STORIES ABOUT THEIR CONSUMER EXPERIENCES 5NFOCUS GROUPS )NTERVIEWING A DIVERSE GROUP OF PEOPLE 4O EXPLORE IDEAS ABOUT SANDALS )$%/ GATHERED AN ARTIST A BODYBUILDER A PODIATRIST AND A SHOE FETISHIST
"RAINSTORMING $EFER JUDGMENT $ONT DISMISS ANY IDEAS !N INTENSE IDEA GENERATING SESSION ANALYZING DATA "UILD ON THE IDEAS OF OTHERS .O hBUTS v ONLY hANDSv GATHERED BY OBSERVING PEOPLE %ACH LASTS NO MORE THAN %NCOURAGE WILD IDEAS %MBRACE THE MOST OUT OF THE BOX NOTIONS BECAUSE THEY CAN BE THE KEY TO SOLUTIONS AN HOUR 2ULES OF BRAINSTORMING ARE STRICT AND ARE 'O FOR QUANTITY !IM FOR AS MANY NEW IDEAS AS POSSIBLE )N A GOOD SESSION STENCILED ON THE WALLS UP TO IDEAS ARE GENERATED IN MINUTES "E VISUAL 5SE YELLOW RED AND BLUE MARKERS TO WRITE ON BIG INCH BY INCH 0OST ITS THAT ARE PUT ON A WALL 3TAY FOCUSED ON THE TOPIC !LWAYS KEEP THE DISCUSSION ON TARGET /NE CONVERSATION AT A TIME .O INTERRUPTING NO DISMISSING NO DISRESPECT NO RUDENESS
2APID PROTOTYPING 3OME GUIDELINES -OCKING UP WORKING MODELS HELPS EVERYONE VISUALIZE POSSIBLE SOLUTIONS AND SPEEDS UP DECISION MAKING AND -OCK UP EVERYTHING )T IS POSSIBLE TO CREATE MODELS NOT ONLY OF PRODUCTS BUT ALSO OF SERVICES SUCH AS HEALTH CARE AND SPACES SUCH AS MUSEUM LOBBIES INNOVATION 5SE VIDEOGRAPHY -AKE SHORT MOVIES TO DEPICT THE CONSUMER EXPERIENCE 'O FAST "UILD MOCK UPS QUICKLY AND CHEAPLY .EVER WASTE TIME ON COMPLICATED CONCEPTS .O FRILLS -AKE PROTOTYPES THAT DEMONSTRATE A DESIGN IDEA WITHOUT SWEATING OVER THE DETAILS #REATE SCENARIOS 3HOW HOW A VARIETY OF PEOPLE USE A SERVICE IN DIFFERENT WAYS AND HOW VARIOUS DESIGNS CAN MEET THEIR INDIVIDUAL NEEDS "ODYSTORM $ELINEATE DIFFERENT TYPES OF CONSUMERS AND ACT OUT THEIR ROLES
2EFINING (ERES HOW ITS DONE !T THIS STAGE )$%/ NARROWS DOWN THE CHOICES TO A FEW POSSIBILITIES "RAINSTORM IN A RAPID FASHION TO WEED OUT IDEAS AND FOCUS ON THE REMAINING BEST OPTIONS &OCUS PROTOTYPING ON A FEW KEY IDEAS TO ARRIVE AT AN OPTIMAL SOLUTION TO A PROBLEM %NGAGE THE CLIENT ACTIVELY IN THE PROCESS OF NARROWING THE CHOICES "E DISCIPLINED AND RUTHLESS IN MAKING SELECTIONS &OCUS ON THE OUTCOME OF THE PROCESSREACHING THE BEST POSSIBLE SOLUTIONS 'ET AGREEMENT FROM ALL STAKEHOLDERS 4HE MORE TOP LEVEL EXECUTIVES WHO SIGN OFF ON THE SOLUTION THE BETTER THE CHANCES OF SUCCESS
)MPLEMENTATION 4AP ALL RESOURCES )NVOLVE )$%/S DIVERSE WORKFORCE FROM COUNTRIES TO "RING )$%/S STRONG ENGINEERING DESIGN AND SOCIAL CARRY OUT THE PLANS SCIENCE CAPABILITIES TO BEAR WHEN ACTUALLY CREATING A 4HE WORKFORCE %MPLOYEES HAVE ADVANCED DEGREES IN DIFFERENT KINDS OF ENGINEERING MECHANICAL ELECTRICAL BIOMECHANICAL SOFTWARE AEROSPACE AND MANUFACTURING PRODUCT OR SERVICE -ANY ARE EXPERTS IN MATERIALS SCIENCE COMPUTER AIDED DESIGN ROBOTICS COMPUTER SCIENCE MOVIE SPECIAL EFFECTS MOLDING INDUSTRIAL INTERACTION GRAPHIC AND WEB INFORMATION FASHION AND AUTOMOTIVE DESIGN BUSINESS COMMUNICATIONS LINGUISTICS SOCIOLOGY ERGONOMICS COGNITIVE PSYCHOLOGY BIOMECHANICS ART THERAPY ETHNOLOGY MANAGEMENT CONSULTING STATISTICS MEDICINE AND ZOOLOGY
65 As proposed by the project sponsor As specifi ed 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 Software development models
Development processes remain a topic of heated discussion in the software development world. This section provides an overview of some of the prominent models.
67 Waterfall lifecycle after Philippe Kruchten (2004)
The essence of the “waterfall” approach is getting one stage Kroll admitted, “In practice, most teams use a modifi ed “right” before moving on to the next. Output (a “deliverable waterfall approach, breaking a project down into two or more document”) from one phase serves as input (requirements) parts, sometimes called phases or stages. This helps to to the next phase. Kruchten noted, “Of paramount impor- simplify integration, get testers testing earlier, and provide an tance for certain projects is the issue of freezing the require- earlier reading on project status. This approach also breaks ments specifi cations (together with some high-level design) up the code into manageable pieces and minimizes the inte- in a contractual arrangement very early in the lifecycle, prior gration code . . .” to engaging in more thorough design and implementation work. This is the case when an organization has to bid a According to Kruchten, “we inherited the waterfall lifecycle fi rm, fi xed price for a project.” Per Kroll (2004) noted, “Many from other engineering disciplines, where it has proven very design teams would view modifying the design after Stage 1 effective. It was fi rst formally described by Winston Royce as a failure of their initial design or requirements process.” in 1970.”
2EQUIREMENTS
$ESIGN
#ODING
4ESTING
2EQUIREMENTS 2EQUIREMENTS 2EQUIREMENTS
$ESIGN $ESIGN $ESIGN
#ODING #ODING #ODING
4ESTING 4ESTING 4ESTING
68 Rational Unifi ed Process (RUP) after Phillippe Kruchten (2003)
RUP follows an “iterative” lifecycle—as opposed to the “wa- Kruchten noted, “The process has two structures or, terfall” lifecycle—“developing in iterations that encompass if you prefer, two dimensions: the activities of requirements analysis, design, implementa- - The horizontal dimension represents time and shows the tion, integration, and tests. One of the best descriptions is in lifecycle aspects of the process as it unfolds. Professor Barry Boehm’s paper on the “spiral” model. You - A vertical dimension represents core process disciplines can summarize it with the catch phrase, ‘Analyze a little, (or workfl ows), which logically group software engineering design a little, test a little, and loop back.’” (For more on activities by their nature.” Boehm’s model, see page 122.) Rational Software was an independent developer purchased by IBM in 2003. Rational (and later IBM) developed and -AJOR MILESTONE sold a suite of software development tools built around the )NTERNAL RELEASE Rational Unifi ed Process (RUP). RUP was designed using the Unifi ed Modeling Language (UML) and has as its underlying %XTERNAL RELEASE object model, the Unifi ed Software Process Model (USPM).
0HASES )NCEPTION %LABORATION #ONSTRUCTION 4RANSITION
)TERATIONS
"USINESS MODELING
2EQUIREMENTS
!NALYSIS AND DESIGN
)MPLEMENTATION
4EST
$EPLOYMENT
#ONFIGURATION AND CHANGE MANAGEMENT
0ROJECT MANAGEMENT
%NVIRONMENT
69 Extreme Programming (XP) Process after Don Wells (2000)
Kent Beck, founder of Extreme Programming, has described communications—factors unrelated to the programming. how he created XP in 1996. Chrysler asked him to put a The context in which the software development takes place payroll system project back on track. When they called him, proves as important to the project’s success as the program- eighteen months into the project, the system still couldn’t ming itself.” print a check. Three weeks later, Beck had them print their fi rst one. “Up until then I believed better programming At its core, XP is a simple process of experimentation and would solve all the world’s ills. Yes, you can screw up the improvement: Divide a project into “iterations”; in each itera- programming so badly you kill the project. Usually, however, tion, implement a few new features called “stories”; for each the problem concerns relationships between the business story, write “acceptance tests” to demonstrate the story people and the programmers, the budget process, poor meets customer expectations. Alan Cooper, however, argues
4EST 3CENARIOS
.EW 5SER 3TORY 5SER 3TORIES 2EQUIREMENTS 0ROJECT 6ELOCITY "UGS
3YSTEM -ETAPHOR 2ELEASE 0LAN ,ATEST 6ERSION #USTOMER !PPROVAL !RCHITECTURAL 2ELEASE )TERATION !CCEPTANCE 3MALL 3PIKE 0LANNING 4ESTS 2ELEASES
5NCERTAIN #ONFIDENT %STIMATES %STIMATES 3PIKE
.EXT )TERATION
.EW 5SER 3TORY 0ROJECT 6ELOCITY
2ELEASE 5SER 3TORIES 5NFINISHED 4ASKS ,EARN AND #OMMUNICATE 0LAN
0ROJECT 6ELOCITY )TERATION 0LAN .EW &UNTIONALITY .EXT )TERATION $EVELOPMENT ,ATEST )TERATION 0LANNING "UG &IXES 6ERSION
"UGS &AILED !CCEPTANCE 4ESTS $AY BY $AY
70 XP is not a design process—because it includes no mecha- ownership. At the center of the last diagram is pair program- nism for understanding user goals. (For more on Cooper, see ming, one of the primary distinguishing features of XP. Two pages 86-91.) programmers work together at a single computer. Beck claims this increases quality. It has to be a lot more fun than The models below are nested. The fi rst one shows the whole coding alone. (For another model of extreme programming, project; the second “zooms in” on iteration; the third “zooms see page 127.) in” on development; and the fourth on collective code
5NFINISHED ,EARN AND 4ASKS #OMMUNICATE
)TERATION 4OO -UCH 3HARE 0AIR 0ROGRAMMING .EW 0LAN 4ASKS TO $O 2EFACTOR -ERCILESSLY &UNCTIONALITY -OVE 0EOPLE !ROUND #2# #ARDS
.EXT 4ASK OR #OLLECTIVE 5NIT 4ESTS 0ASSED 3TAND 5P #ODE -EETING &AILED /WNERSHIP !CCEPTANCE 4EST 0ASSED !CCEPTANCE 4ESTS
$AY BY $AY "UG &IXES &AILED !CCEPTANCE 4ESTS
-OVE 0EOPLE !ROUND
#2# 5NIT 3IMPLE $ESIGN #ARDS #HANGE 0AIR 7E .EED (ELP 4ESTS 0ASSED
#OMPLEX 0ROBLEM 2UN !LL 0AIR 5P &AILED 5NIT 4EST .EW 5NIT 4ESTS 5NIT 4ESTS .EXT 4ASK OR #REATE A 0AIR 0RO #ONTINUOUS 2UN &AILED &AILED !CCEPTANCE 4EST 5NIT 4EST GRAMMING )NTEGRATION !CCEPTANCE 4EST 0ASSED 5NIT 4EST .EW &UNCTIONALITY
3IMPLE #ODE #OMPLEX #ODE !CCEPTANCE 4EST 0ASSED
2EFACTOR -ERCILESSLY
71 V model Paul Rock (~1980), IABG (1992)
The principle characteristic of the V model seems to be that Accounts of this model’s origin vary. According to Gold- it weights testing equally with design and development. smith and Graham, “Initially defi ned by the late Paul Rook Goldsmith and Graham (2002) note, “In fact, the V Model in the late 1980s, the V was included in the U.K.’s National emerged in reaction to some waterfall models that showed Computing Centre publications in the 1990s with the aim testing as a single phase following the traditional develop- of improving the effi ciency and effectiveness of software ment phases . . . The V Model portrays several distinct test- development.” But according to Morton Hirschberg, formerly ing levels and illustrates how each level addresses a different of the Army Research Laboratory, “The V Model is a series stage of the lifecycle. The V shows the typical sequence of of General Directives (250, 251, and 252) that prescribe or development activities on the left-hand (downhill) side and describe the procedures, methods to be applied, and the the corresponding sequence of test execution activities on functional requirements for tools to be used in developing the right-hand (uphill) side” software systems for the German Federal Armed Forces.”
#ONTRACT 2EVIEW 7ARRANTY 4EST
5SERS 3OFTWARE !CCEPTANCE 4ESTING 2EQUIREMENTS
3OFTWARE 2EQUIREMENTS 3YSTEM 4ESTING 3PECIFICATIONS
3OFTWARE (IGH ,EVEL $ESIGN )NTEGRATION 4ESTING 1UALITY $EVELOPMENT !SSURANCE
$ETAILED $ESIGN 5NIT 4ESTING
#ODING
0ROJECT -ANAGEMENT
72 Joint Application Development (JAD) after Jane Wood and Denise Silver (1995)
JAD sessions (sometimes jam sessions) are intensive work- According to Carmel et al (1993), “JAD was conceived by shops, usually three to fi ve days long, in which various levels Chuck Moris and Tony Crawford of IBM in 1977. The JAD of users meet with developers to hammer out requirements approach was loosely derived from another IBM methodol- for a system. Typically consultants use the process to quickly ogy—BSP (Business Systems Planning). The fi rst JAD meet- lock down user requirements for automation projects—so ings . . . used the same basic JAD concepts still used today: they can minimize the time needed to defi ne requirements user participant meetings, magnetic visual displays, and and work within a fi xed bid. careful documentations of the meeting.”
0ROJECT 2EQUEST
$EFINITION )NTERVIEW -ANAGEMENT 3ELECT THE *!$ 4EAM
0REPARE THE -ANAGEMENT 3CHEDULE THE 3ESSION $EFINITION 'UIDE
-ANAGEMENT $EFINITION 'UIDE
2ESEARCH "ECOME &AMILIAR #REATE $ATA -ODELS AND WITH THE 3YSTEM 0ROCESS -ODELS $ATA -ODELS AND 0ROCESS -ODELS 'ATHER 0RELIMINARY )NFORMATION 0REPARE THE 3ESSION !GENDA
3ESSION !GENDA
0RELIMINARY )NFORMATION 7ORKING $OCUMENT
0REPERATION 4HE 7ORKING $OCUMENT 4RAIN THE 3CRIBE
6ISUAL !IDS 4HE PRE 3ESSION -EETING
3ET 5P THE -EETING 2OOM
/VERHEADS &LIP #HARTS AND -AGNETICS
4HE 3ESSION 0ROCESS -ODELS $ATA -ODELS 3CREENS
!SSUMPTIONS /PEN )SSUES
2EPORTS
3CRIBE .OTES AND &ORMS
4HE &INAL $OCUMENT 0RODUCE THE !SSEMBLE THE 4RACK $ISTRIBUTION &INAL $OCUMENT $OCUMENT
4HE 2EVIEW -EETING !PPROVE THE $OCUMENT
#HANGING 2EQUIREMENTS
3IGNED !PPROVAL &ORM *!$ $OCUMENT
73 PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987)
Charbonneau wrote, “The PMBOK describes a set of gener- PM as ‘the application of knowledge, skills, tools, and tech- ally accepted practices that PM practitioners can use to niques to project activities to meet project requirements.’ manage all types of projects, including software develop- ment and deployment projects. The PMBOK presents [thirty-nine] PM practices in logi- cal groupings. One dimension describes [nine]‘knowledge The PMBOK defi nes a project as ‘a temporary endeavor areas’ while the other dimension describes project manage- undertaken to create a unique product or service.’ It defi nes ment processes split into fi ve process groups.” The process groups are shown in the model below.
)NITIATING 0LANNING 0ROCESSES 0ROCESSES
#ONTROLLING %XECUTING 0ROCESSES 0ROCESSES
ARROWS REPRESENT FLOW #LOSING OF INFORMATION 0ROCESSES
74 ISO 13407 Human-centered design processes for interactive systems Tom Stewart et al. (1999)
“ISO 13407 provides guidance on achieving quality in use edge and techniques with the objective of enhancing effec- by incorporating user centered design activities throughout tiveness and productivity, improving human working condi- the life cycle of interactive computer-based systems. It des- tions, and counteracting the possible adverse effects of use cribes user centered design as a multi-disciplinary activity, on human health, safety and performance.” which incorporates human factors and ergonomics knowl-
0LAN THE HUMAN CENTERED PROCESS
-EETS REQUIREMENTS 5NDERSTAND AND SPECIFY THE CONTEXT OF USE
%VALUATE 3PECIFY USER DESIGN AGAINST AND ORGANIZATIONAL USER REQUIREMENTS REQUIREMENTS
0RODUCE DESIGN SOLUTIONS
75 User-centered design process (UCD) after Karel Vredenburg (2003)
Vredenburg describes this “simplifi ed generic description of or an analog method. This answers the question, ‘What else the design process” as follows: “The design process starts is out there?’ with the collection of relevant market defi nition information to answer the basic question, ‘Who do we think will use this At this point, conceptual design of the user experience offering?’ This involves understanding the target markets, starts, and early feedback is gathered from users, answering types of users, prime competitors, market trends, high level the question, ‘How’s this for starters?’ This leads to several needs and preferences, and so forth. Next, detailed informa- cycles of iterative detailed design and user feedback through tion is collected from representative users within the target design evaluation and validation sessions, answering the markets to understand their goals and tasks to answer the questions, ‘Does this work?’ and ‘What would make it bet- question, ‘What are they looking for?’ Following this, we ter?’ At the end of the development cycle, a user feedback attempt to understand how the tasks described in the prior benchmark assessment session is conducted to answer the step are carried out today either with a competitor’s product question, ‘How do we stack up?’”
7HY DO WE THINK WE WILL USE THIS OFFERING -ARKETING DEFINITION
7HAT ARE THEY LOOKING FOR 4ASK ANALYSIS
7HAT ELSE IS OUT THERE #OMPETITIVE EVALUATION
(OWS THIS FOR STARTERS $ESIGN AND WALK THROUGH
$OES THIS WORK 7HAT WOULD MAKE IT BETTER $ESIGN EVALUATION AND VALIDATION
(OW DO WE STACK UP "ENCHMARK ASSESSMENT
76 Relation of UCD to IPD and Business Management after Karel Vredenburg (2003)
The model below illustrates how User Centered Design UCD is a core enabling process in the overall integrated (UCD) fi ts into IBM’s integrated product development pro- product development (IPD) process, which is the business cess (IPD) and to its overall business management process. checkpoint mechanism used for all funding and project- milestone reviews within IBM. Having UCD and UE included Vredenburg noted, “Developing a new process and further directly in the corporate-wide IPD process ensures that deci- enhancing it is only one component, albeit an important one, sions made about an offering will be required to take UCD in the overall strategy of building ease of use into the total and UE information into account.” user experience at IBM. Organizations need to be enabled to carry out new processes and be provided with leadership Vredenburg also noted creating new corporate-wide posi- and guidance while executing them. tions, development of education and training, communica- tions, and collaboration programs, and provision of tools and technology as part of IBM’s strategy for integrating UCD.
)NTEGRATED 0ORTFOLIO -ANAGEMENT 4EAM )0-4
"USINESS -ANAGEMENT 5NDERSTAND 0ERFORM 0ERFORM $EVELOP !LIGN -ANAGE -ARKET INFORMATION THE MARKETPLACE MARKET PORTFOLIO MARKET SEGMENT AND OPTIMIZE MARKET SEGMENT #USTOMER FEEDBACK SEGMENTATION ANALYSIS STRATEGY BUSINESS PLANS AND ASSESS #OMPETITION INFORMATION AND PLAN PERFORMANCE 4ECHNOLOGY TOOLS 0RODUCT PORTFOLIO
)NTEGRATED 0RODUCT $EVELOPMENT $EVELOP $EVELOP $EVELOP 1UALIFY 2AMP UP ,IFE CYCLE 3ATISFIED #ANDIDATE PROJECTS PRODUCT PRODUCT AND VERIFY AND CERTIFY AND LAUNCH MANAGEMENT CUSTOMERS CONCEPTS DEFINITION AND PLAN
#ONCEPT $#0 0LAN $#0 !VAILABILITY $#0
5SER #ENTERED $ESIGN 3TUDY #REATE )TERATIVELY 6ALIDATE AND DEFINE CONCEPT DESIGN DEVELOP DETAILED PRODUCT AGAINST USERS TASKS AND OF USER DESIGN USER EXPECTATIONS COMPETITION EXPERIENCE WITH USERS
0ROJECT $EVELOPMENT 4EAMS 0$4 77 Sun Sigma Framework DMADV methodology for new products
0(!3%3
$EFINE -EASURE !NALYZE $ESIGN 6ERIFY )DENTIFY THE PROBLEM OR )DENTIFY LIST OF CUSTOMER #USTOMIZE CUSTOMER $EVELOP ONE CLEAN PAPER )MPLEMENT THE NEW PROCESS TO BE FIXED OR TO REQUIREMENTS AND DEVELOP EXPECTATIONS TO CREATE A DESIGN TO MEET CUSTOMERS PROCESS AND VERIFY THAT THE BE DESIGNED AND PRIORITIZE #41S AROUND CLEAN PAPER DESIGN REQUIREMENTS DESIGN WORKS CUSTOMER EXPECTATIONS
!#4)6)49 35--!29
#HARTER APPROVAL #USTOMER 0RIORITIZED .EEDS #ONCEPT $ESIGN $ETAILED $ESIGN 6ERIFIED $ESIGN )DENTIFY ALL CUSTOMERS )$ FUNCTIONS REQUIRED TO MEET #RITICAL $EVELOP DETAILED DESIGN ELEMENTS "UILD PILOT PRODUCT PROCESS FOR 3UN3HOT 7ORKOUT 3ESSION TO 0RIORITIZE CUSTOMERS TO 1UALITIES #41S &LOWDOWN #41S TO ELEMENTS VERIFICATION IDENTIFY 1UICK (ITS !SSESS CURRENT CUSTOMER DATA $EVELOP ALTERNATE DESIGN CONCEPTS %STIMATE CAPABILITIES OF DETAILED %XECUTE TEST DOCUMENT #OLLECT h6OICE OF THE #USTOMERv 3ELECT MOST PROMISING CONCEPTS DESIGN !NALYZE RESULTS AND ADJUST DESIGN 0HASE AND 'ATE APPROVAL $ETERMINE h6OICE OF THE #USTOMERv $EVELOP CONCEPT DESIGN 0ERFORM DESIGN RISK ASSESSMENT STRATEGY &-%! 0ROJECT #LOSURE 5PDATE PROJECT IN 024 !NALYZE AND PRIORITIZE NEEDS 0ERFORMANCE 'AP !NALYZE GAP AND OPTIMIZE DESIGN )MPLEMENT DESIGN FULL SCALE $EPLOY #41S TO CONCEPT DESIGN %XECUTE CONTROL PLAN #4/ $RILLDOWN 0REDICT #41 PERFORMANCE 6ERIFICATION 0LAN 4RANSFER OWNERSHIP $ETERMINE CHARACTERISTICS AND 0ERFORM '!0 ANALYSIS AND REVISE #USTOMER FEEDBACK ON DESIGN MEASURES FOR NEEDS CONCEPT DESIGN $ETERMINE WHAT TO VERIFY &INANCIAL BENEFITS VERIFIED AND 3ELECT CRITICAL FEW MEASURES 0ERFORM DESIGN RISK ASSESSMENT #REATE TEST DOCUMENT APPROVED -EASUREMENT SYSTEM CAPABILITY &-%! #REATE PILOT PLAN %STABLISH TARGETS AND SPECS 0HASE AND 'ATE APPROVAL 3ET PERFORMANCE 3IGMA GOALS 2EFINE BENEFIT ESTIMATES #ONTROL 0LAN )$ CRITICAL INPUT PROCESS OUTPUT 5PDATE PROJECT IN 024 "ENCHMARKING BEST PRACTICE 0HASE AND 'ATE APPROVAL PARAMETERS IDENTIFIED $OCUMENT PROCEDURES TO GUIDE #ELEBRATION AND RECOGNITION 5PDATE PROJECT IN 024 ONGOING OPERATION 0HASE AND 'ATE APPROVAL %XIT STRATEGY IDENTIFIED
5PDATE PROJECT IN 024 !SSESS PATENTABILITY OF PROCESSPRODUCT
0HASE AND 'ATE APPROVAL
5PDATE PROJECT IN 024
/540543
0ROJECT #HARTER h6OICE OF THE #USTOMERv 3TRATEGY !LTERNATE DESIGN CONCEPTS $ETAILED DESIGN ELEMENTS 0ILOT PRODUCT PROCESS "USINESS #ASE 0ROBLEM 3TATEMENT 0ERFORMANCE 3IGMA GOALS &INAL CONCEPT DESIGN 4EST DOCUMENT 5PDATED SCORECARD 'OAL 3TATEMENT 3COPE &IRST PASS SCORECARD 5PDATED SCORECARD 0ILOT PLAN &INAL PRODUCT PROCESS $EFINITION OF 4EAM AND 4IME #OMMITMENTS 3TAKEHOLDER ANALYSIS AND ACTIONS 3TAKEHOLDER ANALYSIS AND ACTIONS 5PDATED SCORECARD 4IMELINE -ILESTONES %STIMATED "ENEFITS 3TAKEHOLDER ANALYSIS AND ACTIONS 2ISKS AND #ONSTRAINTS #HARTER !PPROVALS
(IGH ,EVEL 0ROCESS -AP
3TAKEHOLDER !NALYSIS AND !CTIONS
78 Sun Sigma Framework DMAIC methodology for improving existing products
0(!3%3
$EFINE -EASURE !NALYZE )MPROVE #ONTROL )DENTIFY THE PROBLEM AND -EASURE THE CURRENT !NALYZE THE PROCESS 'ENERATE SELECT DESIGN )NSTITUTIONALIZE THE IDENTIFY TOP TO #RITICAL PERFORMANCE OF THE DEFECT VARIATION TO DETERMINE ROOT TEST AND IMPLEMENT IMPROVEMENT AND TO 1UALITIES #41S TO #41 NOT MET AND DISPLAY CAUSES AND OPPORTUNITIES IMPROVEMENTS IMPLEMENT ONGOING FOCUS IMPROVEMENTS ON VARIATION IN THE PROCESS FOR REDUCING THE VARIATION MONITORING
!#4)6)49 35--!29
#HARTER APPROVAL /UTPUT -EASUREMENT 2OOT #AUSE !NALYSIS 3OLUTION 'ENERATION AND 0ILOT 4EST 3USTAINED 3OLUTION 0ROJECT 9 AND DEFECT DEFINED "RAINSTORM ALL POSSIBLE 8S $EVELOP AND SELECT SOLUTIONS 0ROCESS DOCUMENTATION CONTROLS IN 3UN3HOT 7ORKOUT 3ESSION TO 0ERFORMANCE SPECIFICATION FOR 9 0RIORITIZE LIST OF 8S 0ERFORM PILOT OF SOLUTIONS PLACE IDENTIFY 1UICK (ITS $ATA COLLECTION PLAN 6ERIFY 8 WITH DATA #ONFIRM IMPROVEMENTS -EASURE PERFORMANCE -EASUREMENT SYSTEM VALIDATED #ONFIRM PRIORITIZED 8S #ONFIRM SUSTAINABLE SOLUTION 0HASE AND 'ATE APPROVAL #OLLECT DATA FOR 9 0ERFORMANCE 'AP -AP NEW PROCESS 6ALIDATE MEASUREMENT SYSTEM ON 8S 0ROCESS CAPABILITY FOR 9 )DENTIFY GAPS BETWEEN CAPABILITIES $ETERMINE NEW CAPABILITY 5PDATE PROJECT IN 024 )MPROVEMENT GOAL FOR 9 AND CUSTOMER REQUIREMENTS PERFORMANCE 0ROJECT #LOSURE 2E EVALUATE $-!)# VS $-!$6 %VALUATION TRANSITION OPPORTUNITIES "ENCHMARKING BEST PRACTICE )MPLEMENTATION 0LAN )DENTIFY OTHER IMPROVEMENT IDENTIFIED "ENCHMARKING $EVELOP IMPLEMENTATION PLAN OPPORTUNITIES )DENTIFY CONTROLS 0ROJECT DOCUMENTATION COMPLETE 0HASE AND GATE APPROVAL 2EFINE BENEFIT ESTIMATES )MPLEMENT IMPROVEMENTS 4RANSLATION PACKAGE
5PDATE PROJECT IN 024 0HASE AND 'ATE APPROVAL "ENCHMARKING &INANCIAL BENEFITS VERIFIED AND APPROVED 5PDATE PROJECT IN 024 0HASE AND 'ATE APPROVAL 0HASE AND 'ATE APPROVAL 5PDATE PROJECT IN 024 5PDATE PROJECT IN 024
#ELEBRATION AND RECOGNITION
/540543
0ROJECT #HARTER $ETAILED PROCESS MAP 3TAKEHOLDER ANALYSIS AND ACTIONS 0OSSIBLE SOLUTIONS 0ROJECT DOCUMENTATION "USINESS #ASE 0ROBLEM 3TATEMENT 3TAKEHOLDER ANALYSIS AND ACTIONS 0ILOT OF SOLUTIONS 4RANSLATION PACKAGE 'OAL 3TATEMENT 6ALIDATED CUSTOMER #41S -AP OF NEW PROCESS 3COPE $EFINITION OF TEAM AND TIME )MPLEMENTATION PLAN COMMITMENTS 4IMELINE MILESTONES &INAL IMPROVEMENTS %STIMATED BENEFITS 2ISKS AND CONSTRAINTS 3TAKEHOLDER ANALYSIS AND ACTIONS #HARTER APPROVAL
(IGH ,EVEL 0ROCESS -AP
3TAKEHOLDER !NALYSIS AND !CTIONS
79 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product instances
0(!3%3
#ONCEPT 0LAN $EVELOP 3YSTEM 4EST #USTOMER $EPLOY 3USTAIN 2ETIRE )NTEGRATE !CCEPTANCE 4EST
!#4)6)49 35--!29
"USINESS 5NIT CREATES #REATE OPTIONAL %XECUTE 3YSTEM 4EST 6ERIFY EXECUTION !NNOUNCE TO THE 3USTAIN THE PRODUCT )NVENTORY CAP A 0RODUCT 0ORTFOLIO 3UB 3TEERING THROUGH SYSTEM TEST PUBLIC EQUIPMENT AND 3TEERING #OMMITTEE #OMMITTEES #REATE TRAINING OF 0RODUCT 0LAN #ONDUCT ON GOING DISPOSABLES MATERIALS #REATE AND DELIVER VIABILITY ASSESSMENTS #REATE OPTIONAL %XECUTE #USTOMER 0RODUCTION 4RAINING !NNOUNCE END OF LIFE #ONSOLIDATION 4EAMS #REATE ANNOUNCEMENT !CCEPTANCE 4EST !NNOUNCE INTENT TO TO PUBLIC # 4EAMS PACKAGE #REATE AND EXECUTE END OF LIFE !NNOUNCE TO INTERNAL ,AUNCH 0ACKAGE %XECUTE %ND OF )NFLUENCE ,INE COMMUNITY #ONDUCT ND LESSONS 0RODUCT 0LAN -ANAGEMENT TO START #ONDUCT ST LESSONS LEARNED REVIEW PROJECTS !NNOUNCE TO CHANNELS LEARNED REVIEW #ONDUCT RD FINAL LESSONS LEARNED !PPROVE EACH #REATE TRAINING REVIEW #OMPONENT 0ROJECT MATERIALS 0LAN #ONDUCT 2EVENUE !PPROVE EACH 2ELEASE #OMPONENT 0ROJECT !RCHITECTURE
4EST EACH COMPONENT
$ELIVER EACH #OMPONENT 0ROJECT TO # 4EAM
#ONDUCT #OMPONENT 4/)
4EST #OMPONENTS
#ONDUCT 0RODUCT 4/)
/540543
0RODUCT &UNCTIONAL #OMPONENT 0LANS &INALIZED 3ALES 0LAN &INALIZED 3UPPORT %ND OF 0RODUCT 0LAN &INALIZED %ND OF 2EQUIREMENTS 3PECIFICATION 0LAN 3UPPORT ,IFE 0LAN $OCUMENT )NTERNAL $ESIGN 3YSTEM 4EST 2EPORTS 0RODUCT 0LAN 3PECIFICATION #USTOMER )NITIAL &UNCTIONAL $OCUMENT 5PDATED 0RODUCT !CCEPTANCE 4EST 3PECIFICATION #OMPONENT "OUNDARY 3UMMARY 2EPORT )NITIAL 0RODUCT )NTEGRATION 4EST 0LANS 0RODUCT #ONTENT #ONTENTS ,IST "/- !PPROVED 0RODUCT $EFECT 2ESOLUTION AND $OCUMENT PAGERS FOR #ONTENT ,IST "/- 2ISK !SSESSMENT PAGERS FOR REQUIRED COMPONENTS 2EPORTS COMPONENTS $EFECT 2ESOLUTION AND &INALIZED 00$ 2ISK !SSESSMENT 4RAINING -ATERIALS /PS-RG 0LAN 2EPORTS
&INALIZED 00$ -ARKETING 0LAN
4RAINING -ATERIALS
!NNOUNCEMENT 0ACKAGE
80 Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) “Mapped” processes for product lines
0(!3%3
#ONCEPT 0LAN $EVELOP 3YSTEM 4EST #USTOMER $EPLOY 3USTAIN 2ETIRE )NTEGRATE !CCEPTANCE 4EST
!#4)6)49 35--!29
"5 CREATES 0RODUCT $EVELOP THE PRODUCT 1UALIFY THE PRODUCT #ONFIRM PRODUCT ,AUNCH THE PRODUCT -ANAGE PRODUCT 2ETIRE PRODUCT AND ,INE 0ORTFOLIO 3TEERING AND VERIFY COMPONENT FUNCTIONALITY AND FUNCTIONALITY IN PROFITABILITY AND MANAGE CUSTOMER #OMMITTEE 0# PERFORMANCE PERFORMANCE PLANNED CUSTOMER 3TABILIZE OPERATIONAL GROWTH TRANSITIONS ENVIRONMENTS AND SUPPORT $EVELOP 3UNS AND 1UALIFY PRODUCTION PROCESSES 0ROVIDE CUSTOMER CRITICAL PARTNERS AND SUPPLIER %XECUTE INTRODUCTION SUPPORT AND DEFECT PRODUCTION PROCESSES PROCESSES AND SUPPORT PLANS TRACKING
0REPARE COMPREHENSIVE PLANS FOR INTRODUCTION AND SUPPORT
/540543
0RODUCT ,INE &UNCTIONAL 2EQUIREMENTS 3PECIFICATION $OCUMENT 0RODUCT ,INE 0LAN )NITIAL &UNCTIONAL $OCUMENT 3PECIFICATION
0RODUCT ,INE #ONTENT $OCUMENT
81 Complex linear models
Most of models of the design process have three to seven steps. If they contain more steps, they’re typically organized into a tree with three to seven major steps. This may be another function of George Miller’s famous “Magic Number 7.” The next section includes some very detailed models.
82 Vanguard Group
The model on the following spread comes from the design team at the Vanguard Group. So far as I know, they have not published it.
83 Web development process after Vanguard Group (circa 1999)
-AJOR REVIEW POINT 4EAM MUST RECEIVE 3ENIOR -ANAGEMENT APPROVAL TO PROCEED
0(!3%3 0LANNING 2EQUIREMENTS #ONCEPTUAL $ESIGN !NALYSIS $ESIGN
#REATE "USINESS #OMPLETE )NITIAL #REATE 3ITE "EGIN #REATE #OMPLETE #REATE $ETAILED )DEA #ASE AND )NITIAL 5SER 2ESEARCH !RCHITECTURE AND &UNCTIONAL .AVIGATIONAL #ONCEPTUAL 7IREFRAMES 3COPE #ONCEPTUAL 2EQUIREMENTS $IAGRAMS 4ESTING $ESIGN
!#4)6)49 35--!29
#ONDUCT USER $EVELOP USER 2EFINE PROFILE (EAVY ITERATION OF "UILD ARCHITECTURE )DENTIFY AND PRIORITIZE #REATE hVISUALIZATIONv RESEARCH RESEARCH PLAN MAPPING TO SEGMENT REQUIREMENTS FROM CONTAINER KEY CONTENT OF REQUIREMENTS STRATEGY ARCHITECTURE AND RELATIONSHIP OUTLINE $EVELOP BUSINESS #REATE USER PROFILES DESIGN AND MENTAL MODELS )DENTIFY TOP TASKS FOR !UDIT PAGES TO CASE SUMMARY 2EFINE TASK ANALYSIS TESTING UNCOVER FUNCTIONAL "EGIN TASK ANALYSIS )DENTIFY DETAILED AND NON FUNCTIONAL #ONDUCT COMPETITIVE 2EFINE MENTAL MODEL CONTENT INVENTORY 6ALIDATE REQUIREMENTS REQUIREMENTS ANALYSIS "EGIN TO ESTABLISH AND ARCHITECTURE WITH MENTAL MODEL #REATE OUTLINE OF -AP DETAILED CONTENT USERS "EGIN TO REFINE $EFINE GOALS AND CONTAINERS AND THEIR TO ARCHITECTURE APPLY DESIGN OBJECTIVES RELATIONSHIPS 0REPARE APPROPRIATE STANDARDS #ONDUCT GAP ANALYSIS MATERIALS FOR TEST "EGIN TO hTHUMBNAILv HIGH LEVEL LOOK AND #ONDUCT TESTS FEEL #REATE RECOMMENDA 6ALIDATION OF CONCEPTS TIONS BASED ON WITH THE BUSINESS FINDINGS
/540543
"USINESS CASE #LIENT )NTERVIEWS 3ITE ARCHITECTURE 2EQUIREMENTS .AVIGATIONAL 0APER MOCK UPS 7IREFRAMES ITERATED 2EPORT OF FINDINGS DESIGN CONCEPTS DIAGRAMS 5SABILITY REPORT
6!,5% !$$ WITH LESSONS LEARNED
7EB TEAM 3EPARATE USER GOALS #ONTROL COMPLEXITY 'AIN BUSINESS BUY IN "ALANCE BUSINESS +EEP )MPORTANT TASKS 5SABILITY EXPERTISE %NSURE THAT DESIGN IS PARTICIPATION AT BUSINESS STRATEGY BEFORE ENTERING INTO OBJECTIVES AND USER WITHIN A FEW CLICKS ALLOWS FOR RAPID SCALEABLE AND FLEXIBLE BRAINSTORMING AND THEN RECONCILE 5NDERSTAND USER COSTLY DESIGN NEEDSEXPECTATIONS VALIDATION TO ALLOW FOR ONGOING STAGE AND DISCREPANCIES GOALS AND BEHAVIORS DEVELOPMENT CYCLE -AP ARCHITECTURE ADJUSTMENT OF MAINTENANCE DURING STRATEGY TO AVOID LOW USAGE !SSES DESIGN BACK TO BUSINESS ARCHITECTURE FORMULATION )NVOLVE THE RIGHT 2EDUCES COMPLEXITY STANDARDS AND STRATEGY AND USER REQUIREMENTS !LLOW BUSINESS TO SEE PEOPLE EARLY IN THE #OHESIVE TEAM TASKS LANGUAGE DETERMINE IF GOALS AND PARTICIPATE IN THE PLANNING PROCESS ENVIRONMENT CREATES METAPHORS ETC DIFFERENTIATION IS "USINESS ANALYSIS OF EVOLUTION OF THE SITE EFFICIENT INFORMED NECESSARY AND WHY #ONSIDER USAGE TEST RECOMMENDA OUTPUT AND RAPID #REATES CLARITY AROUND REPORTING TIONS #ONSIDER ERROR ITERATION TASKS FOCUSES THE 4RANSLATION OF CONDITIONS EFFORT COMPETITIVE ANALYSIS #LARIFY SCOPE AND *UDGEMENT IN TO CONCEPT FUNCTIONALITY APPLYING THE RIGHT !DDITIONAL DESIGN !SSISTS WITH BUSINESS USABILITY TECHNIQUES STRATEGY STANDARDS PRIORITIZATION REAL #ONSIDER CROSS OVER TO THE PROJECT ANALYSIS ESTATE EXPERIENCE
(IGH LEVEL TECHNOLOGY ASSESSMENT
84 -AJOR REVIEW POINT 4EAM MUST RECEIVE 3ENIOR -ANAGEMENT APPROVAL TO PROCEED
2EFINEMENT OF 5) $ESIGN "UILD -ONITOR )MPROVE
"UILD #REATE $ESIGN #OMPLETE 5SER #OMPLETE 5SER #OMPLETE $ELIVER 5) #ONTINUOUS 3TRATEGY %LEVATE 4ESTING OF $ESIGN )NTERFACE 4ESTING OF &INAL 3PECIFICATIONS )MPROVEMENT 7IREFRAMES 'UIDELINE 5SER )NTERFACE AND 2ELATED 4EST 3PECIFICATION $OCUMENTATION
0REPARE NEXT LEVEL OF !SSEMBLE THE DESIGN #REATE DETAILED #ONDUCT FINAL TESTING &INALIZE 5) 'ATHER DATA TASKS AND TEST STRATEGY AND DESIGN FOR ALL UNIQUE TO UNCOVER MAJOR SPECIFICATIONS MATERIALS DOCUMENT INSTANCES FLAWS PROTOTYPE OF UNIQUE 5NCOVER ISSUES AND INSTANCES DEFECTS #ONDUCT TEST 2EFINE AND APPLY SITE &OCUS TESTING ON SPECIFIC DESIGN UNIQUE INSTANCES $ELIVER AND REVIEW 5) 5SE $-!)# TO IDENTIFY 2EPORT USABILITY TEST GUIDELINES WITH THE DEVELOPMENT IMPROVEMENTS FINDINGS #REATE RECOMMENDA TEAM )DENTIFY KEY CONTENT TIONS BASED ON 7ORK WITH BUSINESS TO )NTERPRET FINDINGS AND PLACE FINDINGS SUBMIT 3#2S AND MAKE RECOMMENDA PROJECT REQUESTS TIONS 6ALIDATE DESIGN STRATEGY WITH THE &OLLOW 3$,# THROUGH BUSINESS TO ELEVATION
-ONITOR IMPROVEMENTS THROUGH DATA
5SABILITY REPORT $ESIGN STRATEGY h3KINNED PROTOTYPEv h3KINNED PROTOTYPEv 0ROTOTYPE $ATE TRACKING AN ITERATED DOCUMENTATION ANALYSIS 5SABILITY REPORT 6/# 0ARETOS 7EB 5SAGE 2EPORTS %RROR ,OGS %XIT 3URVEYS 7433 4RENDS .)#% CALLS
0REDICT USER INTEREST ,OOK AND FEEL OF THE (IGH DEGREE OF DESIGN &INAL CHECKPOINT WITH #ONTINUAL 4HOROUGH ATTENTION TO $ETAILED ANALYSIS OF ALL SITE IS BEING BUSINESS ITERATION USERS TO VALIDATE THE IMPROVEMENT OF INTEGRATION TEST DATA 0#% 6/# )NCORPORATING MULTIPLE ESTABLISHED AND EXPERIENCE DESIGN DOCUMENTATION TO 752 7)33 06#3 OPTIONS INTO TESTS TO VALIDATED WITH KEY #REATE A SITE THAT ARCHITECTURE CONTENT CREATE EFFICIENCIES 1UALITY AND CONTROL 4RACKER 2ESEARCH REDUCE COMPLEXITY FOR BUSINESS hHANGS TOGETHERv AND USABILITY BETWEEN DESIGN AND ASSESSMENT BY ETC THE USER STAKEHOLDERS DEVELOPMENT DESIGN TEAM IN THE #OVERING ALL &INALIZE TEMPLATE FOR INTEGRATION REGION 6/# ANALYSIS "USINESS ANALYSIS OF %VALUATION OF PAGE POSSIBILITIES THROUGH USAGE REPORTING TEST RECOMMENDA LOADS UNIQUE INSTANCES 0AGE PERFORMANCE 65% PROJECTS TIONS ANALYSIS AND -ANAGE BUSINESS TROUBLE SHOOTING 0RIORITIZATION OF )MPLEMENT ADHERE TO FEEDBACK BY AREA OF ENHANCEMENTS WITH CHANGE CONTROL EXPERTISE AVOID THE BUSINESS PROCESS DESIGN BECOMING THE FOCUS VERSUS CONTENT ,OOK FOR COMPATIBILITY ACROSS BROWSERS /3 AND DOWNLOADS ETC
85 Alan Cooper
Few people are good computer programmers and also good Cooper advocates fi ve signifi cant changes to conventional interaction designers. Alan Cooper is one. Cooper’s favorite methods of software development in his goal-directed de- topic is what’s wrong with the software that increasingly fi lls sign process: our lives and how it came to be so bad. He holds forth on the subject in two books, About Face: The Essentials of User 1) Design fi rst, program second. Interface Design (1995) and The Inmates Are Running the 2) Separate responsibility for design from responsibility Asylum: Why High-Tech Products Drive Us Crazy and How to for programming. Restore the Sanity (1999). 3) Hold designers responsible for product quality and user satisfaction. In summary, Cooper’s argument is as follows: In software, 4) Invent on specifi c user for your product—a persona. the cost of adding one more new feature is almost nothing; Give that user a name and an environment and derive no additional material or manufacturing costs restrain feature his or her goals. creep. The trouble is: Each additional feature makes the 5) Work in teams of two: designer and design communicator product more complicated to understand and more diffi cult to use. I developed the diagrams that follow based on a series of conversations with Cooper and members of his staff, includ- In the traditional software development process, many ing Dave Cronin, David Fore, Kim Goodwin, Jonathan Kor- people inside a company—and oftentimes customers as man, and Robert Reimann. The fi rst two were fi rst published well—ask for features. Thus, a list of features often becomes in the AIGA journal, Gain. The second two have not been the de facto product plan. Programmers make this approach published previously. worse by picking or negotiating their way through the list, often trading features for time. In such a process, Cooper points out, it’s hard to know when a product is complete.
86 Evolution of the software development process after Alan Cooper (2001)
In 1975, Cooper borrowed $10,000 from his dad and started a company with his high-school friend, Keith Parsons. They began writing and selling software for personal computers. The diagram below describes the evolution of the software development process from the beginning of the personal computer industry to the present, as Cooper saw it.
0ROGRAMMERS /RIGINALLY PROGRAMMERS DID IT ALL )N THE EARLY DAYS OF THE 0# SOFTWARE INDUSTRY SMART PROGRAMMERS DREAMED UP USEFUL SOFTWARE #ODE4EST 3HIP WROTE IT AND EVEN TESTED IT ON THEIR OWN !S THEIR BUSINESSES GREW THE BUSINESSES AND THE PROGRAMS BECAME MORE COMPLICATED
-ANAGERS BROUGHT ORDER -ANAGERS 0ROGRAMMERS )NEVITABLY PROFESSIONAL MANAGERS WERE BROUGHT IN 'OOD PRODUCT MANAGERS UNDERSTAND THE )NITIATE #ODE4EST 3HIP MARKET AND COMPETITORS 4HEY DEFINE SOFTWARE PRODUCTS BY CREATING REQUIREMENTS DOCUMENTS /FTEN HOWEVER REQUIREMENTS ARE LITTLE MORE THAN A LIST OF FEATURES AND MANAGERS FIND THEMSELVES HAVING TO GIVE UP FEATURES IN ORDER TO MEET SCHEDULES
4ESTING BECAME A SEPARATE STEP -ANAGERS 0ROGRAMMERS 1! !S THE INDUSTRY HAS MATURED TESTING HAS BECOME A SEPARATE DISCIPLINE AND A SEPARATE )NITIATE#ODE 4EST 3HIP STEP IN THE PROCESS 4ODAY ITS COMMON TO FIND TESTER FOR EVERY OR PROGRAMMERS 4HIS CHANGE ILLUSTRATES THAT THE PROGRAMMERS ROLE IS NOT FIXED BUT STILL EVOLVING
4ODAY COMMON PRACTICE IS TO CODE -ANAGERS 0ROGRAMMERS 1! AND DESIGN SIMULTANEOUSLY #ODE "UG 4EST )N THE MOVE FROM COMMAND LINE TO GRAPHICAL )NITIATE 3HIP USER INTERFACE DESIGNERS BECAME INVOLVED IN $ESIGN 5SER 4EST THE PROCESS THOUGH OFTEN ONLY AT THE END $ESIGNERS 5SABILITY &OLKS 4ODAY COMMON PRACTICE IS FOR SIMULTANEOUS CODING AND DESIGN FOLLOWED BY BUG AND USER TESTING AND THEN REVISION
#OOPER INSISTS THAT DESIGN -ANAGERS $ESIGNERS 0ROGRAMMERS 1! PRECEDE PROGRAMMING "UG 4EST )N #OOPERS GOAL DIRECTED APPROACH TO )NITIATE $ESIGN #ODE 3HIP SOFTWARE DEVELOPMENT ALL DECISIONS PROCEED 5SER 4EST FROM A FORMAL DEFINITION OF THE USER AND HIS OR 5SABILITY &OLKS HER GOALS $EFINITION OF THE USER AND USER GOALS IS THE RESPONSIBILITY OF THE DESIGNER THUS DESIGN PRECEDES PROGRAMMING
87 Goal-directed design process after Alan Cooper (2001)
PROVIDE INPUT TO 5SERS #OOPER PUTS USER GOALS AT THE CENTER OF THE SOFTWARE DESIGN PROCESS 4HAT PROCESS IS PART OF A SERIES OF OFFICE PRACTICES WHICH DEPEND ON THE TALENT AND SKILLS OF DESIGNERS -ANAGERS PROVIDE MANDATE TO $ESIGNERS AND ON THEIR APPLICATION OF PRINCIPLES AND 0RIMARY RESPONSIBILITY INSURE FINANCIAL SUCCESS PATTERNS THROUGHOUT THE PROCESS
4HIS DIAGRAM SHOWS THE PROCESS PROCEEDING IN STEPS FROM LEFT TO RIGHT )T LEAVES OUT FEED )NITIATE $ESIGN BACK LOOPS AND ITERATION WHICH ARE NECESSARY FOR PRODUCING GOOD WORK
2ESEARCH AND !NALYZE /PPORTUNITIES #ONSTRAINTS AND #ONTEXT FOCUS IN THE FIRST HALF CONTINUING THROUGHOUT 7HO WILL USE THE PRODUCT 7HAT PROBLEM WILL IT SOLVE FOR THEM
!CTIVITY $EFINE INTENT AND 2EVIEW WHAT EXISTS $ISCUSS VALUES !PPLY ETHNOGRAPHIC $EFINE TYPICAL $EDUCE WHAT CONSTRAINTS OF PROJECT EG DOCUMENTS ISSUES EXPECTATIONS RESEARCH TECHNIQUES USERS USERS WANT
LEAD TO 2ESULT 3COPE !UDIT )NTERVIEWS /BSERVATIONS 0ERSONAS 'OALS DESIRED OUTCOMES BUSINESS PLAN MANAGEMENT USE PATTERNS PRIMARY LIFE TIME CONSTRAINTS MARKETING PLAN DOMAIN EXPERTS SECONDARY END FINANCIAL CONSTRAINTS BRANDING STRATEGY CUSTOMERS POTENTIAL USERS SUPPLEMENTAL EXPERIENCE GENERAL PROCESS MARKET RESEARCH PARTNERS THEIR ACTIVITIES NEGATIVE MILESTONES PRODUCT PLAN SALES CHANNEL THEIR ENVIRONMENTS SERVED INDIRECTLY PERSONAL 3COPE MAY BE COMPETITORS 4HIS STEP LEADS TO THEIR INTERACTIONS PARTNER PRACTICAL LOOSE OR TIGHT RELATED TECHNOLOGY A PROJECT MANDATE THEIR OBJECTS TOOLS CUSTOMER CORPORATE AEIOU FRAMEWORK FROM ORGANIZATIONAL FALSE 2ICK 2OBINSON 3APIENT
!RTIFACT 0ROJECT "RIEF 3UMMARY 4APES 4APES .OTES .OTES )NSIGHTS 4RANSCRIPTS 4RANSCRIPTS 3UMMARY 3UMMARY )NSIGHTS )NSIGHTS
-EETINGS "RIEFING )NTERVIEWS #HALK TALK #HALK TALK WITH EARLY FINDINGS MANAGEMENT
$ESIGN /FFICE 0RACTICES $ESIGNER 4ALENT AND 3KILLS 4HE WAY THE OFFICE IS SET UP AND RUN n THE ENVIRONMENT ! DESIGNERS NATIVE ABILITIES AND BACKGROUND ALSO AFFECT THE SPOKEN AND UNSPOKEN RULES n AFFECT THE WORK THE WORK #OOPER LOOKS FOR PEOPLE WITH THESE SKILLS #OOPERS STAFF DESCRIBES SEVERAL KEY PRACTICES ANALYTIC EMPATHIC GOAL DIRECTED DESIGN PROCESS CONCEPTUAL INTERPERSONAL COLLABORATIVE ENVIRONMENT AND COMMON PURPOSE VISUAL BRAINSTORMING $$# TEAM STRUCTURE SEE SEPARATE DIAGRAM WRITTEN IMAGINATION EGOLESS DESIGN COMMUNICATIONS APPROPRIATENESS OF ASSIGNMENTS COMMITMENT TO EDUCATION COMMITMENT TO ENHANCE PROCESS ASSESSMENT AND SELF ASSESSMENT
88 PROVIDE FEEDBACK ON USABILITY TO 5SERS
PROVIDE BUG REPORTS TO
PROVIDE SPEC TO 0ROGRAMMERS PROVIDE CODE TO 1! CERTIFY PRODUCT FOR RELEASE 3OFTWARE DEVELOPMENT PROCESS INSURE CUSTOMER SATISFACTION INSURE PERFORMANCE INSURE RELIABILITY
#ODE 4EST 3HIP
4HE GOAL DIRECTED DESIGN PROCESS TAKES PLACE WITHIN A LARGER SOFTWARE DEVELOPMENT PROCESS 3YNTHESIZE AND 2EFINE &ORM -EANING AND "EHAVIOR ONGOING THROUGHOUT FOCUS IN THE SECOND HALF 7HAT IS IT (OW WILL IT BEHAVE FOR USERS
)MAGINE A SYSTEM TO 4ELL STORIES ABOUT $ERIVE COMPONENTS /RGANIZE THE 2EFINE DETAILS HELP USERS REACH GOALS USING THE SYSTEM BASED ON USERS COMPONENTS DESCRIBE MODELS
DRIVE #ONCEPT 3CENARIOS %LEMENTS &RAMEWORK 3PEC PROBLEM DEFINITION DAY IN THE LIFE INFORMATION OBJECTS OBJECT RELATIONSHIPS APPEARANCE SPARK VISION DEFINITION KEY PATH FUNCTIONAL OBJECTS CONCEPTUAL GROUPINGS LANGUAGE INFORM DESIGN IMPERATIVES ERROR CONTROL MECHANISMS PATTERNS FLOW BEHAVIOR MOTIVATE-AY REQUIRE CHANGES SET UP LOGIC NARRATIVE FLOW PRODUCT CHARACTER FILTER IN SCOPE NAVIGATION STRUCTURE PRODUCT STORY ORGANIZE PRIORITIZE INFLECT VALIDATE
&ORMAL $OCUMENT .OTES ,ISTS 3KETCHES &ORMAL $OCUMENT 0ROBLEM 3TATEMENT 3TORYBOARDS 3KETCHES &LOW $IAGRAMS $EMONSTRATION 6ISION 3TATEMENT $IAGRAMS 0ROTOTYPE (IGH LEVEL DATA MODELS
0RESENTATION #HALK TALK WITH 0RESENTATION PROGRAMMERS
4HROUGHOUT THE GOAL DIRECTED DESIGN PROCESS DESIGNERS APPLY OTHER PRACTICES THEIR TALENT AND SKILLS AS WELL AS PRINCIPLES AND PATTERNS $ESIGN 0RINCIPLES $ESIGN 0ATTERNS 0RINCIPLES GUIDE THE CHOICES DESIGNERS MAKE AS THEY $ESIGN PATTERNS ARE RECURRING FORMS OR STRUCTURES WHICH CREATE 0RINCIPLES APPLY AT ALL LEVELS OF DESIGN FROM BROAD DESIGNERS MAY RECOGNIZE OR APPLY n DURING ANALYSIS AND CONCEPT TO SMALL DETAIL &OR EXAMPLE ESPECIALLY DURING SYNTHESIS #HRISTOPHER !LEXANDER $O NO HARM (IPPOCRATES h! 0ATTERN ,ANGUAGE v PROVIDES EXAMPLES OF PATTERNS FOR -EET USER GOALS ARCHITECTURE #OOPER COLLECTS PATTERNS FOR SOFTWARE #REATE THE SIMPLEST COMPLETE SOLUTION /CKHAM &ULLER INTERACTION &OR EXAMPLE A COMMON PATTERN IS DIVIDING A #REATE VIABLE AND FEASIBLE SYSTEMS WINDOW INTO TWO PANES THE LEFT SMALLER PANE PROVIDES TOOLS OR CONTEXT AND THE RIGHT LARGER ONE PROVIDES A WORKING SPACE OR DETAILS
89 Idealized process of developing buildings after Alan Cooper (2004)
Since high school, architecture has fascinated Cooper. His building will be like (how it will “behave”). Based on the archi- view of how architecture should be practiced provides a tect’s plans, engineers determine how to make the building model for how he believes software development should be stand up. And fi nally, the builders execute the architect’s and practiced. Cooper organized the process of developing a engineer’s plans. Obviously, architects serve their clients and building into three domains: architecture, engineering, and consult with engineers and builders on what is possible and construction. In his view, architects determine what the practical.
CLIENTS DEMONSTRATE NEEDS ARTICULATE GOALS
ARE OBSERVED BY
ARCHITECTS DESIGN FORMS CREATING POTENTIAL USES FOR REPRESENTED IN PLANS
PROVIDE A BASIS FOR
ENGINEERS DESIGN STRUCTURES ENSURING STABILITY AND SAFETY FOR REPRESENTED IN PLANS
GUIDE
BUILDERS BUILD BUILDINGS FOR
ARE ASSESSED BY
INSPECTORS MAY ISSUE PERMITS WHICH ALLOW OCCUPANCY BY MAY REFUSE ACCORDING TO BUILDING CODES
WHICH REQUIRES CORRECTIONS FROM
90 Idealized process of developing software After Alan Cooper (2004)
Following his ideal model of architecture, Cooper advocated fi nally to consult with programmers to answer questions as organizing the process of developing software into three they program. domains: interaction design, engineering, and programming. Interaction designers determine what the software will be like Cooper distinguishes engineers from programmers. Ac- (how it will “behave”). Based on the interaction designer’s cording to him, engineers like to fi gure out how to solve plans, engineers determine how to make the software work problems. They like to create and don’t want to be told what by writing many very short test programs—but no fi nal code. to do. Programmers, he suggested, don’t like ambiguity. And fi nally, the programmers write real code to execute They like to code and simply want to know what the code the interaction designer’s and engineer’s plans. Here too, is suppose to do. Cooper warned, putting an engineer in a Cooper acknowledges the need for feedback—for interac- programming job or a programmer in an engineering job is a tion designers to observe users to understand their goals, to recipe for unhappiness. consult with engineers to understand what’s possible, and
USERS DEMONSTRATE NEEDS ARTICULATE GOALS
ARE OBSERVED BY
INTERACTION DESIGNERS DESIGN FORMS CREATING POTENTIAL USES FOR BEHAVIORS REPRESENTED IN PLANS
PROVIDE A BASIS FOR
ENGINEERS DESIGN PROGRAM STRUCTURES VERIFIED BY SMALL PROTOTYPES REPRESENTED IN SPECIFICATIONS
WHICH ARE IMPLEMENTED BY
PROGRAMMERS WRITE CODE WHICH IS USED BY
IS ASSESSED BY
TESTERS FIND BUGS
WHICH REQUIRE CORRECTIONS FROM
91 Morris Asimow
Asimow defi nes morphology of design as “the study of the In Introduction to Design, Asimow devotes more than 50 chronological structure of design projects.” He notes, “Each pages to describing engineering design and the design design-project has an individual history which is peculiarly its process. He defi nes engineering design as “a purposeful own. Nonetheless, as a project is initiated and developed, a activity directed toward the goal of fulfi lling human needs, sequence of events unfolds in a chronological order forming particularly those which can be met by the technological fac- a pattern which, by and large, is common to all projects.” He tors of our culture. . . . As a profession, Engineering is largely continues, “Design is a progression from the abstract to the concerned with design. What distinguishes the objects of concrete. (This gives a vertical structure to a design project.) engineering design from those of other design activities is . . . Design is [also] an iterative problem-solving process. the extent to which technological factors must contribute to (This gives a horizontal structure to each design step.)” their achievement.”
Asimow defi nes the phases of a project (vertical) as Asimow, like Alexander, Jones, and Doblin, distinguishes - Feasibility study craft-based design, “design by evolution,” from “design by - Preliminary design innovation.” He notes, “Now more frequently than ever in the - Detailed design past, products are designed de novo,” and suggests this cre- - Planning for production ates greater risk and complexity and thus implies the need - Planning for distribution for new design tools (the subject of his book.) - Planning for consumption - Planning for retirement According to Rowe (1987), Asimow was “an industrial en- gineer prominent in the 1950s and 1960s.” Two years after He likened the design process (horizontal) to “the general Asimow fi rst published his model, Tomas Maldonado and problem solving process,” describing these steps” Gui Bonsiepe introduced it to the design and architecture - analysis community, including it in their seminal article “Science and - synthesis Design” published in the journal, Ulm 10/11 (1964). - evaluation - decision - optimization - revision - implementation
92 Morphology of design (1 of 3) after Morris Asimow (1962)
0HASE &EASIBILITY 3TUDY
-ARKET .EEDS !NALYSIS 6ALID 3TEP )NFO
$ESIRED /UTPUTS
4ECH 3TEP 2ELEVANT 3YSTEM )DENTIFICATION )NFO $ESIGN 0ROBLEM
%NGR 3TATEMENT OF 0ROBLEM
#REATIVE $ESIGN #ONCEPTS 0LAUSIBLE 3TEP 4ALENT 3YNTHESIS
!LTERNATIVE 3OLUTIONS
4ECH 3TEP 0OSSIBLE 0HYSICAL !NALYSIS +NOWL 0HYSICAL 2EALIZABILITY
2EALIZABLE 3OLUTIONS
%CON &ACTORS %CONOMIC !NALYSIS 0AY 3TEP %CONOMIC 7ORTH
7ORTHWHILE 3OLUTIONS
3TEP -ONEY &INANCIAL !NALYSIS &INANCE &INANCIAL &EASIBILITY &ACTORS
3ET OF 5SEFUL 3OLUTIONS
3YMBOLOGY
)NFO 0ROCESS 3OURCE
/UTCOME $ECISION
)TERATIVE OR FEEDBACK LOOP
93 Morphology of design (2 of 3) after Morris Asimow (1962)
0HASE 0RELIMINARY $ESIGN
%XP 3ELECTION OF "EST 3TEP 4ECHN $ESIGN #ONCEPT
4ENTATIVE 3ELECTION
-ATHEMATICAL %NGR 3TEP 6ALID !RCHETYPES 3CIENCE
!NALYTICAL &ORMULATION
-ATH !NALYSIS 3ENSITIVITY !NALYSIS 7HICH 3TEP
3ENSITIVE 0ARAMETERS
4ECH 3TEP &IT #OMPATIBILITY !NALYSIS )NFO
!DJUSTED 0ARAMETERS
-ATH 4EST 3TABILITY !NALYSIS 3TABLE 3TEP
!DJUSTED &OR 3TABILITY
3TEP "EST /PTIMIZATION -ATH
/PTIMUM
4RENDS 0ROJECTION )NTO &UTURE 4IME 3TEP
"EHAVIOR /VER 4IME
-ATH 3TEP 0ERFORM 0REDICTION OF "EHAVIOR 4EST
%XPECTED 0ERFORMANCE
,AB 4ECHNIC 4ESTING 7ORK 3TEP
4EST 2ESULTS
%XPER 3TEP "ETTER 3IMPLIFICATION IENCE
!CCEPTED 0ROPOSAL 94 Morphology of design (2 of 3) after Morris Asimow (1962)
0HASE $ETAILED $ESIGN
%XPER 0REPARATION &OR $ESIGN 6ALID 3TEP IENCE
"UDGET /RGANIZATION
$ESCRIPTION 4ECHN 3TEP 'OOD 3UBSYSTEMS +NOWL
3UBSYSTEM #ONCEPTS
4ECHN $ESCRIPTION 'OOD 3TEP +NOWL #OMPONENTS
#OMPONENT #ONCEPTS
4ECHN 3TEP 'OOD $ESCRIPTION OF 0ARTS +NOWL
3PECIFICATIONS AND $RAWINGS
4ECHN !SSEMBLY $RAWINGS &IT 3TEP %XPER
#OMPLETE $ESCRIPTIONS
%XPERIMENTAL 3TEP 0RODUCE 3HOP IBLE #ONSTRUCTION
0ROTOTYPE
$OES ,AB 0RODUCT 4EST 0ROGRAM )T 7ORK 3TEP
4EST $ATA
-ATH 3TEP 'OOD !NALYSIS 0REDICTION !NALYSIS
$ETECTED &LAWS
4ECHN +NOWL 2EDESIGN "ETTER 3TEP
)MPROVED $ESIGN
95 Bruce Archer
Cross (1984) notes, “One of the fi rst tasks attempted by the Archer’s statements about the design process contradict design methodologists was the development of new, sys- Rowe’s critique, “The fact is that being systematic is not nec- tematic design procedures.” He calls out four authors as es- essarily synonymous with being automated.” Archer contin- pecially important: Jones, Alexander, Archer, and Rittel. (For ues, “When all has been said and done about defi ning design more on Jones, see pages 56-59; for more on Alexander, see problems and analyzing design data, there still remains the page 18.) This section presents three models from Archer. real crux of the act of designing—the creative leap from (Rittel came to see design as a process of argumentation pondering the question to fi nding a solution. . . . If we accept aimed at coming to agreement on goals; as far as I know, he that value judgments cannot be the same for all people, for presented no staged or procedural models of design.) all places or all time, then it follows that neither the designer nor his client (nor, eventually, the user) can abdicate the re- Archer taught at both the Royal College of Art (RCA) in sponsibility for setting up his own standards. Similarly, there London and the Hochschule für Gestaltung in Ulm (HfG Ulm). is no escape for the designer from the task of getting his own Rowe (1987) notes that at Ulm, “speculation moved beyond creative ideas. After all, if the solution to a problem arises description and explanation of design behavior and into the automatically and inevitably from the interaction of the data, realm of idealization. Not only was the possibility of a ‘scien- then the problem is not, by defi nition, a design problem.” tifi c’ and totally objective approach toward design seriously entertained, it became a goal in itself. A confi dent sense of rational determinism prevailed; the whole process of de- sign, it was believed, could be clearly and explicitly stated, relevant data gathered, parameters established, and an ideal artifact produced.”
96 Biological sequence of problem solving after Bruce Archer (1963-1964)
Archer notes the similarity of biological response mecha- “A further line of thinking which does not quite fall into this nisms and problem solving in computer programming and pattern but which has contributed to the development of design. And he explicitly links these processes to cybernet- systematic methods for designers is the ‘heuristic’. an ics. ancient philosophical study of the method of intellectual discovery which has been revitalized recently by Professor “The study of control mechanisms of living organisms is [George] Polya of Stanford University, USA.” called cybernetics. In recent times, designers of highly complicated control systems for machine tools, aeroplanes, “The method for solving design problems set out in this ar- rockets and remote controlled instruments have turned to ticle owes something to both the heuristic and the cybernetic cybernetics for inspiration.” approaches.” (See Polya’s model on page 36. See models from cybernetics on pages 117-118.)
$ISCERN @SOMETHING WRONG (EIGHTEN ALERTNESS AND LOCATE THE AREA OF DISTURBANCE "RING APPROPRIATE SENSE ORGANS TO BEAR %VALUATE EVIDENCE AND COMPARE WITH PREVIOUS EXPERIENCES 0OSTULATE A POSSIBLE CAUSE FOR THE DISTURBANCE 2ECALL EXPERIENCE WITH SIMILAR ANDOR ANALOGOUS CAUSES 0REDICT CONSEQUENCE OF SUGGESTED CAUSE &ORMULATE COURSES OF ACTION POSSIBLE IN RESPONSE TO SUCH A CAUSE 2ECALL EXPERIENCE WITH SIMILAR ANDOR ANALOGOUS COURSE OF ACTION 0REDICT CONSEQUENCES OF EACH SUGGESTED COURSE OF ACTION 3ELECT COURSE OF ACTION TO BE FOLLOWED !CT $ISCERN EFFECT OF ACTION 2ECALL EXPERIENCE WITH SIMILAR ANDOR ANALOGOUS EFFECTS 2EPEAT FROM UNTIL EQUILIBRIUM IS RESTORED
97 Basic design procedure after Bruce Archer (1963-1964)
This diagram was reprinted in the journal Ulm (1964) and He continues, “The practice of design is thus a very compli- several other places, e.g., Cross (1984, 2000) and Rowe cated business, involving contrasting skills and a wide fi eld (1987). Archer proposed this model as representative of an of disciplines. It has always required an odd kind of hybrid to emerging “common ground” within the “science of design carry it out successfully. The more sophisticated the de- method” even while acknowledging continuing “differences”. mands of function and marketing become, the harder the job of the designer will get. Already it has become too compli- Regarding the procedure, he points out, “In practice, the cated for the designer to be able to hold all the factors in his stages are overlapping and often confused, with frequent mind at once.” returns to early stages when diffi culties are encountered and obscurities found.”
4RAINING
!NALYTICAL 0HASE "RIEF 0ROGRAMMING %XPERIENCE /BSERVATION -EASUREMENT )NDUCTIVE 2EASONING $ATA #OLLECTION
!NALYSIS
#REATIVE 0HASE 3YNTHESIS %VALUATION *UDGMENT $EDUCTIVE 2EASONING $EVELOPMENT
%XECUTIVE 0HASE 3OLUTION #OMMUNICATION $ESCRIPTION 4RANSLATION 4RANSMISSION
98 #HECK ,IST FOR 0RODUCT $ESIGNERS 0HASE
0RELIMINARIES &ORWARD 3UMMARY 4HE CHECK LIST WHICH ACCOMPANIED THE ORIGINAL SERIES OF ARTICLES IN 2ECEIVE %NQUIRY $ESIGN WAS REGARDED BY THE AUTHOR AS THE EMBODIMENT OF A %VALUATE %NQUIRY HYPOTHESIS ON THE STRUCTURE OF THE DESIGN ACT 3INCE THIS WAS %STIMATE /FFICE 7ORK ,OAD PUBLISHED FURTHER FUNDAMENTAL STUDY HAS BEEN UNDERTAKEN 0REPARE 0RELIMINARY 2ESPONSE
4HE FOLLOWING CHECK LIST IS THUS PRESENTED AS A SECOND HYPOTHESIS WHICH THE AUTHOR RECOGNIZES AS STILL NAIVE IN PLACES )T IS NOT 0HASE n 2ECEIVE BRIEF ANALYZE PROBLEM PREPARE DETAILED PROGRAMME AND ESTIMATE INTENDED TO BE READ AS A NARRATIVE .EVERTHELESS STUDY OF THE SUMMARY BELOW MIGHT BE USEFUL IN PRESENTING AN OVERALL PICTURE OF "RIEFING DESIGN PROCEDURE 4HE REMAINDER OF THE CHECK LIST IS OFFERED AS A DESIGN TOOL CALCULATED TO BE USEFUL IN THE CONTROL OF MOST NORMAL 2ECEIVE )NSTRUCTIONS PRODUCT DESIGN PROJECTS $EFINE 'OALS $EFINE #ONSTRAINTS (OW TO USE CHECK LIST AND ARROW DIAGRAMS 4HE CHECK LIST HAS BEEN SET OUT IN THE FORM OF A LIST OF ACTIVITIES AND EVENTS ACCORDING TO THE CONVENTIONS OF NETWORK ANALYSIS 0ROGRAMMING
)T IS SUGGESTED THAT THE DIAGRAM APPROPRIATE TO THE PHASE WHICH HAS %STABLISH #RUCIAL )SSUES BEEN REACHED IN THE DESIGN PROJECT IN QUESTION SHOULD BE MOUNTED 0ROPOSE ! #OURSE /F !CTION ON THE WALL ADJACENT TO THE DESIGNERgS DRAWING BOARD !S THE WORK PROGRESSES THE DESIGNER SHOULD IDENTIFY EVENTS IN THE CHECK LIST AS THEY TAKE PLACE AND TICK THEM OFF ON THE DIAGRAM 4HE LINKS IN THE DIAGRAM SHOW WHAT MUST BE DONE NEXT 4ARGET DATES ANDOR 0HASE n #OLLECT DATA PREPARE PERFORMANCE OR DESIGN SPECIFICATION REAPPRAISE PROPOSED PROGRAMME AND ESTIMATE ESTIMATED WORKING HOURS CAN BE ADDED WHERE APPROPRIATE $ATA #OLLECTION
2ECEIVE )NSTRUCTIONS #OLLECT 2EADILY !VAILABLE )NFO #LASSIFY !ND 3TORE $ATA
!NALYSIS
)DENTIFY 3UB PROBLEMS !NALYZE 3UB PROBLEMS !BOUT %NDS 0REPARE 0ERFORMANCE 3PECIFICATION 2EAPPRAISE 0ROGRAM !ND %STIMATE
0HASE n 0REPARE OUTLINE DESIGN PROPOSALS
3YNTHESIS
2ECEIVE )NSTRUCTIONS 2ESOLVE 2EMAINING 0ROBLEMS !BOUT %NDS 0OSTULATE -EANS &OR 2ECONCILING $IVERGENT $ESIDERATA )N 0ERFORMANCE 3PECIFICATION $EVELOP 3OLUTIONS )N 0RINCIPLE TO 0ROBLEMS !BOUT -EANS !RISING &ROM 0ERFORMANCE 3PECIFICATION 0OSTULATE /UTLINE /VERALL 3OLUTIONS
0HASE n $EVELOP PROTOTYPE DESIGNS
$EVELOPMENT
2ECEIVE )NSTRUCTIONS $EFINE $ESIGN )DEA %RECT ! +EY -ODEL $EVELOP 3UB PROBLEM -UTUAL 3OLUTION $EVELOP /VERALL 3OLUTIONS
0HASE n 0REPARE AND EXECUTE VALIDATION STUDIES
$EVELOPMENT #ONTINUED
6ALIDATE (YPOTHESES
0HASE n 0REPARE MANUFACTURING DOCUMENTATION
#OMMUNICATION
$EFINE #OMMUNICATION .EEDS 3ELECT #OMMUNICATION -EDIUM 0REPARE #OMMUNICATION
7INDING 5P
7IND 5P 0ROJECT #LOSE 2ECORDS
99 %XPLANATION )N THE DIAGRAMS TIME FLOWS FROM LEFT TO RIGHT ACROSS THE PAGE EACH 0HASE ARROW REPRESENTS AN ON GOING ACTIVITY WHICH TAKES A GREATER OR LESSER AMOUNT OF TIME (OWEVER THERE IS NOT ATTEMPT TO MAKE THE LENGTH OF 0RELIMINARIES THE ARROW PROPORTIONAL TO THE TIME TAKEN BY THE ACTIVITY 4HE CIRCLES AT EACH END OF THE ARROW REPRESENT THE EVENTS WHICH OPEN AND CLOSE AN 2ECEIVE %NQUIRY %VALUATE %NQUIRY %STIMATE /FFICE 0REPARE 0RELIMINARY 2ESPONSE ACTIVITY %VENTS OCCUR AT AN INSTANT IN TIME RATHER THAN OVER A PERIOD 7ORK ,OAD OF TIME 3OMETIMES MORE THAN ONE ACTIVITY IS REQUIRED TO COMPLETE AN EVENT 3OMETIMES AN EVENT PERMITS MORE THAN ONE ACTIVITY TO COMMENCE %VENTS WITH THE SUFFIX N MUST BE REPEATED A NUMBER OF TIMES FOR DIFFERENT SUB PROBLEMS
4HE CONVENTIONS DESCRIBED ARE COMMON TO VARIOUS FORMS OF NETWORK ANALYSIS FOR EXAMPLE CRITICAL PATH PLANNING AND 0%24
+EY
%VENT
2EPEATED %VENT N
!CTIVITY
#ARRY &ORWARD
2EPEAT )F .ECESSARY &ROM %VENT )NDICATED
7AITING 4IME
)TEM !CTIVITY !CTIVITY .O %VENT
0RELIMINARIES
2ECEIVE %NQUIRY %NQUIRY 2ECEIVED 3END !CKNOWLEDGMENT !CKNOWLEDGMENT $ISPATCHED /PEN 0ROJECT &ILE 0ROJECT &ILE !ND 0ROGRESS -ACHINERY 2EADY #OMMENCE #HART &OR 2ECORDING 0ROGRESS
%VALUATE %NQUIRY &OR %XAMPLE 2EPORT /N %VALUATION /F %NQUIRY 2EADY )DENTIFY !UTHORITY 4O 7HOM !NSWERABLE )DENTIFY 4YPE /F 4ASK )DENTIFY #LASS OF 0RODUCT $EFINE &ORM /F 3UBMISSION 2EQUIRED $EFINE !NY &ACILITY /R &REE 3TRUCTURE /FFERED $EFINE !NY 0ROGRAM ,IMITATIONS )MPOSED
%STIMATE /FFICE 7ORK ,OAD 3URVEY /F /FFICE 7ORKLOAD 2EADY 3URVEY %XISTING !ND 0ROJECTED 0ROGRAMMED %STIMATE /F -ANPOWER !VAILABILITY 2EADY %STIMATE -ANPOWER !VAILABILITY
0REPARE 0RELIMINARY 2ESPONSE "REAK $OWN 4ASK $ESCRIBED 5NDER )NTO !N /UTLINE 0ROGRAM /UTLINE 0ROJECT 0ROGRAM 2EADY -ATCH /UTLINE 0ROGRAM 7ITH -ANPOWER !VAILABILITY %STIMATE 3ET /UT 5NDER 0REPARE 0RELIMINARY %STIMATE /F #OSTS &ORMULATE ! $RAFT 0ROPOSAL $RAFT 0ROPOSAL !ND %STIMATE 2EADY #HECK $RAFT 0ROPOSAL %STIMATE $RAFT 0ROPOSAL !ND %STIMATE !PPROVED )F .ECESSARY 2EITERATE &ROM 5NTIL ! 3ATISFACTORY 0ROPOSAL )S $RAFTED 0REPARE !ND $ISPATCH &AIR #OPY /F 0ROPOSAL !ND %STIMATE 0ROPOSAL !ND %STIMATE $ISPATCHED "RING &ILE !ND 0ROGRESS -ACHINERY 5P TO DATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
2EITERATE 3ECTION 5NTIL !GREEMENT )S !CHIEVED /N ! #OMMISSION 4O #ARRY /UT 0HASE 2ECEIVE "RIEF !NALYZE 0ROBLEM 0REPARE $ETAILED 0ROGRAM !ND %STIMATE /R 5NTIL 0ROJECT )S !BANDONED
100 0HASE
"RIEFING 0ROGRAMMING
2ECEIVE )NSTRUCTIONS $EFINE 'OALS$EFINE %STABLISH #RUCIAL )SSUES 0ROPOSE ! #OURSE /F !CTION #ONSTRAINTS
N
N
)TEM !CTIVITY !CTIVITY .O %VENT "RIEFING
2ECEIVE )NSTRUCTIONS #OMMISSION 2ECEIVED 4O %XECUTE 0HASE 3END !CKNOWLEDGMENT !CKNOWLEDGMENT $ISPATCHED "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILE !ND 0ROGRESS -ACHINERY 5P 4O $ATE -AKE !RRANGEMENTS &OR &ORMAL "RIEFING !RRANGEMENTS #OMPLETE &OR &ORMAL "RIEFING
$EFINE 'OALS &OR %XAMPLE $EFINITION /F 'OALS #OMPLETE $EFINE #LIENTgS #ORPORATE 0OLICY 4RADING 0OLICY 0ROJECT !IMS 0ROBLEM !IMS )DENTIFY 2EASONS &OR %XAMINING 0ROBLEM .OW $EFINE $ESIGN 'OALS
$EFINE #ONSTRAINTS &OR %XAMPLE )DENTIFY !NY .ATIONAL #ONSTRAINTS !NY 4RADE #ONSTRAINTS !NY -ANDATORY #OMPANY #ONSTRAINTS $EFINITION /F #ONSTRAINTS #OMPLETE !NY #ONTRACTUAL #ONSTRAINTS "UDGETARY #ONSTRAINTS -ARKETING #ONSTRAINTS -ANUFACTURING #ONSTRAINTS !NY /THER #ONSTRAINTS
0ROGRAMMING
%STABLISH #RUCIAL )SSUES !NALYZE 'OALS 2ECORDED 5NDER !ND $EFINE #RITERIA &OR -EASURING 3UCCESS #RITERIA &OR -EASURING 3UCCESS )DENTIFIED !NALYZE #ONSTRAINTS )DENTIFIED 5NDER !ND $EFINE &IELD !VAILABLE &OR -ANEUVER &IELD &OR -ANEUVER $EFINED )DENTIFY #RUCIAL )SSUES #RUCIAL )SSUES )DENTIFIED
0ROPOSE ! #OURSE /F !CTION 2EVIEW %XPERIENCE /F !NALOGOUS 0ROBLEMS 2EVIEW /F %XPERIENCE 7ITH !NALOGOUS 0ROBLEMS #OMPLETE #OLLECT #ASE (ISTORIES /F 3IMILAR 0ROBLEMS (ANDLED %LSEWHERE #OLLECTION /F #ASE (ISTORIES 2EADY ,IST #OURSES /F !CTION !VAILABLE !VAILABLE #OURSES /F !CTION ,ISTED 3ELECT ! 0ROMISING #OURSE /F !CTION ! 0ROMISING #OURSE /F !CTION 3ELECTED 4EST 3ELECTED #OURSE /F !CTION ! 0ILOT 3TUDY 4EST /F 3ELECTED #OURSE /F !CTION #OMPLETED )N 4HE ,IGHT /F %XPERIENCE 7ITH !NALOGOUS 0ROBLEMS !PPRAISE 0ROBABLE !DEQUACY /F !PPRAISAL /F 0ROBABLE !DEQUACY #OMPLETE #OURSE /F !CTION 3ELECTED )F .ECESSARY 2EITERATE &ROM 5NTIL ! 3UFFICIENTLY !SSURING #OURSE /F !CTION )S 3ELECTED 2EAPPRAISE /FFICE 7ORKLOAD !ND 0ROJECT &ACILITIES 2EAPPRAISAL /F /FFICE 7ORK ,OAD !ND 0ROJECT &ACILITIES #OMPLETE 2EAPPRAISE 0ROGRAM !ND 4IMETABLE 2EAPPRAISAL /F 0ROJECT 0ROGRAM !ND 4IMETABLE #OMPLETE &ORMULATE $RAFT 2EVISE 0ROPOSAL !ND %STIMATE 7ITH 3PECIAL 2EPORTS /N !ND )F $RAFT 2EVISED 0ROPOSAL !ND %STIMATE 2EADY .ECESSARY
101 0HASE #ONTINUED 0HASE
0ROGRAMMING #ONTINUED $ATA #OLLECTION !NALYSIS
0ROPOSE ! #OURSE /F !CTION #ONTINUED 2ECEIVE )NSTRUCTIONS #OLLECT 2EADILY !VAILABLE )NFO #LASSIFY !ND 3TORE $ATA )DENTIFY 3UB 0ROBLEMS
N
)TEM !CTIVITY !CTIVITY .O %VENT #HECK $RAFT 0ROPOSAL !ND %STIMATE $RAFT 2EVISED 0ROPOSAL !ND %STIMATE !PPROVED )F .ECESSARY 2EITERATE &ROM 5NTIL ! 3ATISFACTORY 0ROPOSAL )S $RAFTED 0REPARE !ND $ISPATCH &AIR #OPY /F 0ROPOSAL !ND %STIMATE 2EVISED 0ROPOSAL !ND %STIMATE $ISPATCHED "RING &ILE !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE 2EITERATE 3ECTIONS !ND 5NTIL !GREEMENT )S 2EACHED 4O #ARRY /UT 0HASE #OLLECT $ATA 0REPARE 0ERFORMANCE 3PECIFICATION 2EAPPRAISE 0ROPOSED 0ROGRAM !ND %STIMATE /R 5NTIL 0ROJECT )S !BANDONED
$ATA #OLLECTION
2ECEIVE )NSTRUCTIONS #OMMISSION 2ECEIVED TO %XECUTE 0HASE 3END !CKNOWLEDGMENT !CKNOWLEDGMENT $ISPATCHED "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
#OLLECT 2EADILY !VAILABLE )NFORMATION &OR %XAMPLE /N !VAILABLE )NFORMATION 2EADY %NVIRONMENTAL !T 0OINT /F 5SE )DENTITY /F 5SERS 5SER %RGONOMICS 5SER -OTIVATION 0RODUCT &UNCTION 0RODUCT -ECHANICS 0RODUCT &INISH 0RODUCT !ESTHETICS -ARKET %NVIRONMENT #OMPETITIVE 0RODUCTS 0RODUCT !RCHETYPE "RAND 0REDECESSORS -AKERgS (OUSE 3TYLE 2ULING -ARKET 0RICES %CONOMIC 1UANTITIES 0RODUCT &ACILITIES ,IMITING $IMENSIONS -ATERIALS #OLLECT /THER 2EADILY !VAILABLE )NFORMATION
#LASSIFY !ND 3TORE $ATA ,IST )NFORMATION 4OPICS (ANDLED ,IST /F )NFORMATION 2EADY 2ATIONALIZE 4OPIC (EADINGS $ESIGN !N )NFORMATION #LASSIFICATION 3YSTEM #LASSIFY !LL )NFORMATION (ELD 3HELVE 4HE )NFORMATION 'ATHERED !VAILABLE )NFORMATION #LASSIFIED !ND 3HELVED
!NALYSIS
)DENTIFY 3UB PROBLEMS ,IST !LL 4HE &ACTORS )N 4HE /VERALL 0ROBLEM ,IST /F &ACTORS 2EADY 0AIR )NTERDEPENDENT &ACTORS 3O !S 4O &ORM !LL -ATTERS )NTO 3UB 0ROBLEMS )NTERDEPENDENCE -ATRIX 2EADY ,IST !LL 4HE 3UB PROBLEMS 4HUS )DENTIFIED ,IST /F 3UB PROBLEMS 2EADY )DENTIFY 4HE !PPARENT 3EQUENCE /F $EPENDENCE /F 3UB PROBLEMS 5PON /NE !NOTHER 3UB 0ROBLEM .ETWORK 2EADY
102 0HASE #ONTINUED
!NALYSIS #ONTINUED
!NALYZE 3UB PROBLEMS !BOUT %NDS 0REPARE 0ERFORMANCE 3PECIFICATION
N
N N
N N N N N
N N N
)TEM !CTIVITY !CTIVITY .O %VENT
$ISTINGUISH 0ROBLEMS !BOUT -EANS &ROM ,IST OF 0ROBLEMS !BOUT -EANS 2EADY 0ROBLEMS !BOUT %NDS ,IST /F 0ROBLEMS !BOUT %NDS 2EADY 2ESOLVE 0ROBLEMS !BOUT %NDS !S )NDICATED )N 3ECTIONS !ND
!NALYZE 3UB PROBLEMS !BOUT %NDS 3ELECT ! 0ROBLEM !BOUT %NDS &ROM 4HE .ETWORK )DENTIFIED 5NDER ,IST 4HE &ACTORS )N 4HIS 3UB PROBLEM ,IST /F &ACTORS )N 3UB PROBLEM 2EADY )DENTIFY 4HE 'OAL 4O "E !CHIEVED 'OALS !ND #ONDITIONS )DENTIFIED %STABLISH 4HE #ONNECTION "ETWEEN 4HE &ACTORS !ND 4HE 'OAL #ONNECTION "ETWEEN &ACTORS !ND 'OALS /R )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA 6ALUES -AY "E 6OLUNTARILY &IXED #ONDITIONS %STABLISHED "Y 4HE $ESIGNER 6OLUNTARILY %VALUABLE &ACTORS )DENTIFIED )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA 6ALUES !RE &IXED "Y %XTERNAL )NFLUENCES %XTERNALLY )NFLUENCED &ACTORS )DENTIFIED )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA !RE $EPENDENT 6ARIABLES &OR %XAMPLE 7HERE $EPENDENTLY 6ARIABLE &ACTORS )DENTIFIED 4HE $ATA !RE 4HE 3OLUTIONS 4O /THER 3UB PROBLEMS )F .ECESSARY 2EVISE .ETWORK )N 3O 4HAT 0ROBLEMS 7HICH 0ROVIDE $ATA &OR /THER 2EVISED .ETWORK 2EADY 0ROBLEMS !RE $EALT 7ITH )N 4HE 2IGHT /RDER /R 3ELECT !NOTHER 0ROBLEM !T #OLLECT .ECESSARY $ATA %ITHER %XTRACT $ATA &ROM 2ECORD 3YSTEM /R !DD &RESH $ATA .ECESSARY $ATA 2EADY 7HERE 3UFFICIENT 0RECISE $ATA )S !VAILABLE $ELINEATE -AXIMUM &IELD /F &EASIBLE 3OLUTIONS 7HERE 3UFFICIENT 0RECISE $ATA )S .OT !VAILABLE 0OSTULATE 3IMPLIFYING 3IMPLIFYING !SSUMPTIONS 0OSTULATED !SSUMPTIONS "Y 0LAUSIBLE 2EASONING !ND 4HEN $ELINEATE ! &IELD /F &IELD /F &EASIBLE 3OLUTIONS $ELINEATED &EASIBLE 3OLUTIONS 2EFERRING 4O )DENTIFY 4HE :ONE 7HERE 3ATISFACTION /F 'OAL )S /PTIMUM /PTIMAL 3OLUTION )DENTIFIED 2EEXAMINE 3ECTION !ND -ODIFY 0ROBLEM .ETWORK !S .ECESSARY 2EITERATE 3ECTION /F %ACH 0ROBLEM !BOUT %NDS )N 4HE .ETWORK !LL 0ROBLEMS !BOUT %NDS 2ESOLVED
0REPARE 0ERFORMANCE 3PECIFICATION 4AKING %VERY #OMBINATION /F 0AIRS /F 3UB PROBLEMS !BOUT %NDS )DENTIFY 7HICH )N %ACH 0AIR 0RIORITIES )DENTIFIED 2ANKING -ATRIX -UST 4AKE 0RECEDENCE )F 4HEIR /PTIMUM 3OLUTIONS !RE )NCOMPATIBLE 2ANK 4HE #OMPLETE ,IST /F 3UB PROBLEMS )N /RDER /F 0RECEDENCE 2ANKED ,IST /F 0ROBLEMS !BOUT %NDS 2EADY )DENTIFY 4HOSE 0AIRS 7HERE 4HE /PTIMUM 3OLUTIONS !RE )N &ACT -UTUALLY #OMPATIBLE 2EFERRING 0ROBLEMS 7ITH #OMPATIBLE /PTIMAL 3OLUTIONS )DENTIFIED 4O &OR %ACH 3UB PROBLEM )DENTIFY 4HOSE 0ARIS 7HERE 4HE /PTIMUM 3OLUTION /F /NE )S #OMPATIBLE 7ITH &EASIBLE "UT 0ROBLEMS 7ITH #OMPATIBLE /PTIMAL&EASIBLE 3OLUTIONS .OT 4HE /PTIMUM 3OLUTIONS /F 4HE /THER )DENTIFIED )DENTIFY 4HOSE 0AIRS 7HERE &EASIBLE 3OLUTIONS "UT .OT 4HE /PTIMUM 3OLUTIONS 0ROBLEMS 7ITH #OMPATIBLE &EASIBLE 3OLUTIONS )DENTIFIED !RE #OMPATIBLE )DENTIFY 4HOSE 0AIRS 7HERE &EASIBLE 3OLUTIONS !ND /PTIMUM 3OLUTIONS !RE )NCOMPATIBLE 0ROBLEMS 7ITH )NCOMPATIBLE 3OLUTIONS )DENTIFIED
103 0HASE #ONTINUED
!NALYSIS #ONTINUED
0REPARE 0ERFORMANCE 3PECIFICATION #ONTINUED 2EAPPRAISE 0ROGRAM !ND %STIMATE
)TEM !CTIVITY !CTIVITY .O %VENT
3ELECT !LL 4HE 3UB PROBLEMS ,ISTED 5NDER !ND 7HICH 3TAND (IGH /N 4HE 2ANK #RITICAL 0ROBLEMS 2EEXAMINED /RDERED ,IST !ND 2EEXAMINE 4HEM !CCORDING 4O 3ELECTION 2EEXAMINE !SSIGNED 6ALUES !ND 3IMPLIFYING !SSUMPTIONS !T 2EITERATE &ROM !S .ECESSARY )F 4OO -ANY )NCOMPATIBILITIES 2EMAIN 2EITERATE 3ECTIONS !ND 3EEKING %ASEMENTS 7HEN !LL 0ROBLEMS !BOUT %NDS (AVE "EEN 2ESOLVED /R !S -ANY /F 4HEM !S 3EEMS 0ERFORMANCE 3PECIFICATION 2EADY 0RACTICABLE !SSEMBLE !LL 4HEIR 3OLUTIONS )NTO ! 0ERFORMANCE /R $ESIGN 3PECIFICATION 2ANKED 3UBSTANTIALLY )N !CCORDANCE 7ITH ,IST !NY 2EMAINING )NTRACTABLE 0ROBLEMS !BOUT %NDS &OR 2EFERENCE 4O #LIENT !NDOR &OR 2EMAINING )NTRACTABLE 0ROBLEMS !BOUT %NDS ,ISTED 2ESOLUTION !S #REATIVE 0ROBLEMS
2EAPPRAISE 0ROGRAM !ND %STIMATE )N 4HE ,IGHT /F !ND 2ESTATE 4HE 0ROBLEM 3ET /UT )N 0ROBLEM 2ESTATEMENT 2EADY 2EAPPRAISE 4HE #RUCIAL )SSUES 3ET /UT )N 2EAPPRAISED #RUCIAL )SSUES ,ISTED 2EAPPRAISE !ND )F .ECESSARY 2EFORMULATE ! #OURSE /F !CTION 0ERVIOUSLY 3ET /UT )N #OURSE /F !CTION 2EFORMULATED 7HERE 2EQUIRED 0REPARE ! 2EPORT /N 4HE /VERALL 0ROBLEMS !BOUT %NDS 2EFERRING 4O 2EPORT /N 0ROBLEM !BOUT %NDS 2EADY 2EAPPRAISE 0ROGRAM !ND 4IMETABLE 0ROGRAM !ND 4IMETABLE 2EAPPRAISED 2EAPPRAISE /FFICE 7ORKLOAD !ND 0ROJECT &ACILITIES 7ORKLOAD !ND &ACILITIES 2EAPPRAISED &ORMULATE $RAFT 2EVISED 0ROPOSAL !ND %STIMATE $RAFT 2EVISED 0ROPOSAL 0ERFORMANCE 3PECIFICATION !ND 7ITH 0ERFORMANCE 3PECIFICATION &OR !PPROVAL !ND 2EPORT /N /VERALL 0ROBLEM !ND %NDS %STIMATE 2EADY 7HERE .ECESSARY #HECK !ND !PPROVE $RAFT 0ROPOSAL !ND %STIMATE $RAFT 0ROPOSAL !ND %STIMATE $ISPATCHED )F .ECESSARY 2EITERATE &ROM 5NTIL ! 3ATISFACTORY 0ROPOSAL )S $RAFTED 0REPARE !ND $ISPATCH &AIR #OPY /F 0ROPOSAL !ND %STIMATE 0ROPOSAL !ND %STIMATE $ISPATCHED "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
2EITERATE 3ECTION 5NTIL !GREEMENT )S 2EACHED 4O #ARRY /UT 0HASE 0REPARE /UTLINE $ESIGN 0ROPOSALS /R 0ROJECT )S 4ERMINATED
7HERE 3UITABLE 0HASE $EVELOP 0ROTOTYPE $ESIGNS !NDOR 0HASE 0REPARE !ND %XECUTE 6ALIDATION 3TUDIES -AY !LSO "E #OMMISSIONED !T 4HE 3AME 4IME !S 0HASE
104 0HASE
3YNTHESIS
2ECEIVE )NSTRUCTIONS 2ESOLVE 2EMAINING 0ROBLEMS !BOUT %NDS
N N N N N N
N N N N
N N N N N N
)TEM !CTIVITY !CTIVITY .O %VENT
3YNTHESIS
2ECEIVE )NSTRUCTIONS #OMMISSION 2ECEIVED 4O %XECUTE 0HASE 3END !CKNOWLEDGMENT !CKNOWLEDGMENT $ISPATCHED "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
2ESOLVE 2EMAINING 0ROBLEMS !ND %NDS .OTE 4HAT )N 'ENERAL 3OLUTIONS 4O 0ROBLEMS !BOUT %NDS 7ILL 0OSE 0ROBLEMS !BOUT -EANS 2EAPPRAISE 4HE 0ERFORMANCE 3PECIFICATION 0REPARED 5NDER !ND 4HE ,IST /F )NTRACTABLE 2EVISED ,IST /F 5NRESOLVED 0ROBLEMS !BOUT %NDS 2EADY 0ROBLEMS !BOUT %NDS 0REPARED 5NDER !ND 0REPARE ! .EW ,IST /F 5NRESOLVED 0ROBLEMS !BOUT %NDS &OR %ACH 0ROBLEM )N 4HE ,IST 0REPARE 5NDER ,IST 4HE &ACTORS )N 4HE 0ROBLEM ,IST /F &ACTORS )N 3UB PROBLEM 2EADY )DENTIFY 4HE 'OALS 4O "E !CHIEVED !ND 4HE #ONSTRAINTS /R #ONDITIONS 4O "E 3ATISFIED 'OALS !ND #ONSTRAINTS /R #ONDITIONS &OR 3UB PROBLEMS )DENTIFIED %STABLISH 4HE #ONNECTIONS "ETWEEN 4HE &ACTORS /R 4HE 'OALS !ND #ONSTRAINTS /R #ONDITIONS #ONNECTIONS "ETWEEN &ACTORS %STABLISHED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE )DENTIFIED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE )DENTIFIED #ATALOG 4HE 0ROPERTIES /F 4HE !NALOGOUS 0ROBLEMS !ND 2EEXPRESS %ACH 7ITHIN ! !NALYSIS /F !NALOGOUS 0ROBLEMS #OMPLETE #OMMON &ORMAT 2EEXPRESS 0RESENT 3UB PROBLEM 7ITHIN 4HE &ORMAT $EVELOPED 5NDER 2E EXPRESSION /F 3UB PROBLEM 7ITHIN #OMMON &ORMAT #OMPLETE )DENTIFY 4HOSE &ACTORS )N 4HE 3UB PROBLEM &OR 7HICH 4HE $ATA 6ALUES -AY "E 6OLUNTARILY &ACTORS 7HERE $ATA 6ALUES !RE 6OLUNTARILY !SSIGNABLE &IXED "Y 4HE $ESIGNER )DENTIFIED )DENTIFY 4HOSE &ACTORS )N 4HE 3UB PROBLEM &OR 7HICH 4HE $ATA 6ALUES !RE &IXED "Y &ACTORS 7HERE $ATA 6ALUES !RE %XTERNALLY &IXED )DENTIFIED %XTERNAL )NFLUENCES )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA !RE $EPENDENT 6ARIABLES &OR %XAMPLE 7HERE 4HE &ACTORS 7HERE $ATA !RE $EPENDENT 6ARIABLES )DENTIFIED $ATA !RE 4HE 3OLUTIONS 4O /THER 3UB PROBLEMS )F .ECESSARY 3USPEND 7ORK /N 4HIS 0ROBLEM !ND 3ELECT !NOTHER !T 3O 4HAT 3UB PROBLEMS !RE $EALT 7ITH )N 4HE 2IGHT /RDER #OLLECT .ECESSARY $ATA %ITHER %XTRACT $ATA &ROM 2ECORD 3YSTEM /R !DD &RESH $ATA .ECESSARY $ATA 2EADY 7HERE 3UFFICIENT 0RECISE $ATA )S .OT !VAILABLE 0OSTULATE 3IMPLIFYING !SSUMPTIONS /R !SSIGN 3IMPLIFYING !SSUMPTIONS 0OSTULATED !NDOR $ATA 6ALUES "Y 0LAUSIBLE 2EASONING 6ALUES !SSIGNED 7HERE .OT 0RACTICAL 3OLUTION %MERGES 6ARY /NE /F 4HE 6OLUNTARILY !SSIGNED 6ALUES !NDOR .O 3OLUTION !SSIGNED 6ALUES !NDOR 3IMPLIFYING !SSUMPTIONS 3EE !ND !ND 3EEK %ASEMENTS !SSUMPTIONS 6ARIED 7HERE 4HIS &AILS 2EAPPRAISE #ONSTRAINTS 3EE !ND 3EEK %ASEMENTS .O 3OLUTION #ONSTRAINTS /R #ONDITIONS %ASED )N 4HE ,AST 2ESORT 2EAPPRAISE 'OALS 3EE !ND 3EEK 6ARIATION .O 3OLUTION 'OALS 6ARIED 2ESOLVE 0ROBLEM $ELINEATING -AXIMUM &IELD /F &EASIBLE 3OLUTIONS 3OLUTION 4O 3UB PROBLEM 2EADY
105 0HASE #ONTINUED
3YNTHESIS #ONTINUED
2ESOLVE 2EMAINING 0ROBLEMS !BOUT %NDS #ONTINUED 0OSTULATE -EANS &OR 2ECONCILING $IVERGENT $ESIDERATA )N 0ERFORMANCE 3PECIFICATION
N
N
N N N N
N N N N N
N
)TEM !CTIVITY !CTIVITY .O %VENT
)F ! 6ARIATION /R !SSUMPTION (AS "EEN -ADE 5NDER !ND ! 3OLUTION (AS %MERGED 0RIMA &ACIE 6ALIDATION /F !SSUMPTIONS !ND 6ARIATIONS 2EFER 4O 3OURCE !ND #HECK 0RIMA &ACIE !CCEPTABILITY /F 6ARIATION /R !SSUMPTION 3EE !LSO #OMPLETE 6ALIDATION 3TUDIES 3ECTION 7HERE .ECESSARY 2EITERATE &ROM 2EITERATE &ROM 5NTIL !LL /UTSTANDING 0ROBLEMS !BOUT %NDS ,ISTED 5NDER !RE !LL 0ROBLEMS !BOUT %NDS 2ESOLVED 2ESOLVED 5NITE 3OLUTIONS 0REPARED 5NDER 7ITH 0ERFORMANCE 3PECIFICATION 0REPARED 5NDER 2EVISED 0ERFORMANCE 3PECIFICATION 2EADY 4O &ORM ! 2EVISED 3PECIFICATION
0OSTULATE -EANS &OR 2ECONCILING $IVERGENT $ESIDERATA )N 0ERFORMANCE 3PECIFICATION %XAMINE 4HE !UGMENTED 0ERFORMANCE 3PECIFICATION 0REPARED 5NDER !ND )DENTIFY )NTER RELATED $ESIDERATA )DENTIFIED )NTERACTION -ATRIX !ND 'ROUP 4HOSE $ESIDERATA 7HICH !PPEAR 4O "E )NTER RELATED ,IST 4HE 'ROUPS /F )NTER RELATED $ESIDERATA ,IST /F )NTER RELATED $ESIDERATA 2EADY &ROM 4HE ,IST 0REPARED 5NDER 3ELECT 4HOSE 'ROUPS #ONTAINING $ESIDERATA 7HICH 'ROUPS #ONTAINING $IVERGENT $ESIDERATA )DENTIFIED !PPEAR 4O "E $IVERGENT /R #ONTRADICTORY &OR %ACH 'ROUP 3ELECTED 5NDER 2EEXPRESS 4HE $ESIDERATA !S 4HE 'OALS !ND $IVERGENT $ESIDERATA 2EEXPRESSED !S 'OALS #ONSTRAINTS /R #ONDITIONS &OR /NE /R -ORE 0ROBLEMS !BOUT -EANS ,IST 4HE 0ROBLEMS !BOUT -EANS 4HUS )DENTIFIED ,IST /F 0ROBLEMS !BOUT -EANS 2EADY &OR %ACH 0ROBLEM !BOUT -EANS ,ISTED 5NDER ,IST 4HE &ACTORS )N 4HE 0ROBLEM ,IST /F &ACTORS )N 4HE 3UB PROBLEM 2EADY )DENTIFY 'OALS !ND #ONSTRAINTS /R #ONDITIONS )N 4HE 3UB PROBLEM ,IST /F 'OALS !ND #ONSTRAINTS /R #ONDITIONS 2EAD %STABLISH 4HE #ONNECTIONS "ETWEEN 4HE &ACTORS 'OALS !ND #ONSTRAINTS /R #ONNECTION "ETWEEN &ACTORS !ND 4HE 'OALS !ND #ONDITIONS #ONSTRAINTS /R #ONDITIONS %STABLISHED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE )DENTIFIED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE )DENTIFIED #ATALOG 4HE 0ROPERTIES /F 4HE .EAREST !NALOGOUS 0ROBLEMS !ND 4HE %LEMENTS /F 4HEIR 0ROBLEM %LEMENTSOLUTION -ATRIX 2EADY 2ESPECTIVE 3OLUTIONS !ND 0REPARE ! 0ROBLEM %LEMENTPROBLEM 3OLUTION -ATRIX 2E EXPRESSION /F 3UB PROBLEM 7ITH 3AME -ATRIX #OMPLETE 2EEXPRESS 4HE 0RESENT 0ROBLEM 7ITHIN 4HE 3AME -ATRIX %XPLORE #OMBINATIONS /F 3OLUTION %LEMENTS %XPLORATION /F #OMBINATIONS /F 3OLUTION %LEMENTS #OMPLETE 3ELECT ! 0ROMISING #OMBINATION /F 3OLUTION %LEMENTS !S ! (YPOTHESIS &OR $EVELOPMENT (YPOTHESIS 3ELECTED 7HERE .O 0ROMISING (YPOTHESIS %MERGES 2EITERATE &ROM )N 7IDER &IELDS .O (YPOTHESIS 2EITERATE &ROM 5NTIL !LL 0ROBLEMS !BOUT -EANS !RISING &ROM $IVERGENT $ESIDERATA )N 4HE 0ERFORMANCE 3PECIFICATION !RE 2ESOLVED !SSEMBLE (YPOTHETICAL 3OLUTIONS 3OLUTIONS IN PRINCIPLE !SSEMBLED
106 0HASE #ONTINUED
3YNTHESIS #ONTINUED
$EVELOP 3OLUTIONS )N 0RINCIPLE 4O 0ROBLEMS !BOUT -EANS !RISING &ROM 0ERFORMANCE 3PECIFICATION 0OSTULATE /UTLINE /VERALL 3OLUTIONS
OR
N
N N N
N N N N N N N N
N
)TEM !CTIVITY !CTIVITY .O %VENT
$EVELOP 3OLUTIONS )N 0RINCIPLE 4O 0ROBLEMS !BOUT -EANS !RISING &ROM 0ERFORMANCE 3PECIFICATION 2EFERRING 4O 4HE 0ERFORMANCE 3PECIFICATION 0REPARED 5NDER 4HE ,IST /F 'ROUPS /F ,IST /F /UTSTANDING )NTER RELATED $ESIDERATA 2EADY )NTERRELATED $ESIDERATA 0REPARED 5NDER ,IST 4HOSE 'ROUPS !ND 3INGLE $ESIDERATA .OT 9ET (ANDLED !DD !NY 0ROBLEM !BOUT -EANS 2EMAINING &ROM 4HOSE 5NDER &OR %ACH )TEM ,ISTED 5NDER 2EEXPRESS 4HE 'OALS !ND #ONSTRAINTS &OR /NE /R -ORE 'OALS !ND #ONSTRAINTS &OR 0ROBLEMS !BOUT -EANS )DENTIFIED 0ROBLEMS !BOUT -EANS ,IST 4HE 0ROBLEMS !BOUT -EANS 4HUS )DENTIFIED ,IST /F 0ROBLEMS !BOUT -EANS 2EADY &OR %ACH 0ROBLEM !BOUT -EANS ,ISTED 5NDER ,IST 4HE &ACTORS )N 4HE 0ROBLEM ,IST /F &ACTORS )N 4HE 3UB PROBLEM 2EADY )DENTIFY 'OALS !ND #ONSTRAINTS /R #ONDITIONS )N 4HE 3UB PROBLEM 2EVISED ,IST /F 'OALS !ND #ONSTRAINTS /R #ONDITIONS 2EADY %STABLISH 4HE #ONNECTIONS "ETWEEN 4HE &ACTORS 'OALS !ND #ONSTRAINTS /R #ONNECTION "ETWEEN &ACTORS !ND 4HE 'OALS !ND #ONDITIONS #ONSTRAINTS /R #ONDITIONS %STABLISHED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE !NALOGOUS 0ROBLEMS )N 0RIOR %XPERIENCE )DENTIFIED )DENTIFY 3IMILAR /R !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE !NALOGOUS 0ROBLEMS (ANDLED %LSEWHERE )DENTIFIED #ATALOG 4HE 0ROPERTIES /F 4HE .EAREST !NALOGOUS 0ROBLEMS !ND 4HE %LEMENTS /F 4HEIR 0ROBLEM %LEMENTSOLUTION -ATRIX 2EADY 2ESPECTIVE 3OLUTIONS !ND 0REPARE ! 0ROBLEM %LEMENTPROBLEM 3OLUTION -ATRIX 2EEXPRESS 4HE 0RESENT 0ROBLEM 7ITHIN 4HE 3AME -ATRIX 2E EXPRESSION /F 3UB PROBLEM 7ITH 3AME -ATRIX #OMPLETE %XPLORE #OMBINATIONS /F 3OLUTION %LEMENTS %XPLORATION /F #OMBINATIONS /F 3OLUTION %LEMENTS #OMPLETE 3ELECT ! 0ROMISING #OMBINATION /F 3OLUTION %LEMENTS !S ! (YPOTHESIS &OR $EVELOPMENT (YPOTHESIS 3ELECTED 7HERE .OT 0ROMISING (YPOTHESIS &OR $EVELOPMENT %MERGES 2EITERATE &ROM )N 7IDER &IELD .O (YPOTHESIS 2EITERATE &ROM 5NTIL !LL 0ROBLEMS !BOUT -EANS !RISING &ROM $ESIDERATA )N 0ERFORMANCE 3PECIFICATION !RE 2ESOLVED )N 0RINCIPLE !SSEMBLE (YPOTHETICAL 3OLUTIONS 3OLUTIONS IN PRINCIPLE !SSEMBLED
0OSTULATE /UTLINE /VERALL 3OLUTIONS 5NITE 4HE #OLLECTION /F (YPOTHETICAL 3OLUTIONS 5NDER 7ITH 4HOSE 5NDER #OMBINED #OLLECTION /F (YPOTHETICAL 3OLUTIONS 2EADY 5SING 4HE 0ERFORMANCE 3PECIFICATION 0REPARED 5NDER !S ! 'UIDE 4AKE %VERY 2ANKING -ATRIX &OR 0ROBLEMS !BOUT %NDS 2EADY #OMBINATION /F 0AIRS /F (YPOTHETICAL 3OLUTIONS !ND )DENTIFY 7HICH )N %ACH 0AIR 3HOULD 4AKE 0RECEDENCE )F 4HEY 3HOULD ,ATER 0ROVE 4O "E )NCOMPATIBLE 2ANK 4HE #OLLECTION /F (YPOTHETICAL 3OLUTIONS )N /RDER /F 0RECEDENCE 2ANKED ,IST /F (YPOTHETICAL 3OLUTIONS 2EADY 4AKING %VERY #OMBINATION /F 0ARIS /F (YPOTHETICAL 3OLUTIONS &ROM 4HE ,IST 5NDER #OMPATIBILITY 3TUDIES #OMPLETE "EGINNING 7ITH 4HE 0AIRS #ONTAINING 4HE (IGHEST 2ANKED 3OLUTIONS !ND )N 4HE ,IGHT /F 7HATEVER )NFORMATION )S 2EADILY !VAILABLE #HECK 4HE 0LAUSIBILITY /F %ACH 0AIRgS 0ROVING 4O "E #OMPATIBLE 7HERE 0ROBABLE )NCOMPATIBILITIES !RE )DENTIFIED 2EITERATE &ROM
107 0HASE #ONTINUED 0HASE
3YNTHESIS #ONTINUED $EVELOPMENT
0OSTULATE /UTLINE /VERALL 3OLUTIONS #ONTINUED 2ECEIVE )NSTRUCTIONS $EFINE $ESIGN )DEA %RECT ! +EY -ODEL
)TEM !CTIVITY !CTIVITY .O %VENT
!SSEMBLE !LL 4HE (YPOTHETICAL 3OLUTIONS )NTO ! 3UGGESTED #OMPOSITE /VERALL 3OLUTION /R #OMPOSITE /VERALL 3OLUTIONS 2EADY 2ANGE /F 3OLUTIONS 2EAPPRAISE 4HE 0ROPOSED 3OLUTIONS )N 4HE ,IGHT /F 4HE 0ROBLEM !S 3ET /UT )N 2EAPPRAISAL )N ,IGHT /F /RIGINAL 0ROBLEM 2EAPPRAISE 4HE 0ROPOSED 3OLUTIONS )N 4HE ,IGHT /F #RUCIAL )SSUES 3ET /UT )N 2EAPPRAISAL )N ,IGHT /F #RUCIAL )SSUES #OMPLETE 7HERE 2EQUIRED 0REPARE !ND 3UBMIT 3KETCH $ESIGNS 3EE .OTE "ELOW 3KETCH $ESIGNS 2EADY 2EAPPRAISE !ND )F .ECESSARY 2EFORMULATE ! #OURSE /F !CTION 0REVIOUSLY 3ET /UT )N 2EAPPRAISAL !NDOR 2EFORMULATION /F #OURSE /F !CTION #OMPLETE 2EAPPRAISE 4IMETABLE 2EAPPRAISAL /F 4IMETABLE #OMPLETE 2EAPPRAISE &ACILITIES 2EAPPRAISAL /F &ACILITIES #OMPLETE )F .ECESSARY 0REPARE 2EVISED 0ROPOSALS 2EVISED 0ROPOSALS 2EADY "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
.OTE )F 3KETCH $ESIGNS -UST "E 3UBMITTED &OR !PPROVAL !T 4HIS 3TAGE 3EE #ONTINUE 7ITH 3ECTION !ND 4HEN 4HE 7HOLE /F 3ECTION &OR 4HE 3KETCH $ESIGN /NLY 2EITERATE 4HE 7HOLE /F 3ECTION 5NTIL ! 3KETCH $ESIGN )S !PPROVED !ND ! #OMMISSION )S 2ECEIVED 4O %XECUTE 0HASE 0ROCEED 7ITH 3ECTION )N 2ESPECT /F 4HE &INISHED $ESIGN
$EVELOPMENT
2ECEIVE )NSTRUCTIONS #OMMISSION 2ECEIVED 4O %XECUTE 0HASE 3END !CKNOWLEDGMENT !CKNOWLEDGMENT $ISPATCHED "RING &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE &ILES !ND 0ROGRESS -ACHINERY 5P 4O $ATE
$EFINE $ESIGN )DEA 5SING 4HE -OST !BSTRACT /R 'ENERAL -EDIUM !VAILABLE EG ! &ORM /F 7ORDS #OMPLETELY $EFINITION /F %SSENTIAL 'ERM /F $ESIGN )DEA 2EADY $EFINE 4HE %SSENTIAL 'ERM /F 4HE $ESIGN )DEA 5SING 4HE 3AME -EDIUM $EFINE 4HE -AXIMUM 6ARIATION %MBRACEABLE "Y 4HE $ESIGN )DEA $EFINITION /F 2ANGE /F 6ARIATION %MBRACEABLE "Y $ESIGN )N 4HE #ASE /F 3KETCH $ESIGNS "EING 0REPARED 5NDER 0ROCEED .OW 7ITH 3ECTION )DEA 2EADY )N 2ESPECT /F 3KETCH $ESIGNS /NLY
%RECT ! +EY -ODEL ,IST 2ANGE /F -EDIA &OR 4HE 2EPRESENTATION /F !N %MBODIMENT /F 4HE $ESIGN )DEA ,IST /F !VAILABLE -EDIA 2EADY 3ELECT 4HE ,EAST !BSTRACT -EDIUM 7HICH 7ILL %XHAUSTIVELY $ESCRIBE 4HE 6ARIANTS /F 4HE -EDIUM 3ELECTED $ESIGN )DEA 3EE %RECT ! +EY -ODEL /F 4HE %SSENTIAL $ESIGN )DEA 3HOWING !LL )TgS 6ARIANTS +EY -ODEL %RECTED
108 0HASE #ONTINUED
$EVELOPMENT #ONTINUED
$EVELOP 3UB PROBLEM -UTUAL 3OLUTIONS N
N N
N N N N N
N N N
)TEM !CTIVITY !CTIVITY .O %VENT
$EVELOP 3UB PROBLEM -UTUAL 3OLUTIONS 4AKE 4HE #OMBINED #OLLECTION /F (YPOTHETICAL 3UB PROBLEM 3OLUTIONS 5NDER !ND )N )NTERACTION -ATRIX 2EADY 4HE ,IGHT /F 4HE )NFORMATION %MPLOYED )N 4HEIR 2ESPECTIVE 2ESOLUTIONS 3EE 3ECTION !ND 3ECTION )DENTIFY !LL #OMBINATIONS /F 0AIRS /F (YPOTHETICAL 3OLUTIONS 7HICH !PPEAR 4O )NVOLVE )NTER ACTING $EVELOPMENT $ETAILS ,IST 4HE )NTER ACTING 0AIRS 4HUS )DENTIFIED ,IST /F )NTER ACTING 0AIRS /F (YPOTHETICAL 5SING 4HE 2ANKED ,IST /F (YPOTHETICAL 3UB PROBLEM 3OLUTIONS 0REPARED 5NDER !S ! 'UIDE 3UB PROBLEM 3OLUTIONS 2EADY )DENTIFY !ND 0LOT )N 4HE &ORM /F ! .ETWORK 4HE -OST $ESIRABLE 3EQUENCE &OR $ETAILED $EVELOPMENT /F 4HE #HAIN /F (YPOTHETICAL 3UB PROBLEM 3OLUTIONS 3ELECT 4HE %ARLIEST 5NDEVELOPED (YPOTHESIS )N 4HE .ETWORK 2EFERRING 7HERE .ECESSARY 4O ,IST /F &ACTORS )N 3UB PROBLEM 2EADY 7ORKING 0APERS 0REPARED 5NDER 3ECTION !ND ,IST 4HE &ACTORS )N $EVELOPING 4HIS (YPOTHESIS )NTO ! -ATERIAL %MBODIMENT 2EFERRING 7HERE .ECESSARY 4O 7ORKING 0APERS 5NDER 3ECTION )DENTIFY 4HE 'OALS !ND ,IST /F 'OALS !ND #ONSTRAINTS /R #ONDITIONS 2EADY #ONSTRAINTS /R #ONDITIONS )N 4HE 3UB PROBLEM 2EFERRING 7HERE .ECESSARY 4O 7ORKING 0APERS 0REPARED 5NDER 3ECTION %STABLISH 4HE #ONNECTIONS "ETWEEN &ACTORS %STABLISHED #ONNECTIONS "ETWEEN 4HE &ACTORS 'OALS !ND #ONSTRAINTS /R #ONDITIONS )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA 6ALUES -AY "E 6OLUNTARILY !SSIGNED "Y 4HE $ESIGNER &ACTORS 7HERE $ATA 6ALUES !RE 6OLUNTARILY !SSIGNABLE )DENTIFIED )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA 6ALUES !RE &IXED "Y %XTERNAL )NFLUENCES &ACTORS 7HERE $ATA 6ALUES !RE &IXED "Y %XTERNAL )NFLUENCES )DENTIFIED )DENTIFY 4HOSE &ACTORS 7HERE 4HE $ATA !RE $EPENDENT 6ARIABLES &OR %XAMPLE 7HERE 4HE $ATA &ACTORS 7HERE $ATA 6ALUES !RE $EPENDENT 6ARIABLES )DENTIFIED !RE (E 3OLUTIONS 4O /THER 3UB PROBLEMS )F .ECESSARY 2EVISE .ETWORK 0REPARED 5NDER 3O 4HAT 0ROBLEMS 7HICH 0ROVIDE $ATA &OR 2EVISED .ETWORK 2EADY /THER 3UB PROBLEMS !RE $EALT 7ITH )N 4HE 2IGHT /RDER /R 3ELECT !NOTHER 0ROBLEM !T #OLLECT .ECESSARY $ATA .ECESSARY $ATA 2EADY 7HERE 3UFFICIENT !ND 3UFFICIENTLY 0RECISE $ATA )S !VAILABLE $EVELOP ! -ODEL %MBODIMENT /F 4HE (YPOTHETICAL 3OLUTION 7HERE 3UFFICIENT 0RECISE $ATA )S .OT !VAILABLE 0OSTULATE 3IMPLIFYING !SSUMPTIONS "Y 3IMPLIFYING !SSUMPTIONS 0OSTULATED 0LAUSIBLE 2EASONING !ND $EVELOP ! -ODEL %MBODIMENT /F 4HE (YPOTHETICAL 3OLUTION -ATERIAL %MBODIMENT 2EADY 4EST 4HE %MBODIMENT &OR &IT 7ITHIN 4HE &RAMEWORK /F 4HE +EY -ODEL 4EST /F 3UB PROBLEM 3OLUTION %MBODIMENT 7ITH +EY 7HERE %MBODIMENT )S &OUND 4O "E )MPRACTICABLE 2EVISE (YPOTHETICAL 3OLUTION "Y -ODEL #OMPLETE 2EITERATING 3ECTION &OR 4HAT 3UB PROBLEM !ND 3ECTION &OR 4HE %FFECT /F ! .EW (YPOTHESIS /N 4HE /VERALL $ESIGN #ONCEPT 2EEXAMINE 4HE )NTER ACTION -ATRIX 0REPARED 5NDER !ND 4HE .ETWORK 0REPARED 5NDER !LL (YPOTHETICAL 3UB PROBLEM 3OLUTIONS %MBODIED 2EVISE .ETWORK !S .ECESSARY !ND 3ELECT !NOTHER 3UB PROBLEM
109 0HASE #ONTINUED 0HASE
$EVELOPMENT #ONTINUED $EVELOPMENT #ONTINUED
$EVELOP /VERALL 3OLUTIONS 6ALIDATE (YPOTHESES
N
N
N N N N
N N N
)TEM !CTIVITY !CTIVITY .O %VENT
$EVELOP /VERALL 3OLUTIONS 5NITE -ODEL 3UB PROBLEM %MBODIMENTS )NTO /NE /R -ORE -ODEL /VERALL 3OLUTIONS -ODEL /VERALL 3OLUTION 2EADY )DENTIFY 5NDEVELOPED !REAS )N 4HE $ESIGN 5NDERDEVELOPED !REA )DENTIFIED 2EEXPRESS !S ! 3EQUENCE /F !DDITIONAL 0ROBLEMS &OR #OMPLETION .EW .ETWORKS 2EADY $EVELOP %ACH 0ROBLEM 5NDER "Y 2EITERATING &ROM /VERALL 3OLUTION 2EADY 2EITERATE 3ECTION 5NTIL /NE /R -ORE /VERALL 3OLUTIONS !RE &ULLY $EVELOPED $EVELOP %ACH 0ROBLEM 5NDER "Y 2EITERATING &ROM /VERALL 3OLUTION 2EADY 2EITERATE 3ECTION 5NTIL /NE /R -ORE /VERALL 3OLUTIONS !RE &ULLY $EVELOPED
6ALIDATE (YPOTHESES 3ELECT !ND ,IST 4HOSE 0ROBLEMS !BOUT %NDS 7HERE $ATA 6ALUES 7ERE 6OLUNTARILY !SSIGNED ,IST /F 0ROBLEMS !BOUT %NDS #ONTAINING 3EE !ND 6OLUNTARILY !SSIGNED 6ALUES 2EADY 3ELECT !ND ,IST 4HOSE 0ROBLEMS !BOUT %NDS 7HERE 3IMPLIFYING !SSUMPTIONS 7ERE -ADE 3EE ,IST /F 0ROBLEMS !BOUT %NDS #ONTAINING 3IMPLIFYING !ND !SSUMPTIONS 2EADY &OR %ACH 0ROBLEM ,ISTED 5NDER /R &ORMULATE (YPOTHESES #ALCULATED 4O &ACILITATE (YPOTHESES 2EADY 4HE 6ALIDATION /F 4HE 3OLUTION 4O 4HE 0ROBLEM 3EE !ND &OR %ACH (YPOTHESIS 5NDER $ESIGN !N %XPERIMENT 4O 4EST 4HE (YPOTHESIS !ND 6ALIDATE $ESIGN &OR %XPERIMENT /R 4EST 2EADY 4HE 3OLUTION 3EE .OTE "ELOW #ONDUCT 6ALIDATION %XPERIMENT /R 3TUDY !S 0LANNED 5NDER %XPERIMENT /R 3TUDY #OMPLETE 7HERE 4HE %XPERIMENT /R 3TUDY 3HOWS 4HAT 4HE 3OLUTION 4O 4HE 0ROBLEM !BOUT %NDS )S 3OLUTION 4O 0ROBLEM !BOUT %NDS 3HOWN 4O "E )NVALID )NVALID 3EE 4HEN 2EWORK 4HE 0ROBLEM !BOUT %NDS !ND !LL )TgS 2AMIFICATIONS &ROM 7HERE 4HE %XPERIMENT /R 3TUDY )S )NCONCLUSIVE 2EITERATE &ROM 2ESULT /F %XPERIMENT /R 3TUDY )NCONCLUSIVE 7HERE 4HE %XPERIMENT /R 3TUDY )NDICATES 4HAT 4HE 3OLUTION 4O 4HE 0ROBLEM !BOUT %NDS )S !LL 3OLUTIONS 4O 0ROBLEMS !BOUT %NDS #ONTAINING 3UPPORTED 2EITERATE &ROM 5NTIL 0ROBLEMS ,ISTED 5NDER !ND !RE 6ALIDATED !SSUMPTIONS .OW 6ALIDATED )DENTIFY !ND ,IST 4HOSE 3TATEMENTS )N 4HE 0ERFORMANCE 3PECIFICATION 3EE 7HICH (AVE ,IST /F 5NTESTED 3TATEMENTS )N 0ERFORMANCE .OT "EEN %XAMINED 5NDER 3PECIFICATION 2EADY .OTE 7HERE .ECESSARY 4HE 0ROBLEM /F $ESIGNING !N %XPERIMENT #AN "E (ANDLED "Y 4HE 0ROCEDURES 3ET /UT )N 3ECTION !ND 3ECTION 4HESE 0ROCEDURES )NCLUDE !PPRAISING 4HE 3IGNIFICANCE /F 4HE 0ROBLEM 5NDER )NVESTIGATION !ND 4HE !MOUNT /F %FFORT 7HICH #AN "E $EVOTED 4O )TgS 3OLUTION &OR %ACH 3TATEMENT ,ISTED 5NDER &ORMULATE (YPOTHESES #ALCULATED 4O &ACILITATE (YPOTHESIS &ORMULATED 6ALIDATION /F 4HE 3TATEMENT &OR %ACH (YPOTHESIS 5NDER $ESIGN !N %XPERIMENT 4O 4EST 4HE (YPOTHESIS !ND 6ALIDATE $ESIGN &OR %XPERIMENT /R 3TUDY 2EADY 4HE 3TATEMENT 3EE .OTE /N 0AGE #ONDUCT 6ALIDATION %XPERIMENT /R 3TUDY !S 0LANNED 5NDER %XPERIMENT /R 3TUDY #OMPLETE
110 0HASE #ONTINUED
$EVELOPMENT #ONTINUED
6ALIDATE (YPOTHESES #ONTINUED
N N
N N N
N N N N N N
N N N
)TEM !CTIVITY !CTIVITY .O %VENT
7HERE 4HE %XPERIMENT /R 3TUDY 3HOWS 4HAT 4HE 3TATEMENT )N 4HE 3PECIFICATION )S )NVALID 4HEN 3PECIFICATION 3TATEMENT 3HOWN 4O "E )NVALID 2EWORK 4HE 0ROBLEMS !BOUT %NDS %MBODIED )N 4HE 3TATEMENT !ND !LL 4HEIR 2AMIFICATIONS &ROM 7HERE 4HE %XPERIMENT /R 3TUDY )S )NCONCLUSIVE 2EITERATE &ROM %XPERIMENT /R 3TUDY )NCONCLUSIVE 7HERE 4HE %XPERIMENT /R 3TUDY )NDICATES 4HAT 4HE 3PECIFICATION 3TATEMENT )S 3UPPORTED !LL 3PECIFICATION 3TATEMENTS 6ALIDATED 2EITERATE &ROM 5NTIL !LL 3TATEMENTS )N 4HE 0ERFORMANCE 3PECIFICATION !RE 6ALIDATED )DENTIFY !ND ,IST 4HOSE $ESIGN $ETAILS 7HERE $ATA 6ALUES 7ERE 6OLUNTARILY !SSIGNED "Y 4HE ,IST /F $ESIGN $ETAILS "ASED /N !SSUMPTIONS 2EADY $ESIGNER 3EE !ND 7HERE 3IMPLIFYING !SSUMPTIONS 7ERE -ADE 3EE &OR %ACH $ETAIL 5NDER &ORMULATE (YPOTHESES 4O &ACILITATE 6ALIDATION /F 4HE $ETAIL (YPOTHESES &ORMULATED &OR %ACH (YPOTHESIS 5NDER $ESIGN !N %XPERIMENT 4O 4EST 4HE (YPOTHESIS !ND 6ALIDATE $ESIGN &OR %XPERIMENT /R 3TUDY 2EADY 4HE $ETAIL 3EE .OTE !FTER #ONDUCT 6ALIDATION %XPERIMENT /R 3TUDY !S 0LANNED 5NDER %XPERIMENT /R 3TUDY #OMPLETE 7HERE 4HE %XPERIMENT /R 3TUDY 3HOWS 4HAT 4HE $ESIGN $ETAIL )S )NVALID 4HEN 2EWORK 4HE $ESIGN $ETAIL 3HOWN 4O "E )NVALID $ETAIL $EVELOPMENT &ROM 7HERE 4HE %XPERIMENT /R 3TUDY )S )NCONCLUSIVE 2EITERATE &ROM %XPERIMENT /R 3TUDY )NCONCLUSIVE 7HERE 4HE %XPERIMENT /R 3TUDY )NDICATES 4HAT 4HE $ESIGN $ETAIL )S 3UPPORTED 2EITERATE &ROM !LL $ESIGN $ETAILS "ASED 5PON !SSUMPTIONS .OW 5NTIL !LL $ESIGN $ETAILS "ASED 5P /N 6OLUNTARILY !SSIGNED $ATA !NDOR 3IMPLIFYING 6ALIDATED !SSUMPTIONS !RE 6ALIDATED 4AKING 4HE 'OALS )DENTIFIED 5NDER 3ECTION !ND 4OGETHER 7ITH 4HE #ONSTRAINTS ,ISTED 5NDER 3ECTION !ND 4HE 0ERFORMANCE 3PECIFICATION 3ET /UT 5NDER &ORMULATE (YPOTHESES &ORMULATED (YPOTHESES #ALCULATED 4O &ACILITATE 6ALIDATION /F 4HE /VERALL $ESIGNS 5NDER &OR %ACH (YPOTHESIS 5NDER $EVISE !N %XPERIMENT 4O 4EST 4HE (YPOTHESIS !ND $ESIGN &OR %XPERIMENT /R 3TUDY 2EADY 6ALIDATE 4HE $ESIGN 3EE .OTE !FTER !SSEMBLE 4HE #OLLECTION /F 0ROPOSED %XPERIMENTS /R 3TUDIES 0REPARED 5NDER 6ALIDATION 0ROGRAM 2EADY )NTO ! 6ALIDATION 0ROGRAM $ISTINGUISH "ETWEEN 6ALIDATION %XPERIMENTS /R 3TUDIES 4O "E #ARRIED /UT "EFORE 3TUDIES 4O "E #ARRIED /UT "EFORE #OMMUNICATION /F #OMMUNICATION /F 4HE &INAL $ESIGN 3OLUTIONS !ND 4HOSE 7HICH -UST "E #ARRIED /UT /N 4HE &INAL $ESIGN 3OLUTIONS )DENTIFIED -ANUFACTURED -ODELS /R 0ROTOTYPES 3TUDIES 4O "E #ARRIED /UT /N 0ROTOTYPES )DENTIFIED 3ELECT !N !PPROPRIATE 6ALIDATION %XPERIMENT /R 3TUDY &ROM 4HE ,IST /F 4HOSE 7HICH !RE 4O "E %XPERIMENT /R 3TUDY #OMPLETE #ARRIED /UT "EFORE #OMMUNICATION /F 4HE &INAL $ESIGN 3OLUTIONS !ND #ONDUCT %XPERIMENT 7HERE 4HE %XPERIMENT /R 3TUDY 3HOWS 4HAT 4HE $ESIGN )S )NVALID 4HEN 2EWORK &ROM $ESIGN 3HOWN 4O "E )NVALID 7HERE 4HE %XPERIMENT /R 3TUDY )NDICATES 4HAT 4HE $ESIGN )S 3UPPORTED 2EITERATE &ROM %XPERIMENT /R 3TUDY )NCONCLUSIVE 7HERE 4HE $ESIGN )S 3UPPORTED 2EITERATE &ROM 5NTIL !LL 3TUDIES 4O "E #ARRIED /UT !LL 6ALIDATION 3TUDIES 4O "E #ARRIED /UT "EFORE "EFORE #OMMUNICATION /F 4HE &INAL $ESIGN 3OLUTIONS !RE #OMPLETE #OMMUNICATION /F 4HE $ESIGN #OMPLETE 0REPARE ! 2EPORT /N 4HOSE 6ALIDATION %XPERIMENTS /R 3TUDIES 7HICH !RE 4O "E #ARRIED /UT /N 2EPORT /N 6ALIDATION 3TUDIES 4O "E #ARRIED /UT /N -ODELS /R 0ROTOTYPES -ANUFACTURED -ODELS /R 0ROTOTYPES .OW 2EADY
111 0HASE
#OMMUNICATION
$EFINE #OMMUNICATION .EEDS 3ELECT #OMMUNICATION -EDIUM 0REPARE #OMMUNICATION
N
N
N N
)TEM !CTIVITY !CTIVITY .O %VENT
#OMMUNICATION
$EFINE #OMMUNICATION .EEDS 2EFERRING 4O )NSTRUCTIONS 3EE !ND !NY 3UBSEQUENT !MENDMENTS !T !DDRESSEE !ND #HANNEL &OR #OMMUNICATION $ETERMINED !NDOR $ETERMINE !DDRESSEE !ND #HANNEL &OR #OMMUNICATION /F $ESIGN 3IMILARLY 2EFERRING 4O )NSTRUCTIONS !ND !LSO 4O #OURSE /F !CTION !DOPTED 3EE !ND $EPTH /F $ETAIL &OR #OMMUNICATION $ETERMINED 3UBSEQUENT !MENDMENTS !T !ND $ETERMINE 7HETHER 4HE 'ENERAL 3PIRIT 4HE 'EOMETRY !ND 0ERFORMANCE /R 4HE $ETAILED #ONSTRUCTION /F 4HE $ESIGN )S 4O "E #OMMUNICATED 2EFERRING 4O 4HE $EFINITION /F 4HE $ESIGN )DEA !ND 4HE 3TATEMENT /F 4HE 2ANGE /F -ATTER &OR #OMMUNICATION !PPRAISED 6ARIATION %MBRACEABLE "Y 4HE $ESIGN )DEA !ND !LSO 4O 4HE $EVELOPED /VERALL 3OLUTIONS !PPRAISE 7HAT )S 4O "E #OMMUNICATED
3ELECT #OMMUNICATION -EDIUM ,IST !LL #OMMUNICATION -EDIA !VAILABLE ,IST /F #OMMUNICATION -EDIA 2EADY 2EFERRING 4O #OMMUNICATION .EEDS 3ECTION 3ELECT 3UITABLE -EDIA &ROM 4HE ,IST ,IST /F 3UITABLE -EDIA 2EADY 0REPARED 5NDER 2EFERRING 4O 4IMETABLE !ND &ACILITIES 3ELECT -EDIUM 4O "E 5SED )N -EDIUM &OR #OMMUNICATION 3ELECTED #OMMUNICATING 4HE $ESIGN 2EAPPRAISE !ND )F .ECESSARY 2EFORMULATE #OURSE /F !CTION 0REVIOUSLY 3ET /UT )N #OURSE /F !CTION 2EFORMULATED
0REPARE #OMMUNICATION 2EFERRING 4O ,IST 7HAT )S 4O "E #OMMUNICATED ,IST /F -ATTER &OR #OMMUNICATION 2EFERRING 4O #OMMUNICATION .EEDS !ND !ND )N 4ERMS /F 4HE -EDIUM )TEM $ESCRIBED $ESCRIBE %ACH )TEM 5NDER 0REPARE ! 3CHEDULE /R +EY $IAGRAM /F !LL )TEMS $ESCRIBED )TEM 3CHEDULE &OR +EY 2EADY 0REPARE ! 3CHEDULE /R +EY $IAGRAM /F !LL $OCUMENTS /R /THER -EDIA &ORMING 0ART $OCUMENT 3CHEDULE /R +EY 2EADY /F /R 2EFERRED 4O )N 4HE #OMMUNICATION "OTH 7ITHIN %ACH /F !ND "ETWEEN 4HE 4WO 3CHEDULES !ND )NDEX !LL )TEMS 3O 3CHEDULES #ROSS )NDEXED 4HAT "OTH 4HE #ORRELATION !ND 4HE 4RACING /F 4HE #ONSEQUENCES /F !NY 3UBSEQUENT 2EVISION !RE &ACILITATED #HECK %ACH $OCUMENT /R /THER -EDIUM &OR !NY $EFICIENCY )N 4HE )TEMS $ESCRIBED $OCUMENT #ONTENTS #HECKED #HECK %ACH $OCUMENT /R /THER -EDIUM &OR !NY $EFICIENCY )N 4HE -EDIUM )TSELF $OCUMENT 1UALITY #HECKED 2EFERRING 4O #OMMUNICATION .EEDS %XAMINE #OMPLETED #OMPLETED #OMMUNICATION %XAMINED #OMMUNICATION 2EAPPRAISE !ND )F .ECESSARY 2EFORMULATE #OURSE /F !CTION 2EAPPRAISED !T #OURSE /F !CTION 2EFORMULATED
112 0HASE #ONTINUED
#OMMUNICATION #ONTINUED 7INDING 5P
0REPARE #OMMUNICATION #ONTINUED 7IND 5P 0ROJECT #LOSE 2ECORDS
)TEM !CTIVITY !CTIVITY .O %VENT
4RANSMIT )NFORMATION 2ECORD #OPIES 2EADY -AKE 3ECURITY !NDOR 2ECORD #OPIES /F !LL $OCUMENTS /R /THER -EDIA #OMMUNICATION 3ET #OMPILED #OMPILE 4HE #OMMUNICATION 3ET #HECK &OR #OMPLETENESS #OMMUNICATION 3ET $ISPATCHED %NCLOSE !DDRESS !ND $ISPATCH 4HE #OMMUNICATION !DVICE .OTE $ISPATCHED !DVISE $ISPATCH /F #OMMUNICATION 4HROUGH !N !LTERNATIVE #HANNEL )N 4HE #ASE /F 3KETCH $ESIGNS 0REPARED 5NDER #ONTINUE .OW &ROM )N 4HE #ASE /F &INAL $ESIGN 3UBMISSIONS !WAIT !UTHORITY 4O 4ERMINATE 0ROJECT /R 7HERE .ECESSARY 2EITERATE &ROM
7INDING 5P
7IND 5P 0ROJECT #OMMUNICATION &ILED ,ABEL !ND 3TORE #OPY /F 4HE #OMMUNICATION !S $ISPATCHED !UXILIARY 4RANSACTIONS #OMPLETE #OMPLETE #OPYRIGHT /R /THER !UXILIARY 4RANSACTIONS &INANCIAL 4RANSACTIONS !ND "OOK +EEPING #OMPLETE #OMPLETE &INANCIAL 4RANSACTIONS !ND "OOK +EEPING #ORRESPONDENCE #LOSED &ORMALLY $ISCHARGE /BLIGATIONS !ND #LOSE #ORRESPONDENCE 0ROJECT #LOSED $ISENGAGE &ROM 0ROBLEM !ND #LOSE 0ROJECT
#LOSE 2ECORDS -ATERIALS !ND %QUIPMENT $ISPOSED /F 3TORE 2ETURN $ISPOSE /F /R 7RITE /FF !LL 2EMAINING -ATERIALS !ND %QUIPMENT 2EDUNDANT -ATERIAL $ISPOSED /F $ESTROY !LL /BSOLETE !ND 4RANSITORY -ATERIAL 2ECORDS 3TORED #OLLATE ,ABEL !ND 3TORE !LL 2ECORDS !PPRAISAL /F %XPERIENCE #OMPLETE !PPRAISE %XPERIENCE 'AINED !ND !DJUST 3YSTEMS !ND 3TANDARDS
113 Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972)
In this model, Koberg and Bagnall have added feedback Koberg and Bagnall go on to describe alternatives: viewing to their seven-stage model. (See page 16.) They note “one the design process as a branching system, and then as a stage need not follow another . . . It is also possible that the “horse race” where each stage proceeds concurrently rather stages can be considered in other ways . . . It could be cir- than a “mule train” where each stage proceeds one after the cular . . . Others see it as a constant feedback system where next. Finally, they note, “Process never ends . . . its ultimate you never go forward without always looping back to check model is the spiral, a continuum of sequential round trips on yourself; where one progresses by constant backward that go on ad infi nitum.” relationships; and where the stages of the process advance somewhat concurrently until some strong determining vari- able terminates the process (time, money, energy, etc.)”
!CCEPT 3ITUATION
!NALYZE
$EFINE
)DEATE
3ELECT
)MPLIMENTATION
%VALUATE
114 Cyclic models
We tend to think of a process in terms of steps—as a sequence. But designers require feedback, and most design processes include feedback loops. In this section we examine models emphasizing feedback and continuous improvement.
115 Process with feedback (archetype)
This simple model recalls our fi rst process model. (See page This happens all the time in design—at many levels. (See 12.) What’s added is a feedback loop. More precisely, some the previous spread.) We should be careful not to mistake of the output signal is split off and “fed back” into the input this schematic diagram (or circuit diagram) for the actual signal. design process. I include it here to underscore the impor- tance of feedback in designing.
)NPUT 0ROCESS /UTPUT
&EEDBACK
116 Goal-action-feedback loops after Pangaro (2002)
Paul Pangaro describes feedback loops in terms of a goal- Designers follow this cycle. They have goals, act to accom- action-effect-measurement cycle. In this model, a system plish them, and measure their results to see if they meet their acts to accomplish a goal within its environment. The system goals—goal-action-feedback. We’ve seen several analogs of measures the effect its actions have on the environment and this process—defi ne-prototype-evaluate and design-build- compares the effect to its goal. Then the system looks for test. (See pages 50-51.) errors and acts (or re-acts) to correct them. By repeating the cycle, the system converges on a goal or maintains a steady Feedback is a central subject of cybernetics, the science of state. Feedback is the information loop fl owing from the sys- goal-directed systems. Cybernetics has much to teach us tem through the environment and back into the system. (For about fundamental structures of design. example, a boat pilot tacking to reach port or a thermostat turning a heater on and then off.)
'OAL $ESIRED 3TATE
-EASUREMENT THROUGH SYSTEM THROUGH ENVIRONMENT !CTION 3YSTEM MEASURES ITS PROGRESS 3YSTEM ATTEMPTS TO REACH A GOAL COMPARING CURRENT STATE TO DESIRED STATE BASED ON FEEDBACK DETERMINING THE DIFFERENCE IT MODIFIES ITS ACTIONS AND ATTEMPTING TO CORRECT THE @ERROR 3YSTEM ACTS BOTH WITHIN ITSELF AND ON ITS ENVIRONMENT
&EEDBACK TRANSFER OF INFORMATION
%FFECT #URRENT 3TATE
117 Second-order feedback loops after Pangaro (2002)
The model on the previous page assumes a constant goal. measures the room temperature and decides whether to That is, it provides no mechanism for changing or refi ning raise or lower the set-point on the thermostat.) the system’s goal. Typically, such systems are mechanical (or electronic) and require humans to set their goals. (For As we’ve seen, designing involves not only achieving goals example, defi ning the set-point for a thermostat.) The human but also defi ning them. Thus we may improve our model of creates a second loop in which the “action” is setting the designing by nesting our original feedback loop within a sec- goal of the fi rst loop. (Like the thermostat, the human also ond feedback loop. See the next page for an example.
'OAL $ESIRED 3TATE
-EASUREMENT THROUGH BOTH SYSTEMS THROUGH ENVIRONMENT !CTION 3ECOND ORDER SYSTEM MEASURES THE 3ECOND ORDER SYSTEM ATTEMPTS TO REACH ITS GOAL EFFECT OF THE FIRST ORDER SYSTEMS ACTION BY CONTROLLING THE GOAL OF A FIRST ORDER SYSTEM "ASED ON THAT INFORMATION THE SECOND 'OAL ORDER SYSTEM MODIFIES ITS ACTION n $ESIRED 3TATE RESETTING THE GOAL OF THE FIRST ORDER SYSTEM
&EEDBACK ,OOP TRANSFER OF INFORMATION
-EASUREMENT THROUGH THE FIRST ORDER SYSTEM THROUGH ENVIRONMENT !CTION 3YSTEM MEASURES ITS PROGRESS &IRST ORDER SYSTEM ATTEMPTS TO REACH A GOAL COMPARING CURRENT STATE TO DESIRED STATE BASED ON FEEDBACK IT MODIFIES ITS ACTIONS DETERMINING THE DIFFERENCE 4HE FIRST ORDER SYSTEM ACTS BOTH WITHIN ITSELF AND ATTEMPTING TO CORRECT THE @ERROR AND ON ITS ENVIRONMENT
&EEDBACK ,OOP TRANSFER OF INFORMATION
%FFECT #URRENT 3TATE
118 Bootstrapping or improving improvement after Douglas Engelbart (1992)
In 1992, Douglas Engelbart offered “an optimized bootstrap- activity, which is an improving of the improvement process. ping approach for drastically improving on any organization’s His paper ‘Toward High-Performance Organizations: A Stra- already existing improvement processes.” tegic Role for Groupware’ argues that highest payoff comes from engaging in that C-activity.” According to his foundation, Bootstrap.org, the process works as follows, “Referring to an organization’s principal Levels A, B, and C are analogous to fi rst-, second-, and work as an A-activity and to ordinary efforts at process im- third-order feedback loops. provement as a B-activity, he denotes bootstrapping as a C-
GOAL IMPROVE MEANS OF IMPROVEMENT
OBSERVE SUCCESS CODIFY ROLL OUT
CORPORATE QUALITY MANAGEMENT PROCESS
GOAL IMPROVE LOCAL PROCESS
OBSERVE PROBLEM PROTOTYPE TEST CHANGE
LOCAL QUALITY MANAGEMENT PROCESS
GOAL MAINTAIN QUALITY OUTPUT
INPUT PRODUCTION OUTPUT
LOCAL PROCESS
119 Product development process after Stuart Pugh (1990)
Pugh published this model in his book, Total Design: Inte- grated 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
#ONCEPT 3ELECTION $ATA (ANDLING
$ETAIL $ESIGN
/PTIMIZATION #OST 0ATTERNS
-ANUFACTURE
-ARKET 4RENDS
3ELL
120 Iconic model of the design process after Mihajlo D. Mesarovic (1964)
In this model, Mesarovic employs a helix as the central struc- feedback loops among them, requires that objective per- ture, suggesting both a repeated cycle of steps and progress formance criteria can be explicitly stated in a manner that through time. fundamentally guides the procedure. Moreover, there is a strong implication that the eventual synthesis of information Peter Rowe (1987) notes that Mesarovic’s model is similar in the form of some designed object follows in a straightfor- in structure to Asimow’s. (See pages 92-95.) “Throughout ward fashion from analysis of the problem at hand together this kind of account runs the assumption that it is possible with likely performance criteria. Therefore, once a problem to discriminate distinct phases of activity and, further more, has been defi ned, its solution is made directly accessible in that such distinctions have relevance to our understanding of terms of that defi nition.” Rowe describes this view as “be- design.” Rowe continues, “The very maintenance of distinct haviorist” and also links it to “operations research”. phases of activity, with a beginning and an end, and with
!
# 3 !BSTRACT $EFINITION OF .EED
%
&EASIBILITY 3TUDY
0RELIMINARY $ESIGN
$ETAILED $ESIGN
0RODUCTION 0LANNING
(OST %NVIRONMENT #ONCRETE 0RODUCTION
!NALYSIS #OMMUNICATION 3YNTHESIS %VALUATION
121 Spiral model of software development after Barry Boehm (1986)
Boehm represented repeating cycles of design with a spiral steps. The angular dimension represents the progress made path moving away from a center starting point. in completing each cycle. Each loop of the spiral from x-axis clockwise through 360 represents one phase. One phase is In addition to the spiral shape, Boehm introduces a focus on split roughly into four sectors of major activities risk reduction. Gary Schmidt of Washburn University offers - Objective setting this description of Boehm’s model, “The radial dimension of - Risk assessment and reduction the model represents the cumulative costs when fi nishing the - Development and validation - Planning the next phases”
$ETERMINE /BJECTIVES %VALUATE !LTERNATIVES !LTERNATIVES AND #ONSTRAINTS )DENTIFY AND 2ESOLVE 2ISKS
2ISK !NAYLSIS
2ISK !NAYLSIS
2ISK !NAYLSIS
2ISK !NAYLSIS 0ROTOTYPE 0ROTOTYPE /PERATIONAL
2EQUIREMENT 0LAN #ONCEPT 3IMULATIONS -ODELS AND "ENCHMARKS
$EVELOPMENT 0LAN 2EQUIREMENTS 6ALIDATION
)NTEGRATION AND 4EST 0LAN $ESIGN 6ALIDATION AND 6ERIFICATION
&INAL #ODE )MPLEMENTATION AND 4EST
0LAN .EXT 0HASES $EVELOP AND 6ERIFY
122 BodyMedia product development process after Chris Pacione (2002)
In his book, What Is Web Design?, Nico MacDonald (2003) published a similar model Pacione developed for his compa- ny, BodyMedia. MacDonald notes, “The model requires that the product must be the right thing to make, posits designers as synthesizers and indicates the relationship with users is on-going.” Note also Pacione’s variation on the 4Ds—in this case defi ne-design-delve-determine. (See page 62.)
4HE "ODY-EDIA 0RODUCT $EVELOPMENT 0ROCESS -ODEL $ETERMINE $EFINE IS BASED ON $R "ARRY "OEHMS 3PIRAL METHOD AND IS DESIGNED TO PROMOTE
FLEXIBILITY PARALLEL WORK CONSTANT AND CLEAR COMMUNICATION EFFICIENCY SERENDIPITY AND SYNERGY ( MULTIPLE ITERATIONS RAPID PROTOTYPING SMART HUMAN CENTRIC SOLUTIONS RISK MANAGEMENT PREDICTABILITY $
' # ! % )
-ORE GENERAL ,ESS GENERAL LESS SPECIFIC ISSUES MORE SPECIFIC ISSUES " NO DETAILS 5) DETAILS ARCHITECTURE CODE DEBUGGING SKETCHES CONTENT TWEAKS & ROUGH DRAFT OF CONTENT QUICK PROTOTYPES ,AUNCH
$ESIGN AND CONTENT FREEZE
* #ODE FREEZE $ELVE $ESIGN
! $EFINE "RAINSTORM AND +ICKOFF ! " $ESIGN THE )NFORMATION !RCHITECTURE AND QUICK INTERACTIVE PROTOTYPES " # $ELVE INTO PROTOTYPE AND TEST THE USEFULLNESS OF THE IDEA # $ $ETERMINE THE WEAKNESS STRENGTHS AND RISKS TIME CONSTRAINTS $ % $EFINE NEW ALTERNATIVES AND SOLUTIONS % & $ESIGN UPDATE ARCHITECTURE CONTENT CODE AND 5) OF INTERACTIVE PORTOTYPE & ' $ELVE INTO REFINED SOLUTION TEST FOR USABILITY AND MAJOR BUGS ' ( $ETERMINE SOLUTIONS WEAKNESSES STRENGHTS RISKS TIME CONSTRAINTS ( ) $EFINE WHAT NEEDS TO CAN CHANGE WITH CODE 5) ) * $ESIGN $ESIGN AND CONTENT FREEZES ALL SPECS DUE #ODE FREEZE * &INAL TESTING AND 1! ,AUNCH
123 Design process after Paul Souza (1996)
Souza also used a spiral path to represent repeating cycles in the design process. In Boehm’s model, the spiral travels out from the center suggesting—though perhaps not inten- tionally—that the process diverges. Traveling outward could also suggest adding increasing amounts of detail. In Souza’s model, the path travels in toward the center suggesting the process converges on a goal.
124 Innovation planning after Vijay Kumar (2003)
Kumar presented this model at the 2003 HITS Conference to concept—from aha to eureka—describing it as a revela- (Humans, Interaction, Technology, Strategy) in Chicago. He tion, magic, genius, intuition, a hunch. described modes of planning (rather than steps) emphasizing the iterative and interconnected nature of the design pro- Kumar teaches at the Illinois Institute of Technology’s Insti- cess. He has also mapped tools and methods onto each of tute of Design; his teaching and research includes a focus the modes. He spoke of innovation as the jump from insight on understanding innovation.
!NALYSIS !BSTRACT 3YNTHESIS
&RAME %XPLORE -AKE )NSIGHTS #ONCEPTS 0LANS h!HAv h%UREKAv
+NOW (YPOTHESIS -AKE
+NOW +NOW 2EALIZE 0ROTOTYPE 5SER #ONTEXT /FFERINGS 0ILOT [,AUNCH
)MPLEMENT
2ESEARCH 2EAL $ELIVERY
125 Rational Unifi ed Process iteration cycle after Per Kroll (2004)
Iteration is a central principle of the Rational unifi ed process. Knoll suggests four principles: Kroll notes, “Each iteration includes some or most of the 1. Build functional prototypes early. development disciplines (requirements, analysis, design, 2. Divide the detailed design, implementation and test implementation and [testing activities]. Each iteration also phases into iterations. has a well-defi ned set of objectives and produces a partial 3. Baseline an executable architecture early on. working implementation of the fi nal system. And each suc- 4. Adopt an iterative and risk-driven management process. cessive iteration builds on the work of previous iterations to evolve and refi ne the system until the fi nal product is Kroll is director of the Rational Unifi ed Process development complete. Early iterations emphasize requirements as well as and product management teams at IBM. (For another model analysis and design; later iterations emphasize implementa- of RUP, see page 67.) tion and testing.”
2EQUIREMENTS
"USINESS -ODELING !NALYSIS AND $ESIGN
0LANNING #ONFIGURATION AND #HANGE )MPLEMENTATION -ANAGEMENT
%NVIRONMENT )NITIAL 0LANNING 4EST
%VALUATION $EPLOYMENT
126 Extreme programming planning/feedback loops after Don Wells (2000)
Extremeprogramming.org published this hypertext model depicting nested feedback loops within the XP development process. The length of each loop increases from bottom to top of the model. The model also serves as a sort of table of contents for key ideas in extreme programming. (For other models of extreme programming, see pages 70-71.)
2ELEASE 0LAN
-ONTHS
)TERATION 0LAN
7EEKS
!CCEPTANCE 4EST
$AYS
3TAND 5P -EETING
/NE $AY
0AIR .EGOTIATION
(OURS
5NIT 4EST
-INUTES
0AIR 0ROGRAMMING
3ECONDS
#ODE
127 Engineering design process after Atila Ertas and Jesse C. Jones (1996)
This model is interesting in its use of the gear metaphor. Did the authors intend to frame design as a mechanical pro- cess? It’s also unusual to see a model begin with synthesis— or include “materials selection” at the same level of abstrac- tion. The inclusion of the six considerations or constraints is also unusual.
2ELIABILITY -AINTAINABILITY
3YNTHESIS !NALYSIS
!VAILABILITY 4HE $ESIGN 0ROCESS $EPENDABILITY
4ESTING -ATERIAL 3ELECTION
#OST "ENEFIT -ANUFACTURABILITY
128 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.
0RODUCT 2ELEASE 0LANNING
2EQUIREMENTS
3YSTEM 4EST
$EVELOPMENT $ESIGN
/UR &OCUS /THER %LEMENTS OF THE #USTOMER %XPERIENCE n 5SER ANALYSIS REQUIREMENTS n /RDERING DELIVERY n 0RODUCT DEFINITION DESIGN n $OCUMENTATION AND DEVELOPMENT FOR EASE OF USE n )NSTALLATION AND USEFULNESS n )NTEGRATION WITH RD PARTY PRODUCTS n #USTOMER SUPPORT
129 PDCA quality cycle after Walter A. Shewart (1939)
PDCA stands for plan-do-check-act cycle of continuous Edward Deming worked with Shewhart at Bell Laboratories improvement, a standard principle of quality assurance and and later popularized the PDCA cycle, especially in Japan. management. It is also known as the Shewhart cycle or the Deming substituted “study” for “check”. PDCA and PDSA Deming cycle. have many incarnations and many defi nitions. For example, the ISO 9001 standard includes the PDCA cycle. Over the The mathematician Walter A. Shewhart was concerned last 20 years, the focus of quality management has expand- with what he called “the formulation of a scientifi c basis for ed from manufacturing processes to include a systemic view securing economic control.” In 1939, he published Statistical of customer satisfaction. Method from the Viewpoint of Quality Control, the fi rst place he discussed the PDCA concept, according to the American Society for Quality (ASQ).
$ETERMINE THE ROOT CAUSE OF THE PROBLEM #ARRY OUT THE CHANGE OR THE TEST THEN PLAN A CHANGE OR A TEST PREFERABLY IN A PILOT OR ON A SMALL SCALE AIMED AT IMPROVEMENT
0LAN $O
!CT #HECK
!DOPT THE CHANGE #HECK IF THE DESIRED RESULT WAS ACHIEVED IF THE DESIRED RESULT WAS ACHIEVED WHAT IF ANYTHING WENT WRONG )F THE RESULT WAS NOT DESIRED AND WHAT WAS LEARNED REPEAT THE CYCLE USING KNOWLEDGE OBTAINED
130 Adaptability loop after Stephan H. Haeckel (2003)
Haeckel proposed this process for managing within a chang- Haeckel’s model may also be interpreted as a variation ing environment. At fi rst, it appears to be a classic feed- on the classic PDCA cycle. It’s interesting to note that the back-based control loop. But the options for action include PDCA cycle also implies but does not represent a process changing goals and thus suggest a more complex process for changing goals. (Some variations on the model include than is represented in the model. it.) The authors may have chosen a simpler representation to make it easy to communicate and remember.
$EPLOYS PROBES AND GATHER A WIDE RANGE OF 5SE A VARIETY OF TECHNOLOGIES AND TECHNIQUE TO SIGNALS FROM HARD DATA TO FINANCAIL REPORTS TO UNDERSTAND THE MEANING OF WHAT YOUR PROBES ARE CONVERSATIONS WITH CUSTOMERS TO SPOT IMPENDING SENSING AND WHY COMMITMENTS BETWEEN ROLES CHANGE IN YOUR BUSINESS ENVIRONMENT YOUR BREAK DOWN &OR EXAMPLE SCENARIO PLANNING CAN CUSTOMERS BUSINESSES AND THEIR CUSTOMERS HELP IDENTIFY AND PREPARE FOR WAYS THE FUTURE MAY BUSINESSES )NTERNALLY TRACK BREAKDOWNS IN YOUR UNFOLD WAR GAMING HELPS LEADERS THINK THROUGH ORGANIZATIONS PERFORMANCE AND VIOLATIONS OF VARIOUS RESPONSES TO CHANGE AND COLLABORATIVE COMMITMENTS AND BASIC RULES 3CAN FOR DECISION MAKING HELPS LEADERS DECIDE HOW TO CAPABILITIES FIRMS IN OTHER INDUSTRIES HAVE THAT YOU ALLOCATE LIMITED RESOURCES IN UNPREDICTABLE MIGHT FIND USEFUL !LL DATA SHOULD BE VIEWABLE ON ENVIRONMENTS 4HIS INFORMATION SHOULD BE 0#S AND HANDHELDS VIEWABLE ON SCREEN
3ENSE )NTERPRET
!CT $ECIDE
!S LEADER PUBLICLY PROCLAIM THE NEW RAISON DÐTRE 3HOULD ORGANIZATIONS RAISON DÐTRE POLICIES BASIC RULES AND ROLES ORIF NO CHANGE IS REQUIRED OR ROLE AND ACCOUNTABILITY DESIGN CHANGE &OR AT THE TIMEAFFIRM THE OLD ONES 7HEN CHANGING EXAMPLE IF COMMITMENTS ARE REPEATEDLY BROKEN ANY ROLES MAKE SURE THE RIGHT PEOPLE EXECUTE IF NEW CAPABILITIES ARENT BEING INCORPORATED ETC THEM AND THAT THEIR COMMITMENTS TO OTHERS WITHIN &REQUENTLY CHALLENGED POLICIES MIGHT NEED TO BE THE ORGANIZATION ARE ADJUSTED TO REFLECT ANY NEW RELAXED TIGHTENED OR ELIMINATED 4HE RAISON DÐTRE DESIRED OUTCOMES ,IKEWISE INSTALL OR UPGRADE MIGHT NEED CHANGING IF THERE ARE BIG OR SUDDEN ELECTRONIC INFORMATION SYSTEMS TO DISPLAY THE SHIFTS IN THE MARKETPLACE OR IN THE VALUES AND UPDATED COMMITMENTS AS WELL AS ANY NEW PREFERENCES OF YOUR MOST IMPORTANT CUSTOMERS hSENSEv AND hINTERPRETv INFORMATION NOW REQUIRED AND OTHER CONSTITUENTS
131 Complete list of models
Introducing process 25 Overall, the design process must converge 10 after Nigel Cross (2000) Design Process after Tim Brennan (~1990) 26 Gradual shift of focus from analysis to synthesis 12 after Bill Newkirk (1981) Process archetype 27 13 Problem to solution: sequence or parallel process or loop? On the infi nite expandability of process models Academic models 14 Design process archetype: Analysis, Synthesis 28 after Koberg and Bagnall (1972) Walking process after Lawson (1980) 15 Problem, Solution 30 after JJ Foreman (1967) Four-stage design process after Nigel Cross (2000) 16 Expanding the two-step process 31 after Don Koberg and Jim Bagnall (1972) Engineering design process after Michael J. French (1985) 17 Matching process to project complexity 32 after Jay Doblin (1987) VDI 2221: System Approach to the Design of Technical Systems and Products 18 after Verein Deutscher Ingenieure (1987) Unself-conscious and self-conscious design after Christopher Alexander (1962) 33 Design process Analysis synthesis evaluation after Gerhard Pahl and Wolfgang Beitz (1984)
20 34 Oscillation Architect’s Plan of Work (schematic) after the Royal Institute of British Architects Handbook (1965) 21 Programming and designing 35 after William M. Pena and Steven A. Parshall (1969) Architect’s Plan of Work, (detailed) after the RIBA Handbook (1965) 22 Diverge / Converge vs Narrow / Expand 36 Problem solving process 23 after George Polya (1945) Decomposition / recombination after VDI 2221 (from Cross 1990) 37 Scientifi c problem solving process 24 after Cal Briggs and Spencer W. Havlick (1976) Dynamics of divergence and convergence after Bela H. Banathy (1996) 38 THEOC, a model of the scientifi c method
132 39 54 Criteria of validation of scientifi c explanations (CVSE) Mechanical engineering design process after Humberto Maturana (1987) after students at UC Berkeley Institute of Design (BID)
40 55 Comprehensive anticipatory design science New product development process after Buckminster Fuller (1978?) after Steven D. Eppinger and Karl T. Ulrich (1995)
41 57 Design Process and Practice Design Process after Richard Buchannan (1997) after John Chris Jones (1970)
42 58 Creative process Value analysis after Bryan Lawson (1980) after John Chris Jones (1970)
43 59 Primary generator Man-machine system designing after Jane Darke (1978) after John Chris Jones (1970)
44 Consultant models Design process after Jane Darke (1978) 60 Eight phases of a project 45 Sometimes presented as six phases of a project Design process after Thomas A. Marcus (1969) and Thomas W Maver (1970) 62 4D software process 47 and variations Process of designing solutions after Clement Mok and Keith Yamashita (2003) 63 IT consulting process overview 48 after Mindtree Consulting Case study, using the AIGA process in Iraq by Nathan Felde (2003) 65 IDEO 49 (2004) What the AIGA didn’t tell you by Nathan Felde (2003) 66 Trees 51 Design, build, test (1 of 3) Software development models after Alice Agogino 68 52 Waterfall lifecycle Design, build, test (2 of 3) after Philippe Kruchten (2004) after Alice Agogino 69 53 Rational Unifi ed Process (RUP) Design, build, test (3 of 3) after Phillippe Kruchten (2003) after Alice Agogino
133 Complete list of models continued
70 87 Extreme Programming (XP) Process Evolution of the software development process after Don Wells (2000) after Alan Cooper (2001)
72 88 V model Goal-directed design process Paul Rock (~1980), IABG (1992) after Alan Cooper (2001)
73 90 Joint Application Development (JAD) Idealized process of developing buildings after Jane Wood and Denise Silver (1995) after Alan Cooper (2004)
74 91 PMBOK (Project Management Body of Knowledge) Idealized process of developing software PMI (Project Management Institute) (1987) after Alan Cooper (2004)
75 93 ISO 13407 Human-centered design processes for interactive Morphology of design systems after Morris Asimow (1962) Tom Stewart et al. (1999) 97 76 Biological sequence of problem solving User-centered design process (UCD) after Bruce Archer (1963-1964) after Karel Vredenburg (2003) 98 77 Basic design procedure Relation of UCD to IPD and Business Management after Bruce Archer (1963-1964) after Karel Vredenburg (2003) 99 78 Check list for product designers Sun Sigma Framework Bruce Archer (1963-1964) DMADV methodology for new products Cyclic models 79 Sun Sigma Framework 114 DMAIC methodology for improving existing products Seven-step process as a cascade with feedback after Don Koberg and Jim Bagnall (1972) 80 Sun Product Lifecycle (PLC) 116 Sun Software Development Framework (SDF) Process with feedback (archetype) “Mapped” processes for product instances 117 81 Goal-action-feedback loops Sun Product Lifecycle (PLC) after Pangaro (2002) Sun Software Development Framework (SDF) “Mapped” processes for product lines 118 Second-order feedback loops Complex linear models after Pangaro (2002)
84 119 Web development process Bootstrapping or improving improvement after Vanguard Group (circa 1999) after Douglas Engelbart (1992)
134 120 Product development process after Stuart Pugh (1990)
121 Iconic model of the design process after Mihajlo D. 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 Unifi ed 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. Shewart (1939)
131 Adaptability loop after Stephan H. Haeckel (2003)
135 Chronological list
130 57 PDCA quality cycle Design Process after Walter A. Shewart (1939) after John Chris Jones (1970)
36 58 Problem solving process Value analysis after George Polya (1945) after John Chris Jones (1970)
18 59 Unself-conscious and self-conscious design Man-machine system designing after Christopher Alexander (1962) after John Chris Jones (1970)
93 14 Morphology of design Design process archetype: Analysis, Synthesis after Morris Asimow (1962) after Koberg and Bagnall (1972)
97 16 Biological sequence of problem solving Expanding the two-step process after Bruce Archer (1963-1964) after Don Koberg and Jim Bagnall (1972)
98 114 Basic design procedure Seven-step process as a cascade with feedback after Bruce Archer (1963-1964) after Don Koberg and Jim Bagnall (1972)
99 37 Check list for product designers Scientifi c problem solving process Bruce Archer (1963-1964) after Cal Briggs and Spencer W. Havlick (1976)
121 43 Iconic model of the design process Primary generator after Mihajlo D. Mesarovic (1964) after Jane Darke (1978)
34 44 Architect’s Plan of Work (schematic) Design process after the Royal Institute of British Architects Handbook (1965) after Jane Darke (1978)
35 40 Architect’s Plan of Work, (detailed) Comprehensive anticipatory design science after the RIBA Handbook (1965) after Buckminster Fuller (1978?)
15 28 Problem, Solution Walking process after JJ Foreman (1967) after Lawson (1980)
45 42 Design process Creative process after Thomas A. Marcus (1969) and Thomas W Maver (1970) after Bryan Lawson (1980)
21 26 Programming and designing Gradual shift of focus from analysis to synthesis after William M. Pena and Steven A. Parshall (1969) after Bill Newkirk (1981)
136 33 73 Design process Joint Application Development (JAD) after Gerhard Pahl and Wolfgang Beitz (1984) after Jane Wood and Denise Silver (1995)
31 24 Engineering design process Dynamics of divergence and convergence after Michael J. French (1985) after Bela H. Banathy (1996)
122 128 Spiral model of software development Engineering design process after Barry Boehm (1986) after Atila Ertas and Jesse C. Jones (1996)
17 41 Matching process to project complexity Design Process and Practice after Jay Doblin (1987) after Richard Buchannan (1997)
39 124 Criteria of validation of scientifi c explanations (CVSE) Design process after Humberto Maturana (1987) Paul Souza (1999?)
74 75 PMBOK (Project Management Body of Knowledge) ISO 13407 Human-centered design processes for interactive PMI (Project Management Institute) (1987) systems Tom Stewart et al. (1999) 32 VDI 2221: System Approach to the Design of Technical 84 Systems and Products Web development process after Verein Deutscher Ingenieure (1987) after Vanguard Group (circa 1999)
10 129 Design Process Product development process: overview after Tim Brennan (~1990) Hewlett Packard (circa 2000)
23 25 Decomposition / recombination Overall, the design process must converge after VDI 2221 (from Cross 1990) after Nigel Cross (2000)
120 30 Product development process Four-stage design process after Stuart Pugh (1990) after Nigel Cross (2000)
119 70 Bootstrapping or improving improvement Extreme Programming (XP) Process after Douglas Engelbart (1992) after Don Wells (2000)
72 127 V model Extreme programming planning/feedback loops Paul Rock (~1980), IABG (1992) after Don Wells (2000)
55 87 New product development process Evolution of the software development process after Steven D. Eppinger and Karl T. Ulrich (1995) after Alan Cooper (2001)
137 Chronological list continued
88 91 Goal-directed design process Idealized process of developing software after Alan Cooper (2001) after Alan Cooper (2004)
123 65 BodyMedia product development process IDEO after Chris Pacione (2002) (2004)
117 126 Goal-action-feedback loops Rational Unifi ed Process iteration cycle after Pangaro (2002) Per Kroll (2004)
118 68 Second-order feedback loops Waterfall lifecycle after Pangaro (2002) 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. Haeckel (2003)
69 Rational Unifi ed 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 Dates not found Produced for this book (2004)
51 116 Design, build, test (1 of 3) Process with feedback (archetype) after Alice Agogino 52 12 Design, build, test (2 of 3) Process archetype after Alice Agogino 13 53 On the infi nite expandability of process models Design, build, test (3 of 3) after Alice Agogino 19 *Analysis synthesis evaluation 54 Mechanical engineering design process 20 after students at UC Berkeley Institute of Design (BID) Oscillation
60 22 Eight phases of a project Diverge / Converge vs Narrow / Expand Sometimes presented as six phases of a project 27 62 Problem to solution: sequence or parallel process or loop? 4D software process and variations 38 THEOC, a model of the scientifi c 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 Author list
51 87 Design, build, test (1 of 3) Evolution of the software development process after Alice Agogino after Alan Cooper (2001)
52 88 Design, build, test (2 of 3) Goal-directed design process after Alice Agogino after Alan Cooper (2001)
53 90 Design, build, test (3 of 3) Idealized process of developing buildings after Alice Agogino after Alan Cooper (2004)
18 91 Unself-conscious and self-conscious design Idealized process of developing software after Christopher Alexander (1962) after Alan Cooper (2004)
97 25 Biological sequence of problem solving Overall, the design process must converge after Bruce Archer (1963-1964) after Nigel Cross (2000)
98 30 Basic design procedure Four-stage design process after Bruce Archer (1963-1964) after Nigel Cross (2000)
99 43 Check list for product designers Primary generator Bruce Archer (1963-1964) after Jane Darke (1978)
93 44 Morphology of design Design process after Morris Asimow (1962) after Jane Darke (1978)
24 17 Dynamics of divergence and convergence Matching process to project complexity after Bela H. Banathy (1996) after Jay Doblin (1987)
122 119 Spiral model of software development Bootstrapping or improving improvement after Barry Boehm (1986) after Douglas Engelbart (1992)
10 55 Design Process New product development process after Tim Brennan (~1990) after Steven D. Eppinger and Karl T. Ulrich (1995)
37 128 Scientifi c problem solving process Engineering design process after Cal Briggs and Spencer W. Havlick (1976) after Atila Ertas and Jesse C. Jones (1996)
41 48 Design Process and Practice Case study, using the AIGA process in Iraq after Richard Buchannan (1997) by Nathan Felde (2003)
140 49 126 What the AIGA didn’t tell you Rational Unifi ed Process iteration cycle by Nathan Felde (2003) Per Kroll (2004)
131 69 Adaptability loop Rational Unifi ed Process (RUP) after Stephan H. Haeckel (2003) after Phillippe Kruchten (2003)
15 68 Problem, Solution Waterfall lifecycle after JJ Foreman (1967) after Philippe Kruchten (2004)
31 125 Engineering design process Innovation planning after Michael J. French (1985) after Vijay Kumar (2003)
40 28 Comprehensive anticipatory design science Walking process after Buckminster Fuller (1978?) after Lawson (1980)
129 42 Product development process: overview Creative process Hewlett Packard (circa 2000) after Bryan Lawson (1980)
65 45 IDEO Design process (2004) after Thomas A. Marcus (1969) and Thomas W Maver (1970)
57 39 Design Process Criteria of validation of scientifi c explanations (CVSE) after John Chris Jones (1970) after Humberto Maturana (1987)
58 121 Value analysis Iconic model of the design process after John Chris Jones (1970) after Mihajlo D. Mesarovic (1964)
59 63 Man-machine system designing IT consulting process overview after John Chris Jones (1970) after Mindtree Consulting
14 47 Design process archetype: Analysis, Synthesis Process of designing solutions after Koberg and Bagnall (1972) after Clement Mok and Keith Yamashita (2003)
16 26 Expanding the two-step process Gradual shift of focus from analysis to synthesis after Don Koberg and Jim Bagnall (1972) after Bill Newkirk (1981)
114 123 Seven-step process as a cascade with feedback BodyMedia product development process after Don Koberg and Jim Bagnall (1972) after Chris Pacione (2002)
141 Author list continued
33 78 Design process Sun Sigma Framework after Gerhard Pahl and Wolfgang Beitz (1984) DMADV methodology for new products
117 79 Goal-action-feedback loops Sun Sigma Framework after Pangaro (2002) DMAIC methodology for improving existing products
118 80 Second-order feedback loops Sun Product Lifecycle (PLC) after Pangaro (2002) Sun Software Development Framework (SDF) “Mapped” processes for product instances 21 Programming and designing 81 after William M. Pena and Steven A. Parshall (1969) Sun Product Lifecycle (PLC) Sun Software Development Framework (SDF) 74 “Mapped” processes for product lines PMBOK (Project Management Body of Knowledge) PMI (Project Management Institute) (1987) 84 Web development process 36 after Vanguard Group (circa 1999) Problem solving process after George Polya (1945) 76 User-centered design process (UCD) 120 after Karel Vredenburg (2003) Product development process after Stuart Pugh (1990) 77 Relation of UCD to IPD and Business Management 34 after Karel Vredenburg (2003) Architect’s Plan of Work (schematic) after the Royal Institute of British Architects Handbook (1965) 32 VDI 2221: System Approach to the Design of Technical 35 Systems and Products Architect’s Plan of Work, (detailed) after Verein Deutscher Ingenieure (1987) after the RIBA Handbook (1965) 23 72 Decomposition / recombination V model after VDI 2221 (from Cross 1990) Paul Rock (~1980), IABG (1992) 70 130 Extreme Programming (XP) Process PDCA quality cycle after Don Wells (2000) after Walter A. Shewart (1939) 127 124 Extreme programming planning/feedback loops Design process after Don Wells (2000) Paul Souza (1999?) 73 75 Joint Application Development (JAD) ISO 13407 Human-centered design processes for interactive after Jane Wood and Denise Silver (1995) systems Tom Stewart et al. (1999)
142 Authors not identifi ed Produced for this book (2004)
54 116 Mechanical engineering design process Process with feedback (archetype) after students at UC Berkeley Institute of Design (BID) 12 60 Process archetype Eight phases of a project Sometimes presented as six phases of a project 13 On the infi nite expandability of process models 62 4D software process 19 and variations *Analysis synthesis evaluation
66 20 Trees Oscillation
22 Diverge / Converge vs Narrow / Expand
27 Problem to solution: sequence or parallel process or loop?
38 THEOC, a model of the scientifi c method
143 Bibliography
Alexander, Christopher. Hirschberg, Morton. Notes on the Synthesis of Form “The V Model.” MIT Press, 1964. CrossTalk, The Journal of Defense Software Engineering, June, 2000. Archer, L. Bruce. “Systematic Method for Designers”. ISO 13407: 1999, Human-centered design processes for Design magazine, 1963-1964. interactive systems.
Asimow, Morris. Jones, John Chris. Introduction to Design. Design Methods. Prentice-Hall, 1962. 2d ed., rev. Van Nostrand Reinhold, 1992.
Bagnall, Jim and Koberg, Don. Kroll, Per. Universal Traveler. “Transitioning from waterfall to iterative development.” 2d ed., rev. Crisp Publications, 1990. IBM developerWorks web site, 2004.
Banathy, Bela H. Kruchten, Philippe. Designing Social Systems in a Changing World. “Going Over the Waterfall with the RUP.” Plenum Press, 1996. IBM developerWorks web site, 2004.
Carmel, Erran, Whitaker, Randall D., and George, Joey F. Kruchten, Philippe. “PD and Joint Application Design: A Transatlantic “What Is thee Rational Unifi ed Process?” Comparison.” The Rational Edge e-zine, 2003. Communications of the ACM, Vol. 36, No. 4, June 1993. Lawson, Brian. Cooper, Alan. How Designers Think: The Design Process Demystifi ed. About Face: The Essentials of User Interface Design 2d ed. The University Press: Cambridge, 1991. IDG Books, 1995. Maturana, Humberto R. and Varela, Francisco J. Cooper, Alan. The Tree of Knowledge: The Biological Roots of Human The Inmates Are Running the Asylum: Why High-Tech Understanding. Products Drive Us Crazy and How to Restore the Sanity Shambhala Publications, 1998. SAMS, 1999. MacDonald, Nico. Cross, Nigel. What Is Web Design? Developments in Design Methodology. RotoVision, 2003. John Wiley & Sons, 1984. Nassbaum, Bruce. Cross, Nigel. “The Power of Design” Engineering Design Methods: Strategies for Product Design. Business Week, May 17, 2004. 3d ed. John Wiley & Sons, 2000. Parshall, Steven A. and Peña, William M. Dubberly, Hugh. Problem Seeking: An Architectural Programming Primer. “Alan Cooper and the Goal-directed Design Process,” 4th ed. John Wiley & Sons, 2001. AIGA Gain, Volume 1, Number 2, 2001 Plamondon, Scott. Ertas, Atila , and Jones, Jesse C. “Working smarter, not harder: An interview with Kent Beck.” The Engineering Design Process. IBM developerWorks web site, 2003. 2d ed., John Wiley & Sons,1996. PMI Standards Committee Goldsmith, Robin F. and Graham, Dorothy. A guide to the project management body of knowledge. “The Forgotten Phase.” PMI, 1996. Software Development, July, 2002.
144 Poyla, George. How to Solve It: A New Aspect of Mathematical Method. 2d ed. Princeton University Press, 1988.
Rowe, Peter G. Design Thinking. The MIT Press, 1987.
Silver, Denise and Wood, Jane. Joint Application Development. 2d ed. John Wiley & Sons, 1995.
Simon, Herbert. The Sciences of the Artifi cial. The MIT Press, 1994
Vredenburg, Karel. “Building ease of use into the IBM user experience.” IBM Systems Journal, Vol. 42, No. 4, 2003.
Wells, Don. Extreme Programming: A gentle introduction Extremeprogramming.org web site, 2004.
145 Dubberly Design Offi ce developed this book over many months. It began as a manilla folder with copies of processes. We completed the fi rst “book” version as part of a project undertaken for Elaine Coleman and Sun’s Virtual Center for Innovation. Sun’s Noel Franus and Cindy Yepez were infi nitely patient with the slow pace of work and politely pushed us to add descriptions to each model.
Greg Baker, Ryan Reposar, Audrey Crane, and Hugh Dubberly drew the models. It was Greg who patiently redrew Archer’s huge model bringing the diagram and Archer’s descriptive text together for the fi rst time. Ryan assembled the book and handled the many changes.
We present this version for educational purposes only. We have obtained no permissions to reproduce any of the models. Copyrights remain with their owners.
Copyright © 2004 Dubberly Design Offi ce
146 147