5 The Structure of the

Design Process

5. 1 Introduction The core of designing is reasoning from function to form. Such

reasoning, as we have seen in the preceding chapter, is logically
incorrect, not conclusive. One of the most important tasks of
design methodology is to indicate how design processes should
be arranged so that they nevertheless lead to reliable,effective
conclusions and are efficient as well. This takes us to the structure
of the design process.
The literature on design and product development contains a
variety of models of designing and can therefore give the im-
pression that there is still little agreement on the structure of this
process. However, to a large extent the differences are of a ter-
minological nature. If we examine this, we can distinguish three
types of models, which - each from another point of view - throw
light on a particular aspect of designing. In this chapter we shall
address characteristic examples of each of these types of models.
In the first type, designing is conceived as a specific form of
problem-solving. In problem-solving 'steps' can be distinguished,
which form a cycle that plays a part in each phase of the product
design and product development process. The empirical cycle is
the basic model for problem-solving. Adjusting this cycle to the
process of solving design problems leads to a basic design cycle.
This cycle is the most fundamental model of the design process.
In the second type of models product design is described as a
process)n which the design of a product is worked out on dif-
ferent l~els of abstraction. These levels correspond to various
forms in which a design in the making can be represented, such as
the function structure, the principal solution and the preliminary
design. Such representations of not yet completely worked out
product design stand in a means-end relationship one to another,
84 Product Design: Fundamentals and Methods

upon which the phase models of the design process are founded.
Examples of this approach are the models of French, Pahl and
Beitz, and the VDI (Verein Deutscher Ingenieure).
The third type is the phase models of the product development
process. These comprise activities of the product design process,
as well as of production development and the development of the
marketing plan. The domain of these models is not only the
design of a new product, but the design of the plan for a new
business activity as a whole. In these models the interaction
between the various aspects of product development comes to the
fore. They offer something to hold on to in product design, but
are also very important in managing product development
projects. The product development programme of L. Bruce
Archer is given as a typical example.
The three types of models portray different 'dimensions' of
designing products. The phase models of product design indicate
what kinds of problems the product designer has to solve and .
what the best sequence is therein. The basic design cycle gives the
logical sequence of steps in the problem-solving process within
each phase of product designing. The phase models of product
development teach us what aspects should be taken into account.
The three types of models do not oppose, but supplement one
another.
The triple 'problem-solving-phases-aspects' can be found in
many design theories. As far as we know, the idea comes from A.
D. Hall[l].

5.2 Designing as
Problem Solving

5.2.1 The Empirica' Designing is a special form of problem solving. We speak of 'a
Cycle problem' when someone wants to reach a goal and the means to
do so are not immediately obvious. Problem solving is the process
of thought, in which those means are sought intentionally.
In all forms of problem solving a similar cycle of activities can
be recognized. De Groot[2] calls this cycle 'the empirical cycle' and
characterizes it as follows:

observation-supposition-expectation-testing-evaluation

The cycle begins with the observation of the situation in which

one acts. Having learned from earlier cycles, a problem solver
The Structure of the Design Process 85

entertains suppositions about actions that might solve the

problem, and expectations as to the effects of these actions in the
problem situation. The expected effects are tested - that is to say,
compared with the desired effects (is the effect good or bad?), and
then the problem solver evaluates the result of his thought
process by asking himself: 'what have I learned?' and 'how can I
utilize the experiences gained (in a next cycle)?'
From psychological theories and protocol analyses of human
thought it appears however-present and how indispensable this
cycle is. But, says De Groot, a simple (logical) analysis based on
known facts and common sense is sufficient to show the ne-
cessity of the cycle for problem solving. De Groot's analysis is as
follows:

In all examples of directed thinking, whether it be creative,

analytic or interpretative, there is invariably a goal, or end,
which the subject tries to attain. How to attain this end, is a
problem to him - by definition, since we have assumed that
it requires an effort of thought. Specifically it is a problem in
that the means to attain the end are not readily available or
even immediately evident; they have to be discovered,
inferred, worked out or even created.
When, now, we come to analyze the directed process of
thought and action that is required for the solution of the
problem, it can always be broken down into a sequence of
elaborative phases or steps that serve to solve 'part of the
problem', i.e., to lead nearer to the overall goal. What
happens in an elaborative phase, then, can be interpreted as
applying a means to attain a goal - either the overall goal or an
intermediate one (shift from end to means).
Another general characteristic of any process of directed
thinking, rational action, or creation, is that the subject has a
certain amount of freedom: there are a variety of ways in
which he can try to achieve his end. Furthermore, when
choosing a particular way, i.e. a particular means, there will
mostly be a margin of uncertainty as to the adequacy of the
means envisaged. Whether a certain means serve to secure
the end in view or, at any rate, to further its realization, is a
question that will be answered in the process, namely when
the subject makes a tentative choice of his means, tries it out
empirically, either in reality or through mental simulation,
and finally tests it for its effectiveness. This process, char-
acterized by the sequence: end-problem-means - freedom-
uncertainty-choosing-trying-testing, is repeated over and
over in a series of coordinated cycles[3].

It is not difficult to recognize the empirical cycle in this de-

scription of problem-solving. Characteristic of this cycle is, in the
first place, 'trying'; problem solving - and thus also designing - is
fundamentally a trial-and-error process. Solutions are provision-
86 Product Design: Fundamentals and Methods

ally, tentatively, chosen and tried out, after which the effects are
evaluated and corrective measures taken.
A second important characteristic is that solutions are usually
not tried out in reality, but 'in the imagination'. That is to say:
before a problem-solver decides to indeed realize a solution, he
forms an image of its effects and evaluates those effects, either in
his mind or with the help of some kind of model. De Groot,
therefore, also calls the cycle 'the empirical cycle as reflected'.
Problem solving is not a primitive, unconscious form of trial and
error, in which a randomly chosen action is tried out directly, but
conscious and purposeful 'trying' in the form of a thought
process.
The third important characteristic is the spiral-like develop-
ment of the problem and the solution. To solve a problem, one
generally passes through the cycle many times. The results of the
evaluation of the previous cycle are, beside new observations, the
input data for the next cycle. We can also say this in another way:
after a cycle the problem solver himself has changed somewhat;
he has gained experience, he has learned, and this is expressed in
a following cycle by, among other things, observing the problem
in a different maimer and having other expectations as to the
effects. This characteristic was also clearly evident in the analysis
of the structure of the product development process (Section 2.5).
The empirical cycle as reflected is a fundamental principle that
is found in all sorts of experiential processes. De Groot[4) con-
siders the cycle therefore as a necessary construct, a logically in-
dispensable thought model, that becomes noticeable in every
attempt to come to grips with such phenomena as purposeful
behaviour, learning, problem-solving, directed and creative
thinking, by human beings and, even, machines*.
Yet, the actual implementations of the cycle need not be the
same in different fields. ·De Groot himself sharpens the empirical
cycle into the cycle of empirical scientific inquiry:

observation-induction-deduction-testing-evaluation

*In an excellent paper, in which creative thought is examined within the com-
parative psychology of knowledge processes, Campbell expresses the same
thought. See: Campbell, D., Blind variation and selective retention in creative
thought as in other knowledge processes. In: C. Radnitzky and I. Bartley W. W.
(eds.), Evolutionary Epistemology, Rationality and the Sociology of Knowledge. La Salle,
ill.: Open Court, 1987, pp.91-114. (First published in The Psychological Review
(1960), 67, 380-400.)
The Structure of the Design Process 87

The different names for the elements reflect that this is a cycle
for solving a particular kind of problem, namely problems about
knowledge or Jtheoretical' problems. In this cycle, Jobservation'
stands for the collection and grouping of empirical material and
the (tentative) formation of hypotheses (the psychological induc-
tion process). The phase Jinduction' comprises the precise for-
mulation of hypotheses. In the phase of Jdeduction' special
consequences are inferred therefrom, leading to explicit and
accurate predictions, which are tested, mostly experimentally, on
new empirical material. The 'evaluation' is the interpretation of
the results of the testing in a wider context (do they prOVide
sufficient support for the hypothesis?). In Section 5.5 we shall
compare this cycle with the basic design cycle, in order to uncover
some methodological differences between design and empirical
scientific investigation.
Another special implementation of the empirical cycle is the
problem-solving model of systems engineering, widely known as
the prescriptive model for solving Jpractical' problems. The book
A Methodology for Systems Engineering by HaU[5] contains an ex-
cellent discussion of this cycle and its foundations. Hall's cycle is
as follows:

• problem definition (study of needs and environment);

• value system design (stating objectives and criteria);
• systems synthesis (generating alternatives);
• systems analysis (deducing the consequences of the alter-
natives);
• selecting the best system (by comparing consequences with the
criteria);
• planning for action (implementing the next project phase).

The practical purpose of this cycle appears from the change of

'observation' in (purposeful) Jdefinition of a problem' plus
'stating objectives, and from the change of Jtesting' and 'eva-
luation into 'selecting' and 'planning'.
This problem-solving cycle is already quite close to the basic
design cycle, which lies before us. Both cycles concern the
solution of practical problems, contrary to theoretical problems
that are solved by means of empirical research.

5.2.2 The Basic Design In design, reasoning takes place from goal (the function) to means
Cycle (the design). As in problem-solving in general, in designing many
88 Product Design: Fundamentals and Methods

Function

Crleria

Provisional design

Expected properties

Value of the design

Figure 5.1 The basic

design cycle.
Approved design

means can realize the goal and it is initially uncertain what means
is (the most) effective. It therefore needs no further explanation
.that design is in essence a trial-and-error process that consists of a
sequence of empirical cycles, in which the knowledge of the
problem as well as the solution increases spirally.
We call the model of this cycle 'the basic design cycle' (figure
5.1). As was said, it is a specific implementation of the more
general 'empirical cycle as reflected'. Naturally, the basic design
cycle shows similarities with Hall's cycle of practical problem
solving, but there are differences too:

• Hall's cycle applies to practical problem solving in general,

the basic design cycle is geared to design problems. We
therefore usually do not have the basic design cycle begin
with 'a problem', but with 'the function to be realized',
because this is usually the point of departure for designers.
Apart from that, this is not an essential difference, for the
concepts of 'problem' and 'function' both refer to a dis-
The Structure of the Design Process 89

crepancy to be eliminated between an undesirable initial state

and a desired final state.
• Goals are inherent to the notion of 'problem'. Formulating a
problem without mentioning something of a goal to be reached
is impossible. Hence, 'problem definition' and 'value system
design' have been taken together in the element 'analysis'.
• In the basic design cycle the synthesis step ends in one provi-
sional design and not in different alternatives. Not that
thinking up alternatives would not make sense - in design this
is even an important methodological principle - but because
the cycle is a unity and for each alternative all steps of the cycle
should be taken at least once. In this respect, the basic design
cycle is more fundamental.
• 'Selecting the best system' has been divided into 'evaluation'
(determining the value of a provisional design), and decision (is
a design good enough, to be taken to the next phase or to be
produced?). The decision becomes more complex after some
iterations, and increasingly contains selections. .
• The basic design cycle lacks the implementation step eplanning
for action'). Hall[6] himself gives the reason for this: im-
plementation is a problem-solving process in itself (which is.
again full of design problems!). This step, we believe, does not
belong in a fundamental cycle, which should be applicable
even to the smallest possible design problem:
• And then there are, of course, terminological differences. In-
dustrial designers usually understand 'analysis' to be the
analysis of (information on) a problem, resulting in criteria for
assessing solutions. Engineering designers more often speak of
'analysiS' in the sense of simulating or testing the properties of
a new product. In the basic design cycle we have chosen the
usual terminology of the industrial designers.

We consider the basic design cycle the most fundamental

model of designing. Someone who claims to have solved a design
problem has gone through this cycle at least once. The basic
design cycle also appears to be a useful scheme to classify the
body of rules and methods (the 'methodics') of designing. In Part
III each of the steps of the basic design cycle is treated in a
separate chapter, in which the methodological problems con-
cerned and the most important methods are discussed. Therefore
a short discussion will suffice here. Comparable models of design
as problem solving can be found in, among others, Archer[7,S],
Lewis and Samuel[9], Mannheim[lO] and Rzevski[ll].
90 Product Design: Fundamentals and Methods

Analysis The point of departure in product design is always the function of

the new product, that is, the intended behaviour in the widest
sense of the word. We do not only include the technical function,
but also the psychological, social, economic and cultural functions
that a product should fulfil. The function need not be laid down
in all detail- this is even impossible - but broad statements on the
function must have been made, otherwise the designer does not
know what has to be designed. In Chapter 2 we saw that product
design should be preceded by a product planning phase, which
should yield one or more product ideas with, among other things,
statements on the functions to be fulfilled. In the analysis phase
the designer forms an idea of the. problems around such a new
product idea (the problem statement) and formulates the criteria
that the solution should meet, first broadly and in later iterations
more accurately and completely. The problem statement should
express who has the problem, what is thought to be the problem,
and what causes it. It is also important to know how the pro-
blematic situation will develop if nothing is done, and what
possibilities there are to intervene.
Essential to any problem definition is the goal. In defining a
problem, one will have to form an image of a future situation,
which is to be prefered to the present one. To be able to determine
later whether the proposed solutions are indeed solutions to the
problem, it is desirable to formulate the goal as concretely as
possible in the form of a list of requirements. This list is called the
design specification. A design specification cannot be 'deduced'
from the problem. It is part of the perception that the client, the
designer and other 'stakeholders' have of a certain problem. A
specification comprises all sorts of decisions as to the direction in
which solutions will be sought; writing a specification is therefore
already a genuine design activity. It is - like designing - a re-
ductive process, in which one reasons from a function as the goal
on the one hand, towards the desired properties as the means on
the other hand. One can, therefore, arrive at different, equally
good specifications for one and the same problem.

Synthesis The second step in the basic design cycle is the generation of a
provisional design proposal. The word 'synthesis' means the
f

combining of separate things, ideas, etc., into a complete whole.

Since a design is a new ordering in space of already known ma-
terials, parts and components, tros is what the step is called.
However, a good design is seldom merely a collection of solutions
 The Structure of the Design Process 91

to subproblems; it is an integral solution, which makes sub-

problems disappear, so to speak. French[12] points out the sig-
nificance of integrating ideas, which he calls 'design
philosophies'. The concept of the Moulton bike is a good example
(Moulton was the first to unite small dimensions, a proper stance
and proper riding performance in a new concept of a bicycle).
Synthesis is the least tangible of all phases of the cycle, because
the enigmatic phenomenon of 'human creativity' plays the most
important part. It is the crucial phase, yet this awareness should
not lead to the misconception that the other .phases are not im-
portant or that they can even be skipped. On the contrary, the
cycle is a unity in which the synthesis comes out well only if it is
supported by and implemented in the other phases of the design
cycle. Hence, the result of this phase is called a provisional design;
it is not yet more than a possibility, the value of which can only
become apparent in the later phases of the cycle.
The origination of ideas, seen as a psychological process,
cannot be localized in a particular phase of the basic design cycle.
The synthesis step, therefore, has primarily methodological sig-
nificance: it is the moment of extemalization and description of an
idea, in whatever form (verbally, sketch, drawing, model, etc.).
The place of the synthesis step in the cycle follows from the fact
that the concept of a 'solution' presumes the existence of a
'problem', and from the observation that an explicitly described
provisional design - however general its description - is a pre-
requisite for simulation and evaluation, and thus for qualifying a
provisional design as 'useful' or 'good'.

Simulation Simulation is a deductive subprocess. Simulation is forming an

image of the behaviour and properties of the designed product by
reasoning and/or testing models, preceding the actual manu-
facturing and use of the product. Here, the whole array of tech-
nological and behavioural scientific theories, formulae, tables and
experimental research methods is available to the designer. Yet, in
practice many simulations are based merely on generalizations
from experience. Simulation leads to 'expectations' about the
actual properties of the new product, in the form of conditional
predictions.

. Evaluation In the basic design cycle the term 'evaluation' has the saine
meaning as 'testing' in the empirical cycle. Evaluation is estab-
92 Product Design: Fundamentals and Methods

lishing the 'value' or 'quality' of the provisional design. To do so,

the expected properties are compared with the desired properties
in the design specification. As there will always be differences
between the two, it will have to be judged whether those differ-
ences are acceptable or not. Making such a value judgement is
difficult, for usually many properties are involved. Often a design
proposal excels in part of these properties, while it is weak in
others.

Decision Then follows the decision: continue - that is to say, elaborate the
design proposal or, if it is the final design, manufacture it - or try
again and generate a better design proposal. Usually the first
provisional design will not be a bull's eye and the designer will
have to return to the synthesis step, to do better in a second, third
or tenth iteration. But this is not the only feedback of experience
that is possible within the cycle. One can also go back to the
formulation of the problem and the list of requirements.
Exploring solutions appears to be a forceful aid to gaining
insight into the true nature of a problem[13). In the light of newly
discovered solution variants, one will therefore often want to
adjust, expand, or perhaps sharpen up the initial formulation of
the problem. The design and the design specification are thus
further developed in successive cycles and in a strong interaction,
until they fit one another. Archer has described this process quite
strikingly:

The first thing to recognize is that 'the problem', like any

other ill-defined problem, is not the statement of require-
ments. Nor is 'the solution' the means ultimately arrived at
to meet those requirements. 'The problem' is obscurity about
the requirements, the practicability of envisageable provi-
sions and/or misfit between the requirements and the pro-
visions. The 'solution' is a requirement-provision match that
contains an acceptable small amount of residual misfit and
obscurity. Thus the relationship between design problem
and design requirements and design provision lies along one
axis, and the relationship between design problem and
design solution lies along another axis. The design activity is
commutative, the designer's attention oscillating between the
emerging requirement ideas and developing provision ideas,
as he illuminates obscurity on both sides and reduces misfits
between them[14]. .

This iterative, spiral-like development of the design and the

design specification has been reflected in figure 5.2. The design
The Structure of the Design Process 93
Function

~
Spec. 1

Design 1 r
Spec.2 ___ /
Compare

~
r
Properties

Design 2 Compare

~ Spec.• ___ /

I --- P,ope." ~ ---.. Approved design

~~~~J"
Figure 5.2 The itera-
tive structure of the
design process.

process comprises a sequence of intuitive (reductive) steps and

discursive (deductive) steps. Between the two, there is always a
comparison of the results attained so far and the desired results ..
The experience gained in the cycle is fed back, both to the design
proposal and to the formulation of the problem and the list of
requirements.

5.3 The Phases

01 the Product
Design Process

5.3.1 Introduction If the empirical cycle is an indispensable structural unit, this also
holds for the basic design cycle that is derived from it. This is the
way design processes are structured. That establishment leads
almost imperatively to the statement: effective design processes
should be structured in this manner. The cycle, which is found
descriptively, changes into a norm for effective designing. We can
therefore also consider the basic design cycle as a prescriptive
model for designing. But because the basic design cycle is so
general and abstract, it offers in this form insufficient scope for the
purposeful structuring of design projects in practice.
The basic design cycle and the idea of spiral-like development
can, however, be worked out into a phase model of the design
process. To that end the design process is divided into groups
94 Product Design: Fundamentals and Methods

of related activities, which lead to a certain stage of develop-

ment of a design, such as a functional design or function
structure, a principal solution, a concept, and the like. These
'designs in the making' correspond with the provisional designs
I, 2, 3, etc., in figure 5.2. They are not alternative design pro-
posals for the same problem, but further elaborations, at an
increasingly concrete level. The end of each phase can be taken
as a decision point. Herein lies the importance of phase models.
At the decision points one looks back on the work performed,
and the results obtained are weighed against the goals of the
project. Phase models therefore urge a regular evaluation of the
project. That evaluation often has to be reported to the manager
who is responsible for the product development process, or to
the client, who decides what will happen to the design
proposal: reject, do a step back, or continue to the following
phase.

5.3.2 Foundations of Phase models are based on the idea that a design in the making
Phase Models can exist in three different ways:

• as a function structure;
• as a solution principle;
• as an 'embodied' design.

A function structure is a representation of the intended be-

haviour (the functions) of a product and its parts. A solution
principle defines the working principle, or mode of action, of a
product or a part thereof. It specifies (in generic terms) the
function carriers or 'organs' of which a product should be built
up, to fulfil its internal and external functions. For example, the
function 'amplifying force' can be realized by the function
carrier 'lever', but also by other technical means, such as a
wedge and electromagnetic and hydraulic mechanisms. A
function may require various function carriers and a function
carrier may 'carry' various functions. In practice a solution
principle is usually given as a diagram or a sketch. By an
'embodied' design we understand a design in the more usual
meaning of the word. It is a description, usually as a drawing,
of the geometrical and physico-chemical form of a product and
its parts.
This three-part division is based on system-theoretical insights,
which Hubka and Eder[15] have elaborated in their Theory of
The Structure of the Design Process 95

- - System boundary

Figure 5.3 A system "-

Element
comprising a box, a "-
"-
beam and a stone. Relation

Technical Systems*. In the following paragraphs we shall discuss

this and other foundations of phase models in our own wording.

A product is a system There is hardly any product that does not consist of various parts.
Products are built up of components, which in turn contain parts,
and even a part might be composed of different materials.
Products are systems and can themselves be part of more com-
prehensive man-machine systems. A system is built up of
elements, which are recognized because of their properties or
attributes. Figure 5.3 is an example of a simple material system; it
consists of a box, a beam and a stone. Attributes of the elements
are, for example, their weight, dimensions, shape and stiffness.
Sometimes the attributes of one element depend on those of
another element. Such a dependence is called a relation. There
are, for example, relations between the positions of the box, the
beam and the stone, and the force needed to lift the box. A col-
lection of elements is only a system if there exist relations between
its elements.

* Hubka and Eder use the words 'organ structure' and 'component structure' for
'solution principle' and 'embodied design'. However, these phrases have not
become very usual, and have, therefore, not been adopted here.
96 Product Design: Fundamentals and Methods

The set of invariant relations is called the structure of a system.

Systems ate continuously changing, but their structure constrains
the number of possible transformations. Because of its structure, a
system remains as it is.
Each system has an environment, which consist of the entirety
of elements outside the system, which influence its behaviour. In
figure 5.3 the ground and a user belong to the environment. The
system boundary is the conceptual boundary between elements
that are and elements that are not reckoned to belong to the
system. A system boundary can correspond to a physical
boundary, but need not do so.
Relations between a system and its environment can work in
two directions: from environment to system and vice versa. The
terms 'input' and 'OUtput' are therefore also used for these rela-
tions. For a more extensive discussion of system concepts, we
refer to Kramer and de SmitI16].

The function of a system Systems fulfil functions. In Section 4.2.4 we defined the function
of a product as the process of change, which is to be brought
about by the product, of something in its environment. In terms of
systems, this is said differently: the function of a system is the
intended transformation of inputs into outputs. These are two
equivalent definitions, for the transformation of input character-
istics into output characteristics is nothing else than a change of
state of the environment of a system. The function of a system is
often represented as a black box, as in figure 4.2. A black box
suggests that functioning coincides with a clearly observable
process in the product. This is possible, but need not necessarily
be the case. For example, the functioning of a coffee mill (beans
:=:;> coffee) requires a mechamcal process in the mill. However, if
we consider the functioning of a screw, a chair or a bridge, then
there is no visible process. Yet, the functions of these systems can
also be described by a black box. The input and output char-
acteristics are then not to be seen as concrete flows of material,
energy and information, but as imaginary quantities. For
example, the function of a bridge is 'supporting human beings
and vehicles'. The loads that result therefrom become the inputs,
the reaction forces on the supports the outputs. The shape, di-
mensions and the material of the bridge make the intended
transformation (loads ~ reaction forces) possible. In a compar-
able way, the functions of other 'static' products can be char-
acterized, so that in principle one definition of 'function' suffices
The Structure of the Design Process 97

for all sorts of products[l7}. In Section 4.2.4 we pointed out that

non-technical functions are also covered by this definition.

The function structure Suppose someone wants to lift a box with the aid of a beam and a
stone. The beam and the stone can thus be considered as a sub-
system of the system 5 pictured in figure 5.3, which functions as
an instrument for the action. A subsystem is a collection of
elements, which shows all characteristics of a system, but which
also plays a role in the functioning of a larger whole. In other
words: a subsystem fulfils a subfunction in the mode of action of a
larger system.
To describe a subsystem, we must look at the relations between
the subsystem and its environment. In our example, the en-
vironment no longer consists only of the ground and the user, but
includes the box as well. So, the system boundary has moved. The
function of the instrument is 'amplifying force'. The input is the
force Fl that the user exerts, the outputs are the reaction forces F2
and F3 (figure 5.4).
We can continue the analYSis of system S, for the instrument
itself comprises two subsystems: the beam and the stone; we can
therefore ask for the function of the stone with respect to the
beam. That function is 'transmitting force'. Transmitting is to
move a quantity in space, so F3 is part of both input and output of
the stone, but the place of action is different (figure 5.5).

Beam
F1 --II>I~ plus
stone

F3

Figure 5.4 The function of the subsystem 'beam plus stone'.

F:3 --II>I~ Stone

Figure 5.5 The

function of the stone. F3
98 Product Design: Fundamentals and Methods

S
instrument

F1 ~
, F2 ,
-, Beam , -,-' Box ,

F'3

,
I Stone
I
~

Figure 5.6 The function structure of the system 'box, beam and stone',

By describing the subsystems of S in this manner, we get a

representation of system S, in which only the functions of the
system as a whole - and of its subsystems - are given in their
mutual relation. It is an abstract representation that does not refer
to concrete shape and material of the physical parts of the system.
Such a representation is called a 'function structure', and also a
'functional design' (figure 5.6). Some examples are given in
Chapter 7 (figures 7.2 and 7.5 and Example VI); in that chapter we
shall go more deeply into the role of the function structure in the
design process. It will become apparent then that the function
structure is an important methodological tool; it provides an aid
for thinking about the mode of action of a product, without en-
forcing premature decisions on its embodiment.

The solution principle A function structure is a model of the intended behaviour of· a
material system; it shows what internal functions must be
realized by (not yet concretely defined) elements, so that the
system as a whole can fulfil its external overall function. De-
signers try to realize this behaviour by thlnking up concrete parts
and components for the internal functions, and establishing for
each part its place in the whole, as well as its precise geometry
and material.
A product, if made and used, is part of the material reality; the
processes of change that are brought about by the product, are
governed by the cosmonomous behaviour of that reality. In
making decisions, designers are themselves led by images - in the
form of causal models - of the cosmonomy. The natural processes
that are described by the causal models are in themselves neutral,
regarding a particular solution, and a designer cannot really
change these processes as such. What can be done is making
The Structure of the Design Process 99

Subfunction Physical effect Solution pl1nciple

(independent of solution) (physical effect and
form design features)

.~
Friction

~
-._-:.
I,
T, Transfer '1 /1

torque 0- /
/1
1
K' ~FR '
FR =JlFN "

-v

Fa Amplify
torce
F~
Lever

'q;1'
a

Fe a=Fbb
Expansion
~

me. ~
Q b

---
~ rCJ
J
Close J I '-J
contact r---
If 11 13"
" I
S --:::;.."..-

when 1!ii!:Va
L/1=Ci. 1L/3- bimetal

Figure 5.7 Examples of subfunctions, physical effects and solution prin-

ciples (source: Pahl & Beitz).

nature into an ally, by arranging the material in the product in

such a manner that the product does what it should do, under the
influence of the specific laws that govern it because of its form.
Thus, what is essential to the mode of action, to the actual func-
tioning of the product, is the purposeful arrangement of matter by
which one or more known or unknown physical, chemical, bio-
logical or other effects are utilized to realize the intended internal
and external change processes. This arrangement is called a
'solution principle'.

A solution principle is an idealized (schematic) representa-

tion of the structure of a system or a subsystem, in which the
characteristics of the elements and the relations, which are
essential to the functioning, are qualitatively determined[18J.

Figure 5.7 gives three examples of solution principles. It demon-

strates that in a solution principle physical effects, which are
neutral to their utilization, and decisions as to geometry and
material come together. A solution principle therefore is more
than the physical effect upon which it is based. It establishes
already essential characteristics of the form of the product.
Just as the overall function of a system is the resultant of a
number of subfunctions, a solution principle for a product as a
whole arises from the combination of solution principles for its
parts. The overall solution principle, which is chosen for further
development, is called the 'principal solution'.
100 Product Design: Fundamentals and Methods

The core of designing - reasoning from function to form - is

especially evident in the creation of a principal solution, for the
principal solution marks the transition of the abstract functional
structure to the concrete material structure of the product to be
developed. Reasoning from function to form does not lead to a
unique answer. Any function can therefore be realized with dif-
ferent physical effects, and these can be worked out into different
solution principles and principal solutions.

The 'embodied' design A principal solution is already a first design proposal because it
embodies decisions on the geometry and material of the new
product. It is, however, not more than an outline design proposal,
which deals with physical feasibility only. It is a technical possi-
bility that has to be worked out to some extent, before it can be
evaluated against non-technical criteria as well. The development
of a principal solution to a detailed design can be seen as a
process of establishing increasingly accurate, and more numerous
characteristics of the new· product.
Hubka and Eder[19] distinguish in this regard between external'
properties and internal properties (figure 5.8)*. Roughly, this
distinction corresponds to external and internal functioning, re-
spectively of the product in its environment and of its parts one to
another. External properties depend on internal properties. Only
some of the internal properties can directly be determined by the
designer. These so-called design properties' are:
I

• the structure of the entire product (the arrangement of the

parts);

and of each part:

• the shape;
• the dimensions;
• the material;
• the surface quality and texture;
• the tolerances;
• the manufacturing method.

"Hubka and Eder's design properties concern either the geometrical form or the
phYSico-chemical form of the product; their analysis is more detailed than, but
does not deviate from, ours in Section 4.2. Note that external and internal prop-
erties are not precisely the same as extensive and intensive properties.
The Structure of the Design Process 101

Space
Rpliability requirements

Functionally
Function determined Durability
properties Life

Operational Weight/Mass
Function properties

Durability Strength
Liquidation Ergonomic
Wastes properties Structure properties

Tolerance Surface
Form
quality
DESIGN PROPERTIES
Price Economic Aesthetic
properties properties Colour
Dimensions
ManUfacturing
Manufacturing properties
Operational
methods Appearance
costs
Materials

Manufacturing Distribution
Quality properties ' properties
INTERNAL PROPERTIES

DeliVery &
Law planning Transportability
conformance properties Packing
properties

Laws EXTERNAL PROPERTIES Delivery

-Regulations deadline
Standards
Codes of practice

Figure 5.8 Properties of technical systems (source: Hubka & Eder),

A product design is ready for production if all design proper-

ties have been specified definitively and in all required detail. The
desired external and internal properties are laid down in the
design specification. Because usually many properties have to be
considered, and. the relations among them are complex, the de-
velopment of a principal solution into a detailed 'definitive
design' usually requires some stages in between. Typical inter-
mediate stages are the design concept and the preliminary design
(or 'sketch design,)[20].
In a design concept a solution principle has been worked out to
the extent that important properties of the product - such as,
appearance, operation and use, manufacturability and costs - can
102 Product Design: Fundamentals and Methods

be assessed, beside the technical-physical functioning. To do so,

an abstract idea on the kinds of parts and components (the
function carriers) of which the product is built up does not suffice.
One should also have a broad idea of the shape and the kinds of
materials of the product and its parts.
A 'preliminary design' is the following and last stage before the
definitive design. Characteristic for this stage is that,· for at least
the key parts and components of the product, the layout and
shape and main dimensions have been established, and the ma-
terials and manufacturing techniques have been determined.

The logic of phase models The modes of existence of a design as described above, enable
designers to explicate their thoughts about a design, and to judge
and further develop them. Often there corresponds a more or less
usual form of representation to each stage, such as flow diagrams
for function structures, diagrams for solution principles, sketches
for concepts, layout draWings for preliminary designs and stan-
dardized technical drawings for definitive designs. Such docu-
ments mark a stage in the development of the design and a phase
in the design process. The sequence 'function-function structure-
solution principle-"embodied" design' is based therein on
means-end relationships. An 'embodied' design (a concept, a
preliminary design or definitive design) is one of many possibi-
lities (means) to realize a principle (as an end). A principal
solution is a chosen means, seen from the function structure as the
goal. In turn, the function structure is a chosen means with
respect to the overall function as the end. This means-end re-
lationship implies a fundamental, logical sequence in developing
a product, which underlies the phasing of the design process[21].

5.3.3 Three Models of the design process have been developed since the early
Phase Models - 1960s. In engineering design, this development seems to have
One Thought converged into a phase model, comprising four phases. The
model can be found, in slightly different versions, in several
textbooks: especially French[22], Pahl and Beitz[23l and Hubka[24].
More formally, this model has been described in VDI Guideline
2221[25]. Comparable models are those ofPugh[26], Ullman[27] and
van den Kroonenberg and Siers[28].
Among the most widely adopted versions of the phase model
are those of French (figure 5.9) and of Pahl and Beitz (figure 5.10).
In Pahl and Beitz' terminology the phases are called:
The Structure of the Design Process 103

Feedback

Figure 5.9 The phases of the design process according to French.

• clarification of the task e Aufgabe kUiren')

• conceptual design ekonzipieren')
• embodiment design (' entwerfen')
• detail design (' ausarbeiten')

The phases comprise activities, which lead to typical stages in

the development of a product, respectively:

• the design specification (' Anforderungsliste')

• the concept (Konzept)
• the preliminary design evorUiufiger Entwurf' or 'Vorentwurf')
• the definitive design (/endgiiltiger Entwurf' or 'Gesam-
tentwurf')
• the product docwnentation ('Produktdokumentation').

Broadly speaking, the phases involve the following activities:

Clarification of the task In this phase the problem, handed over to the designer by the
product planning department or an external client, is analysed,
and information on the problem is collected. Based upon that in-
formation a design specification is drawn up. The specification
 r---
104 Task
I

•
Clarify the task
~

T
c
-BiJi
C'II til
J!!;
.

r-t- Elaborate the specification .= :;

..!l! ....
(,,)0
I
I
I C_specr;n ~ .9!
.e-
I
I
. c
0

'Ii

I identify essential problems c

.!2l
-
Q>
..c
'5
.§
Establish function structures
~ Search for solution principles ~ 1;
.Ia
'iii E
Combine and firm up into concept variants a0
~
I Evaluate \against technical and economic criteria ~
5
I (,,)

-~- -_
I
I < -

~----
- ......
Concept
-- - - -

.
.. -

----~-
... ,
~

I Q>

~
~.--
Develop preliminary layouts and form designs
Select best preliminary layouts .~
I Refine and evaluate against technical and econon'ic criteria "i
til

I ! c
R

< -P~H~~~~," ~.
I ::J
f
I -. .i
I
I . .....- I
w

I Optimise and complete form designs

Check for errors and cost effectiveness
t-'- Prepare the preliminary parts list and production documents
I
I
I
I < ·;;'~""':. .~n
- ------ ~---
~

I
I •
Final ise details
~~ Complete detail drawingsand production documents
Check aU documents

c------L -- Documentation
.- - - - - - - - - ---
--.

Solution
L--
The Structure of the Design Process 105

defines the functions and properties that are required for the new
product, as well as the constraints placed upon the solution and
the design process itself, such as standards and date of completion.
The specification directs the work in all other phases of the
design process. Work done in later phases may change one's
understanding of the problem and new information may become
available. Therefore modification and refinement of the initial
specification should be undertaken regularly. This is indicated by
the feedback loops in the models.

Conceptual design Given the specification, broad solutions are to be generated and
evaluated, that provide for a suitable point of departure for em-
bodiment design and detail design. Such' broad solutions are
called 'concepts' (Pahl and Beitz) or 'schemes' (French). Normally
they are documented as diagrams or sketches.
The conceptual phase starts with determining the overall
function and important subfunctions to be fulfilled and estab-
lishing their interrelationships (function structure). Next solution
principles ('Losungsprinzipien'), also called 'working principles'
('Wirkprinzipien'), for subfunctions or subproblems are gener-
ated and integrated into overall solutions, in accordance with the
function structure. Such a combination of solution principles has
been called a 'principal solution' ('Prinzipielle Losung'). A prin-
cipal solution defines those physical-technical characteristics of a
product that are essential for its functioning.
However, the choice for a particular principal solution is not to
be based upon technical criteria only. Criteria relating to use, ap-
. pearance, production, costs and others, must also be taken into
account. To that end principal solutions have to be worked up into
concept variants, which already show part of the embodiment of
the principle. A concept, or scheme, should be carried to a point

where the means of performing each major function has been

fixed, as have the spatial and structural relationships of the
principal components. A scheme should have been suffi-
ciently worked out in detail for it to be possible to supply
approximate costs, weights and overall dimensions, and the
feasibility should have been assured as far as circumstances
allow. A scheme should be relatively explicit about special
features or components, but need not go into much detail
over established practice[291.

Figure 5.10 The phases of the design process according to Pahl and
Beitz.
106 Product Design: Fundamentals and Methods

Conceptual design is commonly seen to be the most important

phase of the design process, because the decisions made here will
strongly bear upon all subsequent phases of the design process. A
weak concept can never be turned into an optimum detailed
design, so to speak.

Embodiment design In this phase the chosen concept is elaborated into a definitive
design, also called 'definitive layout'. The definitive design
defines the arrangement ('layout') of assemblies, components and
parts, as well as their geometrical shape, dimensions and mate-
rials ('form designs').
Contrary to what the phrase 'definitive' may suggest, the de-
finitive design need not be completely worked out in full detail.
The configuration of the product and the form of the parts are to
be developed up to the point where the design of the product can
be tested against all major requirements of the specification,
preferably as a working model or prototype.
The decisions to be taken about the layout and form of the
components and parts are strongly interrelated. Therefore, more
than conceptual design, embodiment design involves corrective
cycles in which analysis, synthesis, simulation and evaluation
constantly alternate and complement each other. Embodiment
design is essentially a process of continuously refining a concept,
jumping from one subproblem to another, anticipating decisions
still to be taken and correcting earlier decisions in the light of the
current state of the design proposal. It therefore pr(;>ves difficult to
draw up a detailed plan of action for this phase that holds in
general.
In Pahl and Beitz' model embodiment design is subdivided into
two stages. The" first stage leads to a preliminary design, in which
the layout, form and material of the principal function carriers are
provisionally determined. In this stage several alternative embo-
diments of a concept are often worked up in parallel in order to
find the more optimum layout.
In the second stage, then, the best preliminary design is ela-
borated, up to the point where all major decisions about the
layout and form of the product are taken and tests of its func-
tionality, operation and use, appearance, consumer preference,
reliability, manufacturability and cost can be carried out.
Normally at the end of this phase the design is represented by
layout draWings, made to scale and showing important dimen-
sions, and preliminary parts lists.
The Structure of the Design Process 107

Detail design In this final phase the geometrical shape, dimensions, tolerances,
surface properties and materials of the product and all its in-
dividual parts are fully specified and laid down in assembly
drawings, detail drawings and parts lists. Also instructions for
production, assembly, testing, transport and operation, use,
maintenance and the like, have to be worked out now. All these
documents fall under the heading of the 'product documents'.
Of a more recent date than the models of French, and Pahl and
Beitz is the Guideline VDI 2221, Systematic Approach to the Design
o/Technical Systems and Products. This guideline aims for a general
approach to design, which is applicable to a wide variety of tasks,
and transcends specific branches of industry. To demonstrate its
potential, examples are given for mechanical engineering, process
engineering, precision engineering (mechatronics) and software
engineering. Yet, the ideas presented in the guideline seem to be
more closely associated with mechanical engineering design. The
general approach is divided into seven stages, correspondingly
producing seven results (figure 5.11). Either all or some of the
stages are to be completed, depending on the task at hand. In-
dividual stages can be combined into design phases, in order to
assist the overall planning and management of the design
process. It is stated that the way stages are grouped into phases
can differ depending on the branch of industry or company.
Apart from stage 4, in which a so called 'module structure'
('modulare 5truktur') is to be established, all stages and results
can be recognized in the Pahl and Beitz model as well. The
module structure takes more or less the place of the concept or
scheme in the previous models, though it is not precisely the same
thing. The module structure specifies the division of a principal
solution into realizable parts, components or assemblies, which
has to be undertaken before starting the process of defining these
modules in more concrete terms. Such a breakdown is particu-
larly important for complex products, as it facilitates the dis-
tribution of design effort in the phase of embodiment design.
So much for the explanation of the three phase models of the
design process. Evidently they are very similar. There do not
appear tc? be any great differences in elementary activities dis-
tinguished, nor in the sequence of these activities indicated.
(Naturally this cannot appear from the diagrams only; the defi-
nitions and explanations provided by the authors must be
compared as well.) There seem to be only minor differences in the
division of activities over phases. So, the three models should
rather be considered as variants of a 'consensus model' of the
108 Product Design: Fundamentals and Methods

Task

l
Phase
I

Clarify and define

the task

SpecKication

Detennine functions
and their structures

Function structure

Search for solution principles Phase

and their combinations II

Principal solution

Divide into reaHsable

modules

Module structure

Develop layouts of Phase

key modules III

Preliminary design

Complete overall
layout

Definttive design

Prepare production and

Qperating instructions Phase
IV

Product OOcuments
1
Figure 5.11
General approach to
design according to Further realisation
VOl 2221.
The Structure of the Design Process 109

structure of the design process[30]; they may be taken as different

representations of one and the same pattern underlying the
process of design.
Some additional comments on the models discussed are in
place here.
First, it is stressed by all authors that sharp divisions between
the phases cannot be drawn, and that the stages and phases do
not necessarily follow rigidly one after the other. They are often
carried out iteratively, returning to preceding ones, thus achiev-
ing a step-by-step optimization.
Second, a phase model does not show the problem-solving ,
process, by which solutions for the design problem are generated
and refined. By that problem-solving process, in all phases solu-
tions are generated, tested and evaluated, if need be, by means of
working models or prototypes. That is to say: in each phase the
designer will go through the basic design cycle, often more than
once.
Third, in each phase alternative solutions can be thought up.
Working out all solution variants through all phases would lead
to an explosion of the number of possibilities to be studied. On
the other hand, restricting oneself to one track only within the
network of possibilities is dangerous, because then the better or
best alternatives may be overlooked. One is therefore urged to
diverge and converge in each phase. This important methodical
principle is visualized in figure 5.12.
Fourth, phase models like the ones presented here have not
been without criticism. To begin with, it has been observed that
these models have been developed with the designing of new,
innovative technical systems in mind. Therefore they pay (too)
much attention to the conceptual design phase, at the expense of
the phases of embodiment design and detailed design[31,32]. In
practice many design projects can do without inventing new
technical principles, and start from known, proven, concepts.
However, the phase models offer little procedural advice con-
cerning embodiment and detail design. It has even been ques-
tioned whether more detailed procedural models for these phases
may exist[33,34].
Phase models have also been criticized from a methodological
point of view. For instance: function structures might be of
limited heuristic value[35], partitioning the design process into
small steps might lead to an uncontrollable explosion of solution
variants to explore[36], and, when the appearance of the product is
important - as in industrial design - the total form of a product
110 Product Design: Fundamentals and Methods

Tasks
OJ
s::
.~
s::
co
c:::
•wa Selected task
Overall function

Sub-functions (function structure

to meet the overall function)
Solution principles and/or building
blocks for the sub-functions

• Selected solution principles

and/or building blocks
Combinations of principles to
fulfil the overall function
.... Selected combination of principles
Concept variants (rough dimensioned

• sketches or layouts)
Solution concept

Dimensional layout

• Improved layout
Selected assemblies

Form design variants of assemblies

. . Optimum assemblies

Iilll Final layout

Detail design of components

~ Production documents
(drawings, parts lists, instructions)

Figure 5.12 Divergence and convergence in the design process. The

shadowed elements indicate the chosen pOints of departure for the next
phase (source: VOl 2222).

has to be determined before or parallel to the form of the parts and

components (as 'dictated' by the chosen solution principles)[37].
Another point of criticism is that in practice the actual beha-
viour of designers seldom looks like the behaviour prescribed in
the phase models. Phase models assume that design should
proceed from the general and abstract to the particular and
concrete, in order to keep the solution space as large as possible.
Also they assume that complex problems should be split into
subproblems, for which subsolutions are to be found and 'syn-
thesized' into overall solutions for the design problem. Several
authors[38,39,40] have stated that, contrary to these assumptions,
The Structure of the Design Process 111

working from abstract problem formulations to concrete solutions

and splitting problems into subproblems are iterative and re-
cursive processes, that rely upon anticipations of possible, likely,
solutions based on knowledge of Lprecedents'.
As such these observations do not disqualify the phase models,
for their purpose is not to predict Lnatural' design behaviour but
to improve it, by offering a systematic procedure that makes the
design process more transparent and effective. By specifying in-
termediate results to aim for, without prescribing in detail how
these intermediate results are to be obtained, phase models - like
all methods - do not restrict designers to just one way of working .
(that is to say, they are not recipes). Instead they try to organize
the problem-solving behaviour of designers to such an extent that
it is more effective and efficient than intuitive, unaided, un-
systematic ways of working. How much this can be said to be
brought about by the models presented here remains to be seen.
There is until now little empirical evidence, either in favour of the
effectiveness of phased procedures or against it. Empirical
research into the design process is only beginning to gain
momentum[41,42]*, so opinions on the value of the phase model as
a heuristic tool for designers are still largely based on personal
experiences and belief in its rationality.

5.4 The· Phases In the phase models of the product design process the interaction
of the Product of product design, production development and marketing is not
Development indicated. Commercial and manufacturing considerations are
Process; largely seen as constraints (established in the specification),
Concentric within which the designer seeks the best possible form for the
Development product.
In Chapter 2 we have seen that product design is part of the
development of a new business activity. This larger process was
called Lproduct development'. Product development comprises
the design of a product, plus the development of the plans for
manufacturing, distribution, the market approach, and some-
times even for a whole facility to be set up anew. All these plans
have to be properly attuned to one another. This also demands a

* For an extensive review of empirical studies into engineering design behaviour

see: Blessing, L. T. M., A Process-based Approach to Computer-supported Engineering
Design. PhD thesis, University of Twente, 1994.
112 Product Design: Fundamentals and Methods

phased approach, but with respect to the overall product devel-

opment process. There can only be real interaction between
developing of these plans if the product development process is
concentrically phased. This was pointed out in Section 2.5.5.
During the development of a product a great many factors
should be taken into account. The success of a new product
depends on the measure in which one succeeds in meeting the
demands of users, market, production and profitability, which are
often contrary with one another.
The full development of a new product is costly. A project may
require many man-years of highly qualified labour, and market
research, prototypes and testing equipment and the manu-
facturing of trial products also require large amounts. Mortality
and failure rate studies[43] show that many product ideas do not
reach the manufacturing stage. During their development, these
ideas do not appear to meet the expectations concerning technical
and commercial feasibility. Moreover, many products that have
been realized have little success on the market.
As mortality and failure rate studies suffer from· many
methodological pitfalls and catches, there may easily be differ-
ences in opinion on the percentage of unsuccessful product de-
velopment projects. But this does not detract from our
argument. In product development there are always alter-
natives. To find the best one, at least some of them have to be
(partially) worked out. In view of the high costs and the un-
certainty about the success, it is very important that the devel-
opment of an 'unfruitful' product idea be stopped as soon as
possible. But, beforehand, it is not known whether an idea will
be unsuccessful, nor because of what problem, for then one
would not have begun with the development of that idea at all.
This principal difficulty can only be overcome by dividing a
product development project into a number of phases, and to
pay attention in each phase to all aspects as much as possible; in
the first phases broadly, in order to keep the development costs
low, and in later phases increasingly more in depth. At the end
of each phase it is to be decided whether an idea will be further
worked out in the following phase, whether the phase will be
repeated, or whether the idea will be rejected.
This principle we have called 'concentric development'. It is the
most important methodological rule for product development;
the product development process should be phased concentrically,
both during product planning and strict development. Therefore
the number of phases is rather arbitrary and different for each
The Structure of the Design Process 113
STAGE
Policy formulation
STRATEGIC
PLANNING
C 1. establish strategic objectives .
2. lay down outline timetables, overall budgets and guide lines for innovation

2 Preliminary research
1. select an invention, discovery, scientific principle, product idea or technological
base.
RESEARCH 2. identify an area of need, marketing opening, consumer appetite, product
[product-oriented deficiency or value base
only: concurrent 3. establish the existing state of the art (library and market research)
market-oriented, 4. prepare outline performance specification (a verbal prescription for a proposed
materials-oriented, product-specification 1)
plant-oriented and 5. identify probable critical p(oblem areas
pure or applied
research would 3 Feasibility study
follow different 1. establish technical feasibility (basic calculations) Out of ten product
patterns] 2. establish financial viability (economic analysis) ideas emerging
3. resolve critical problems in principle (inventions) from stage 3 ....
4. propose outline overall solution(s) (sketch designs 1)
5. estimate work content of phases 4 and 5 and probability of a successful outcome
(risk analysis)

4 Design development
1. expand and quantify performance specification (specification 2)
2. develop detailed design (design 2)
3. predict technical performance and product costs
4. prepare design documentation
5. design technical evaluation experiments and user trials

5 Prototype development
1. construct prototype(s), mock-ups (prototype 1) .... perhaps three
DESIGN 2. conduct bench experiments with prototypes go to prototype
3. evaluate technical performance stage ....
4. conduct user trials with prototypes (trials 1)
5. evaluate performance in use'

6 Trading study
1. re-appraise market potential in light of trials
2. re-appraise costings
3. appraise marketing/production problem
4. revise basic objectives (strategic planning) and development budget
5. revise performance speCification (specification 3)

7 Production development
1. develop a production design (design 3)
2. executa production design documentation .... and one sur-
3. design technical, user and market trials vives for production
4. construct pre-production prototypes (prototype 2) development
DEVELOPMENT 5. conduct technical, user and market field tests (trials 2)
6. appraise trials results and modify deSign

8 Production planning
1. prepare marketing plans
2. prepare production plans
3. design packaging, promotional material, instruction manuals
4. design jigs and tools

Figure 5.13 A characteristic programme for product development

(Source: Archer).
114 Product Design: Fundamentals and Methods

STAGE
9 Tooling and market preparation
1. construct jigs and tools
MANUFACTURING 2. construct trial batch of products off tools (prototype 3)
MARKETING 3. test trial batch (trials 3)
START-UP 4. produce marketing materials and print
5. install marketing machinery
6. install production control machinery

10 Production and sale

1. initiate marketing effort
2. commence production and sale
PRODUCTION 3. collect market, user, repair and maintenance feedback
4. make recommendations for second generation designs (stages 2 to 4)
5. make recommendations for research (stages 1 and 2)

Figure 5.13 Continued.

project. Each following phase augments the certainty that one is

on the right track, but the remaining uncertainty as to the ultimate
success of the product never disappears completely.
It appeared that the basic design cycle had to be 'transformed'
into a phase model, to give direction to design projects. This also
applies to the principle of concentric development. In Chapter 2
concentric development was compared with successive 'rounds'
through the overall model of product development (figure 2.9).
The aspect studies and decision points in that model are passed
many times. In figure 5.13 those 'rounds' were given a more
concrete form in a program for product development, which is
drafted by Archer[44]. This program is based upon case studies in
the field of engineering product development, and gives a good
idea of projects in that field. It is given here as an elaborate
example. Not every activity will be equally important in every
product development project, nor does one find all activities that
might be relevant. A comparable example of concentric devel-
opment is the 'Denkmodell der Produktplanung' of AW
Design[45].
In Archer's program, the steps from the basic design cycle as
well as the phases of the product design process can be re-
cognized. The main phases 'research', 'design' and 'development'
roughly parallel the phases 'conceptual design', 'embodiment
design' and 'detail design' in the phase model of product design.
The basic design cycle can be seen in the repeated occurrence of
establishing specifications (specification 1, 2, 3), developing
designs (design 1, 2, 3), and testing them (trial 1, 2, 3), both as
regarding technical functioning, use and market, as regarding
manufacturing and costs.
The Structure of the Design Process 115

Problem Problem

Criteria r--- Facts

I
I
I
Provisional design I Hypothesis
I
I
I
I
Expected properties Prediction
I
I
L_

Value of the design Degree of truth of the hypothesis

Decision Evaluation

Approved design New knowledge

Figure 5.14 The basic cycles of design and empirical scientific inquiry.

5.5 Comparison In Chapter 3 it was said that empirical scientific research and
of the Basic designing artefacts are, methodologically speaking, essentially
Cycles of Design different activities. In conclusion of this chapter on design
and Empirical problems and the design process, we would like to go more
Scientific Inquiry deeply into this.
In figure 5.14 the basic cycles of design and of empirical sci-
entific inquiry, which were introduced in Section 5.2, have been
placed one beside the other. The first thing that meets the eye is
that they resemble one another. They have the same number of
elements which, moreover, relate to one another in the same
manner. In the research cycle the forward pointing arrow
between 'facts' and 'testing' is dashed to indicate that the pre-
diction should be tested with respect to new data, and so with
respect to other facts than those that 'generated' the hypothesis.
The two cycles have - as presented here - a similar structure: they
116 Product Design: Fundamentals and Methods

are isomorphous. This is not surprising, for, as we set out in

Section 5.2.1, both cycles can be traced to the 'empirical cycle as
reflected' - the basic model for problem-solving. One might then
assume that they are identical and that they only differ in their
terminology. Then one easily reaches the conclusion that tech-
nology is merely a form of applied science and that, if you have
science, you 'automatically' have technology and design. We will
show, however, that this train of thought*, which is indeed
widely prevalent, is incorrect. In order to do so, we will explain
the essential methodical differences between the two cycles.
In Chapter 3 (figure 3.1) it was shown that human beings
function in two domains: the domain of material reality and the
domain of the mind, and that these two domains interact with
one another. Furthermore, it was established that, despite the
intense interaction between the two domains, nevertheless two
main directions can be distinguished, namely a process from the
outside to the inside (from material reality to the domain of the
mind) - a process that we call/knowledge acquisition' - and a
process from the inside to the outside (from the domain of the
mind to the domain of the material reality), which we call
'technical action'. The process from the outside to the inside is
directed towards knowledge of the world. The process from the
inside to the outside is directed towards change of the world. In
the former process, science plays the main part and technology
has possibly (but often) a supporting role. In the latter technology
plays the main part and science has (also often) an supporting
role. In the discussion of the structure of technical action (Section
4.3) we have also seen that the domain of the mind can in itself be
divided into an area of factual statements or truth statements, and
an area of value judgements. This train of thought should be re-
membered in the following explanation.

Two problems Both cycles begin with a problem. These problems appear to be
different already. In both cases they point to an unsatisfactory
situation which one wants to change into a more satisfactory one.
In the research cycle the problem is that the available knowledge
(a collection of factual statements about the world) is not aligned,
or is insufficiently aligned, to the empirical facts. The facts are
unassailable; hence the aim of scientific research is to change,

... See for instance: B1lllge, M., Technology as applied science, Technology and
Culture, 7 (1966) 3, pp.329-347.
The Structure of the Design Process 117

respe.ctively expand, the collection of factual statements (which

appeared to be insufficiently 'true'), in such a manner that they
align better with the facts.
In the design cycle the problem at the onset is that the facts are
not aligned with our values and preferences concerning these
facts. And since (in the first instance) our values are unassailable,
this discrepancy leads us to making it our aim ~o change the facts.
We want to create a material condition which does agree with our
values and preferences. This requires technical action. Technical
action requires technical means, and these must be designed.
Recapitulating, we might say:

• The research cycle is triggered by a discrepancy between the

facts and our knowledge - a package of truth statements con-
cerning these facts. The aim of the process is adjustment of our
knowledge to the facts.
• The problem at the onset in the design cycle is a discrepancy
between the facts and our valuation of these facts. The aim of
the process is adjustment of the facts (by means of the designed
artefacts) to our values and preferences.

The differences therefore are such that in the one process we

aim at changes in the domain of the mind (our knowledge of the
facts), while in the other process we aim at changes in the- domain
of the material reality (the facts). Moreover, in the first case the
mental emphasis is in the subdomain of factual statements, in the
second case in the sub domain of value statements. Thus, the
problems are different. They are oppositely directed and have
. different points of application.

Observation versus Scientific research occupies itself with the existing real world and
analysis with our representation thereof in factual statements. Design, on
the other hand, occupies itself with a not yet existing, but
(hopefully) feasible world, or worlds. Designing is the construc-
tion of possible worlds in which the designed product or process
could appear and function. There is but one actually existing
world, but there are many possible worlds. Possible worlds exist
only in the domain of the mind. A flawless design process can
thus take place entirely in the domain of the mind. But a flawless
empirical research process cannot. In this process, there must be
an interaction between the domain of the material reality and the
domain of the mind.
118 Product Design: Fundamentals and Methods

This refers immediately to a difference between 'observation' in

the research cycle and 'analysis' in the design cycle. In the first
instance, we tend to say, with regard to the research cycle, that
the elements 'problem' and 'observation' are in the wrong order.
For, did the problem not originate from the observation of facts
which did not agree with theory? Indeed, but in order to improve
the theory, we usually need more than the establishment of one or
a few 'anomalous' instances. From the moment the problem has
been recognized and we have decided to resolve it by means of
research, we want to map out the deviations in as large an area as
possible. This requires purposeful observation, in many cases
supported by experiments.
In the design cycle things are different. Since design is aimed at
possible, but not yet actually existing worlds, there is, initially,
nothing to observe. But one can ask oneself in reasoning under
what conditions a world that has been thought up will be both
feasible and desirable. This process of reasoning takes place in the
analysis phase. It often occurs that in analysing a problem we
come to the conclusion that we know too little to be able to carry
out the analysis properly and that the lacking knowledge cannot
be found anywhere in books or magazines. Then we have to
make recourse to research, in order to fill the gaps in our
knowledge. In doing so, the design process is left, strictly
speaking. With the knowledge gained from scientific research, the
design cycle is again entered, in order to further work on one or
more possible worlds.
There is a second difference between 'observation' and
'analysis'. This has to do with the establishment that although
both cycles are largely played out in the domain of the mind, the
research cycle therein is directed towards the subdomain of
factual statements, while the design cycle applies itself in the
sub domain of the value judgements. The relationship between
truth and value is a difficult philosophical problem, into which
we can hardly enter here. Yet, we can establish that most scientific
disciplines strive to work as 'value-free' as possible. Whether this
is possible or not, and whether one should not be satisfied with
aiming at 'objectivity' or even 'inter-subjectivity', are questions
which fall beyond the scope of this book*. We do ascertain,
though, that if other than 'internal' scientific values such as ra-
tionality, logical clarity, objectivity and integrity creep into the

*For an introduction see: Ropoh1, G., Die Wertproblematik in der Technik. In:
Roozenburg, N. and J. Eekels (eds.), Evaluation and decision in design. ZUrich:
Heurista,1990.
The Structure of the Design Process 119

research cycle, this is generally considered as 'unscientific'. This

implies that observation in research should be carried out as
objectively as possible: do not conceal any unwelcome observa-
tions, no dishonest samples, etc. In short: keep out values and
interests as much as possible.
In the parallel analysis phase of the design cycle this is fun-
damentally different. Value judgements are the point of departure
in the design cycle. They extend throughout the cycle and also
dominate the analysis phase. The analysis is therefore not aimed
at possible worlds in general, but at desirable possible worlds; this
desirability' is rooted in the value judgements inherent to the
formulation of the problem.

Induction versus The following two parallel elements of the two cycles are 'in-
synthesis duction' and 'synthesis'. Induction is the process by which a
nu.rtl.ber of individual observations of facts are 'summarized' in a
general law. Induction always concerns a certain aspect of the
reality concerned, for example the colour, the temperature, the
pressure or the chemical behaviour, but never the reality in its
totality. It gives us, so to speak, a generally valid photograph of
that certain aspect of that certain reality. It images that aspect of
that reality. But first there was the reality, and then came the
photograph.
The synthesis phase in the design cycle, on the contrary, is
aimed at the totality of the entity to be designed, not only at a
certain aspect, but at the entirety. A design is a kind of panoramic
photograph, encompassing all aspects. Moreover, in designing (if
we may talk of a photograph) we first have the photograph, and
at a later stage (when the design has been realized) the object that
was depicted. Or said differently: induction in the research cycle
is a posteriori (found afterwards) the material reality which was
studied; synthesis in the design cycle is a priori (given before) the
material reality which can be possibly realized. Consequently, the
pattern of reasoning in the induction phase in the research cycle is
different from that in the synthesis phase in the design cycle. The
former follows the logical pattern of induction, while the latter
follows the logical pattern of innoduction*. This was treated ex-
tensively in Section 4.4.

"" It should be noted that the word 'induction' has different meanings. It is used
both as the name of a particular pattern of reasoning (as in Section 4.4) and as the
name of a phase of the cycle of empirical scientific inquiry. Induction as a logical
. pattern of reasoning does not take place only in the phase of induction, as hy-
potheses are already largely formed during the observation phase. The same holds
for innoduction and syntheSiS.
120 Product Design: Fundamentals and Methods

Deduction versus Here the terminology plays tricks on us in so far that it disguises
simulation that the phase named 'deduction' in the research cycle involves
simulation, while the phase named 'simulation' in the design
cycle is based on deductive reasoning. The difference is therefore
not the logical nature of the operation (in both cases deduction),
but lies, on the one hand, in the system that forms the basis for
deduction, and on the other hand in the nature of the deductively
acquired results. Let us begin with the latter.
Scientific research aims at explaining present and past phe-
nomena and predicting future ones. Explaining is indicating the
general grounds or causes from which the observed phenomena
can be deduced. Predicting is to deduce future phenomena from
the present ones. Empirical generalizations and laws and theories,
gained from induction, provIde for these 'general grounds'. If
they have explanatory power, generally they also have predictive
power, but the reverse is not true. 'Pure' scientists direct them-
selves towards explanatory power for their theories, the engineer
is often already satisfied with predictive power.
Whatever the case may be, it should be possible to derive the
phenomena to be explained or predicted by means of deduction,
from the theoretical relationships acquired from induction. This is.
what one tries to do in the 'deduction phase'. In doing so, does
one try in the research cycle to include the totality of phenomena
in all their aspects? No, for as we already noted: sciences are es-
sentially 'aspect sciences'. Deduction thus aims at only one or a
few aspect(s) of the phenomena, and leaves out all other aspects.
Another characteristic of deduction in the research cycle is the
categoric nature of the conclusion. Although scientific laws are
often formulated in the form of hypothetical propositions
(material implication), deduction takes place via a proposition
syllogism, often according to the modus ponendo ponens. The fol-
lowing reasoning is an example: if Venus is a planet, then Venus
rotates around the sun (p ~ q is true); Venus is a planet (p is true);
therefore Venus rotates around the sun (q is true). The material
implication is the major in the syllogism, the minor categorically
confirms the antecedent, and the conclusion categorically
confirms the consequence.
Recapitulating, we can state that deduction in the research cycle
leads to a categorical explanation and/or prediction of one or
some aspects of reality.
Now, what about the parallel phase of simulation in the design
cycle? The synthesis phase has yielded a provisional design for a
product. Before we manufacture the product, we want to get an
The Structure of the Design Process 121

impression of how this product would behave if we manu-

factured it. We cannot be satisfied with merely one aspect, we
want a comprehensive image of the behaviour with respect to
many aspects: functioning, durability, safety, usability, energy
use, environmental consequences, cost price, etc. We would like
to explore the possible worlds in which our product might occur
before we make it into the real world. But perhaps this exploration
will lead us to retract and take another road. This already in-
dicates that the results of such sounding out, which takes place by
means of simulation, cannot be but hypothetical propositions of
the general form 'if ... then ... '. In ordinary language we say that
simulation is used to predict the behaviour of the designed
product, but then it does concern conditional predictions versus
categorical predictions in the research cycle.
Recapitulating, we can state that simulation in the design cycle
leads to a conditional prediction of the behaviour of the designed
product, with respect to this product in its totality, that is to say
with respect to as many aspects as possible.
As already said, simulation in the design cycle also takes place
on the basis of deductive reasoning, but that is not the whole
story. We will have to go back to the logical systems in which.
deduction takes place. In the research cycle that logical system is
anchored in the inductively acquired law or theory. Induction
directly yields the logical system for deduction, as it is the
purpose of the induction phase to elaborate and formulate a hy-
pothesis in such a way that testable logical consequences can be
derived from it. In the design cycle this is not the case. The pro-
visional design, which follows from the synthesis phase, is a de-
scription of a product, but definitely not a logical system in which
deductive operations can be carried out. At the beginning of the
simulation phase we stand with empty hands. Thus we start the
simulation phase, not immediately with deduction, like in the
research cycle, but we first have to build up a logical system for
that deduction. Since in designing, a number of aspects is
involved, it often means that we have to construct a number of
these deductive systems. Such systems are called models. Thus, at
the beginning of the simulation phase, models should be con-
structed on the basis of which the desired deductive operations
can be carried out. In Chapter 8 we will go more extensively into
the different models for simulation. Here we shall restrict our-
selves to the following remarks.
Deduction always takes place in a logical system. Logical
systems belong to the domain of the mind (although they can be
122 Product Design: Fundamentals and Methods

interpreted materially in books and the like}. Some simulation

models, for example mathematical models, directly form such
logical systems within which deductions can be performed. Yet,
many simulations call upon the help of experiments with physical
models, which are considered, with respect to a certain aspect, as
homomorphisms of the original. Such expe~ental simulations
are based on the hypothetical proposition: if the experiment
yields p, this means q for the original. The deduction can then
restrict itself to the syllogism according to the modus ponendo
ponens: well then, the experiment does yield p, hence the original
shall yield q, under similar conditions. The way in which the
initial conditions and p relate is not deduced via (complex) cal-
culations, but is read from the experiment.
Thus we see that the simulation phase in the design cycle
contains one element more than the deduction phase in the
research cycle, namely the construction of a simulation model (or
simulation models). Furthermore, deduction in the research cycle
takes place entirely in the domain of the mind, while the simu-
lation phase in the design cycle often enters the field of material
reality, via experiments with physical models.

Testing versus evaluation Often Ltestability' is seen as the pre-eminent criterion for scientific
statements. Testing can direct itself to the explanatory power or to
the predictive power of the postulated laws or theories. For
simplicity's sake, we shall restrict ourselves here to the testing of
predictive power. In view of the inductively acquired insight,
deductively a prediction has been made (with or without the help
of an experiment) on facts to be observed in the future. In the
testing procedure these facts are observed and compared with the
prediction. Does it fit the facts? If not, to what extent do the facts
Lsupport' the hypothesis, that is how 'true' is the hypothesis? (In
figure 5.14 we used the qualitative notion of Ldegree of truth' of
the hypothesis for this). In testing, the research cycle again enters
the domain of the material reality. The conclusions are factual
statements in the domain of the mind.
During evaluation in the design cycle, comparisons are made as
well, albeit not between fact and theory, but between 'simulated
design behaviour and the desired behaviour of the product to be
designed. So factual statements are compared to value state-
ments, resulting in value judgements as to the quality or utility of
the design proposal, in the light of the design specification. Eval-
The Structure of the Design Process 123

uation takes place entirely in the domain of the mind, largely in

the domain of value judgements.

Evaluation versus Here as well the terminology might mislead us, for we have
decision formulated the two cycles in words which do not differ much
from the jargon usually used in research and design. Indeed,
'evaluation' in the research cycle does not judge only on the
findings of the entire process. A decision is also taken of whether
the goal laid down (more, better knowledge) has been sufficiently
attained, or whether the results should be sharpened up in one or
more iterations. (Also in science, such a decision implies a value
judgement.) Hence, the feedback arrows which run in figure 5.14
from the element of 'evaluation' back upwards. But if the eva- ,
luation has been satisfactory, it is decided to add the knowledge ~\
which the process has yielded to the acreage of knowledge in the
domain of the mind. Usually this takes place more explicitly in
the form of a scientific publication.
In the design cycle we encounter the element 'decision' at this
level. The decision aspect is expressed more explicitly in the
design process. Here it concerns various possibilities to.
continue. First of all, the provisional design concerned can be
improved in one or more iterations. The feedback arrows reflect
this. But a decision can also be made to generate more design
alternatives. The feedback arrows also clearly show this option.
And finally, the decision can refer to choosing an attractive
alternative from the collection of generated designs. The process
ends with the yield of a number of acceptable designs, or - one
decision step further - with the manufacturing of the most at-
tractive design.
All of these designs are (irrespective of their often beautiful
representations in drawings, mock-ups, scale models and the
like) in the domain of the mind. Yet, that is not the intended
final station, like knowledge in the research cycle. The design
result requires to be realized in the domain of material reality,
in order to leave the possible world in which it was conceived
and to enter the factual world as a product. Does the final
product of the research cycle (new knowledge in the form of
laws of nature or theories) not belong to the actual world? Yes,
but the difference is that this final product belongs to the
. domain of the mind in the actual world, and that is also the
final station. The design as a result of the design cycle is an
intermediate station. It points to the realized product as a final
124 Product Design: Fundamentals and Methods

station of the entire technological process, and that lies in the

domain of the material reality.
What follows is a summary of the differences between the two
cycles, placed one beside the other.

Designing Empirical scientific inquiry

Purpose Purpose
• The design cycle is aimed at • The research cycle is aimed
changing the world (real at knowledge about the
structures). world (mental structures).
• Technology plays most im- • Science plays most im-
portant part, science has an portant part, technology has
attending (instrumental) role. an attending (instrumental)
• The design cycle takes place role.
essentially in the domain of • The research cycle takes
the mind but enters in place necessarily in both the
certain cases the domain of domain of the mind and the
material reality (during sim- domain of the material
ulation). reality.
• The design cycle aims at the • The research cycle aims at
construction of possible (not images of the real world.
yet real) worlds.
Practical problem Theoretical problem
• The facts do not agree with • The facts do not agree with
our values and preferences. the theory. The facts are un-
Values are unassailable; assailable; hence the theory
. hence the facts have to be has to be adjusted.
adjusted. • The problem applies to the
• The problem applies to the area of factual statements in
area of value judgements in the domain of the mind.
the domain of the mind.
Analysis Observation
• By reasoning. • By observation and mea-
• Led by values. surement.
• As value-free (objectively) as
possible.
Synthesis Induction
• Pattern of reasoning: in- • Pattern of reasoning: induc-
noduction. tion.
• Aimed at the totality. • Aimed at an aspect.
The Structure of the Design Process 125
• A priori of the reality to be • A posteriori of the reality
realized. considered.

Simulation Deduction
• Simulation compnses two • Deductions can immediately
phases: be made from results of the
(a) construction of a simula- induction phase.
tion model • Deduction takes place in
(b) deduction based on the domain of the mind.
model. • The result is a categorical
• Deduction can (need not) be prediction.
supported by experiments • The result concerns an
with a physical model. aspect.
• The result is a conditional
prediction.
• The result concerns beha-
viour of the designed
product or process in its
totality.
Evaluation Testing
• Compares design with goal • Compares prediction and
(design specification). fact.
• Directed at values. • Directed at truth.
• Takes place in domain of the • Takes place in the domain of
mind. material reality.
Decision Evaluation
• If positive: the design is • If positive: final station of
passed on for realization. It is process reached.
an intermediate station. • The result is added to the
• The final result is not the amount of knowledge in the
design, but the realized domain of the mind.
product, which is added to
the area of teclmology in the
material reality.

References [1] Hall, A. D., Three-dimensional morphology of systems engineering.

IEEE Transactions on Systems Science and Cybernetics, SSC-5 (1969) 2,
156-160.
[2] Groot, A. D. de, Methodology: Foundations of Inference and Research in
the Behavioral Sciences. The Hague: Mouton, 1969, p. 6.
[3] Groot, A. D. de, Methodology: Foundations of Inference and Research in
the Behavioral Sciences. The Hague: Mouton, 1969, pp.l0-11.
126 Product Design: Fundamentals and Methods

[4] Groot, A. D. de, Methodology: Foundations of Inference and Research in

the Behavioral Sciences. The Hague: Mouton, 1969, pp.16-17.
[5] Hall, A. D., A Methodology for Systems Engineering, 6th edition.
Princeton, NJ.: Van Nostrand, 1968, pp.85-91.
[6] Hall, A. D., A Methodology for Systems Engineering, 6th edition.
Princeton, NJ.: Van Nostrand, 1968, p.90.
[7] Archer, L. B., Technological Innovation; a Methodology. Frimley: In-
forlink, 1971.
[8] Archer, L. B., Design Awareness and Planned Creativity in Industry.
London: Design Council, 1974.
[9] Lewis, W. & A. Samuel, Fundamentals of Engineering Design. New
York: Prentice Hall, 1989, p.12.
[10] Manheim, M. L., Problem-solving Processes in Planning and Design.
Cambridge, Mass.: MIT, 1967.
[11] Rzevski, G., On the design of a design methodology. In: R. Jacques
& J. A. Powell (eds.), Design: Science: Method. Proceedings of the 1980
Design Research Society Conference. Guildford, Surrey: Westbury
House, 1981, pp.6-17.
[12] French, M. Conceptual Design for Engineers, 2nd edition. London:
Design Council, 1985, p. 8. (Earlier published as Engineering Design:
the Conceptual Stage. London: Heinemann, 1971.)
[13] Lawson, B. R., Cognitive strategies in architectural design. Ergo-
nomics, 22 (1979) 1, 59-68.
[14] Archer, L. B., Whatever became of design methodology? Design
Studies, 1 (1979) 1, 17-18.
[15] Hubka, V. & W. E. Eder, Theory of Technical Systems; a Total Concept
Theory for Engineering Design. Berlin: Springer, 1988, pp. 58~92, 241-
254. (Translation of V. Hubka, Theorie Technischer Systeme. Berlin:
Springer, 1984.)
[16] Kramer, N. J. T. A. & J. de Smit, Systems Thinking; Concepts and
Notices. Leiden: Nijhoff, 1977.
[17] Hansen, F., Konstruktionswissenschaft; Grundlagen und Methoden, 2nd
edition. Berlin: Verlag Technik, 1976, pp.51-61. '
[18] Hansen, F., Konstruktionswissenschaft; Grundlagen und Methoden, 2nd
edition. Berlin: Verlag Technik, 1976, pp.46-47.
[19] Hubka, V. & W. E. Eder, Theory of Technical Systems; a Total Concept
Theory for Engineering Design. Berlin: Springer, 1988, pp. 143-145.
(Translation of V. Hubka, Theone Technischer Systeme. Berlin:
Springer, 1984.)
[20] Hubka, V. & W. E. Eder, Theory of Technical Systems;·a Total Concept
Theory for Engineering Design. Berlin: Springer, 1988, pp. 168-173.
(Translation of V. Hubka, Theorie Technischer Systeme. Berlin:
Springer, 1984.)
[21] Hubka, V. & W. E. Eder, Theory of Technical Systems; a Total Concept
Theory for Engineering Design. Berlin: Springer, 1988, pp.71-72.
(Translation of V. Hubka, Theorie Technischer Systeme. Berlin:
Springer, 1984.)
[22] French, M. J., Conceptual Design for Engineers, 2nd edition. London:
Design Council, 1985. (Earlier published as Engineering Design: the
Conceptual Stage. London: Heinemann, 1971.)
[23] Pahl, G. & W. Beitz, Engineering Design; a Systematic Approach
London: Design Council, 1984, Chapter 3: The design process.
(English translation by K. Wallace (ed.) of, Konstruktionslehre;
Handbuch fur Studium und Praxis, 2nd edition. Berlin: Springer,
1986.)
The Structure of the Design Process 127
[24] Hubka, V., Principles of Engineering Design. New York: Springer,
1989.
[25] VDI 2221, Systematic approach to the design of technical systems
and products. DUsseldorf, Verein Deutscher Ingenieure, 1987.
(Translation of the German edition Methodik zum Entwickeln und
Konstruieren technischer Systeme und Produkte. DUsseldorf: Verein
Deutscher Ingenieure, 1986.)
[26] Pugh, S. Total Design; Integrated Methods for Successful Product En-
gineering. Wokingham: Addison-Wesley, 1961, p.ll.
[27] Ullman, D. G., The Mechanical Design Process. New York: McGraw-
Hill,1992.
[28] Kroonenberg, H. H. & F. J. van den & Siers, Methodisch ontwerpen;
ontwerpmethoden, voorbeelden, cases en oefeningen. Culemborg: Edu-
caboek, 1992.
[29] French, M., Conceptual Design for Engineers, 2nd edition. London:
Design Council, 1985, p.l. (Earlier published as Engineering Design:
the Conceptual Stage. London: Heinemann, 1971.)
[30] Roozenburg, N. F. M. & N. G. Cross, Models of the design process;
integrating across the disciplines. Design Studies, 12 (1991) 4, 215-
220.
[31] Franke, H. J., Konstruktionsmethodik und Konstruktionspraxis; eine
kritische Betrachtung. In: Proceedings of the International Conference on
Engineering Design (ICED '85), Hamburg, August 1985, volume 2.
ZUrich: Heurista, 1985, pp.910-924 (WDK 12).
.[32] Pahl, G., Notwendigkeit und Grenze der Konstruktionsrnethodik.
In: Proceedings of the International Conference on Engineering (ICED
'90) Dubrovnik, August 1990. Zurich: Heurista, 1990 (WDK 19).
[33] Andreasen, M., Gestaltungstheorie und Methoden. In: Proceedings of .
the International Conference on Engineering Design (ICED '83), Co-
penhagen, August 1983, volume 1. Zurich: Heurista, 1983, pp. 189-
196 (WDK 10).
[34] Pahl, G., Vorgehen beim Entwerfen. In: Proceedings of the International-
Conference on Engineering Design (ICED '83), Copenhagen, August
1983, volume 1. ZUrich: Heurista, 1983, pp. 209-219 (WDK 10).
[35] Schregenberger, J. W., Neue Impulse fur die Konstrucktionsmetho-
dik. In: Proceedings of the International Conference on Engineering
Design (ICED '85), Hamburg, August 1985, volume 2. ZUrich:
Heurista, 1985, pp.893-898 (WDK 12).
[36] Riehm, U., Einige konzeptuelle Mangel der Kon-
struktionswissenschaft und ihre Auswirkungen auf CAD. In: Pro-
ceedings of the International Conference on Engineering Design (ICED
'83), Copenhagen, August 1983, volume 1. Zurich: Heurista, 1983,
pp.314-326 (WDK 10).
[37] Tjalve, E., Form design; a systematic approach. In: Proceedings of the
International Conference on Engineering Design (ICED '81), Rome,
August 1981, volume 1. Zurich: Heurista, 1981, pp. 559-571 (WDK 6).
[38] Franke, H. J., Konstruktionsmethodik und Konstruktionspraxis; eine
kritische Betrachtung. In: Proceedings of the International Conference on
Engineering Design (ICED '85), Hamburg, August 1985, volume 2.
Zurich: Heurista, 1985 (WDK 12).
[39] Riehm, U., Einige konzeptuelle Mangel der Kon-
struktionswissenschaft und ihre Auswirkungen auf CAD. In: Pro-
ceedings of the International Conference on Engineering Design (ICED
'83), Copenhagen, August 1983, volume 1. Zurich: Heurista, 1983
(WDK 10).
128 Product Design: Fundamentals and Methods

[40] Rutz, A., Konstruieren als gedanklicher Prozep. PhD Thesis, TU

Miinchen, 1985.
[41] Dylla, N., Denk- und Handlungsablaufe beim Konstruieren. Miinchen,
Hanser, 1991.
[42] Fricke, G., Konstruieren als flexibler ProblemlOseprozep; Empirische
Untersuchung uber erfolgreiche Strategien und methodische Vorge-
hensweisen. Dusseldorf: VOl Verlag, 1993 (PhD Thesis, TH Dann-
stadt).
[43] Crawford, C. M., New Product Management, 2nd edition.
Homewood, Ill.: Irwin, 1987, pp.21-23.
[44] Archer, L. H., Technological Innovation; a Methodology. Frimley: In-
forlink,1971.
[45] Geyer, E., Kreativitiit im Unternehmen; Erkennen-Fordern-Nutzen.
Landsberg: Verlag Modeme Industrie, 1987.