KROES Design Methodology
KROES Design Methodology
KROES Design Methodology
technical artefacts
Peter Kroes, Department of Philosophy, Faculty of Technology, Policy
and Management, Delft University of Technology, Jaffalaan 5, Nl-2628
BX Delft, The Netherlands
T
he aim of design methodology is to improve design processes; this
means that it takes a normative stance towards its object of study.
Given this aim it is no surprise that research in design methodology
has always had a strong focus on the nature of design processes. The study
of the nature of technical artefacts, considered to be the outcome of a
design process, has received little attention. For several reasons, however,
including its normative standpoint, design methodology cannot avoid a
closer analysis of the nature of technical artefacts. Here, an interpretation
of technical artefacts in terms of a dual naturewhich refers to the fact
www.elsevier.com/locate/destud
0142-694X/02 $ - see front matter Design Studies 23 (2002) 287302
PII: S0142-694X(01)00039-4 287
2002 Elsevier Science Ltd All rights reserved Printed in Great Britain
that they are physical and intentional objects at the same timeis offered
and it is argued that this interpretation has far-reaching consequences for
the research agenda of design methodology. The paper starts with a com-
parison of design methodology with the methodology of science. This is
followed by an exposition of the dual nature of technical artefacts. Finally,
some consequences of this interpretation of technical artefacts for the
research agenda of design methodology are discussed.
A look at the broader field of design research indeed confirms the strong
bent towards processes and activities in this field. According to Dorst, two
paradigms within design research can be distinguished, design as rational
problem solving and design as reflective practice, and both are process
oriented2. Scho ns theory about the reflective practitioner, which has
attracted much attention in recent years within design research, approaches
design as a reflective process5. Bucciarellis work, also well known within
this field, analyses design as an essentially social process6. Finally, a quick
scan of the contents of volumes 16 (1995) through 22 (2001) of one of the
leading journals in this field, Design Studies, confirms the strong process
orientation. The topics addressed typically concern: (creativity in) design
thinking, design education, design effort, conceptual design as a process,
design progress, communication of design knowledge, managing design
4 Cross, N A History of design
methodology in M J De Vries, information, the role of computers in design, design as a cognitive activity,
N Cross and D P Grant (eds)
decision making in design, etc. This journal explicitly presents itself as a
Design methodology and
relationships with science, forum for the discussion and development of the theoretical aspects of
Kluwer Academic Publishers,
Dordrecht (1993) pp 1527
design, including its methodology and values, but almost without exception
5 Schon, D The reflective prac- the methodological contributions concern the actual methods and tech-
titioner; how professionals think
in action Ashgate, Aldershot niques used in solving design tasks, not the methods and techniques used
(1991)
6 Bucciarelli, L L Designing in justifying the outcome of a design process (see note 2).
engineers The MIT Press, Cam-
bridge, MA (1994)
7 Galle, P Design rationaliz- So, there are two differences between design methodology and research
ation and the logic of design: a
methodology: the former takes a normative stance and is process oriented,
case study Design Studies Vol
17 No 3 (1996) 253275 the latter is descriptive and product oriented (see Figure 1). Compared to
What is a design?
What makes a design a good or a successful design?
What are the proper criteria for evaluating proposed solutions for a
given design problem?
Is it possible to characterise in a general (logical?) way notions such
as the effectiveness and efficiency of design solutions?
How can a proposed solution for a design problem be rationally justi-
fied?
How can design decisions with regard to trade-offs between conflicting
8 Verein Deutscher Inge-
nieure (VDI) Systematic design specifications be rationally justified?
approach to the design of techni-
cal systems and products: Guid-
eline VDI 2221 Beuth Verlag, Shifting attention from design solutions to design methods, the following
Berlin (1987)
9 Kroes P Engineering design questions crop up.
and the empirical turn in the
philosophy of technology in P Does the correct application of design methods guarantee a successful
Kroes and A Meijers (eds) The
empirical turn in the philosophy outcome or make a successful outcome probable to a certain degree?
of technology (C Mitcham (series
ed)) Research in philosophy and
If so, is there a logic of design methods, that is, can we understand this
technology Vol 20, JAI/Elsevier, property of design methods from a logical (analytical) point of view?
Amsterdam (2000) 1943
10 Simon, H A The sciences of
the artificial, 3rd edn The MIT
Press, Cambridge, MA (1996) Furthermore, a technological design (ideally) contains an explanation of
11 Kroes, P A Technical func- how a given physical (chemical, biological) device realises a certain func-
tions as dispositions: a critical
assessment Techne` Vol 5 No 3 tion.
(2001) 16
12 Losonsky, M The nature of How is such a technological explanation, i.e. an explanation of a func-
artifacts Philosophy Vol 65
(1990) 8188 tion in terms of a physical (chemical, etc.) structure, possible?
Design methodology, as it has been practised up till now, has largely neg-
lected these questions. Because it aims at the improvement of design prac-
tice, it has focused mainly on the design process. By analysing in detail
the nature of this process, it tries to rationally reconstruct it in the sense
described earlier. In my opinion, however, design methodology will have
to address some of the issues described above for at least two reasons. The
first is that the design process and the design product are so intimately
related to each other that an understanding of the nature of the design
process requires insight into the nature of the product designed and vice
versa. Consider the design of various kinds of artefacts, e.g. the steering
wheel of a car, an air bag, a car, a car transport system, a police system,
a law on traffic regulations. Roughly speaking, these artefacts may be
ordered on an axis ranging from technical objects through socio-technical
objects to social objects. It is a matter of fact that the design processes
which lie at the basis of these various kinds of artefacts differ strongly. It
seems implausible that it will be possible to construct a domain-inde-
pendent theory about design processes, which will cover all these cases
(see note 4). An analysis of the design process of technical artefacts should
therefore take into account the specific nature of those objects (see note
5). Second, the normative stance taken by design methodology towards the
design process implies that it cannot escape questions concerning the qual-
ity of the outcome of that process. Since that outcome is the design of a
technical artefact, it has to address some of the questions listed above about
criteria for success of a design. So, let us now turn to a closer analysis of
the nature of technical artefacts.
Let us look a little more closely at the functional or purposeful aspect of artificial
things. Fulfilment of purpose or adaptation to a goal involves a relation among three
terms: the purpose or goal, the character of the artifact, and the environment in which
the artifact performs.
For instance, the purpose of a clock is to tell time and the character of the
clock refers to its physical make-up (gears, springs, etc., for a mechanical
clock). Finally, the environment is important because not every kind of
clock is useful in every environment; sundials can only perform their func-
tion in sunny climates. Simons analysis of artefacts is represented in a
schematic way in Figure 2 (see note 6).
reference to the interface between what I have called the inner and outer
environments. These two different ways of characterising an artefact, in
terms of its inner and outer environment, correspond closely to what we
call the dual nature of technical artefacts.
The view that technical artefacts have a dual nature finds its origin in the
observation that we employ in our thinking, speaking and doing two basic
conceptualisations of the world, and that we do not know how to integrate
these two together into one coherent conceptualisation (see note 8). On the
one hand, we see the world as consisting of physical objects interacting
through causal connections. This will be called the physical or structural
conceptualisation which is employed and developed by the physical
sciences. On the other hand, we see the world as consisting partly of agents
(primarily human beings), who intentionally represent the world and act
intentionally in it, and whose behaviour is explained partly in terms of
reasons (and not causes). This is the intentional conceptualisation of the
The question that concerns us is how technical artefacts fit into these two
conceptualisations of the world. Our starting point for exploring this issue
will be the following characterisation of technical artefacts: technical arte-
facts are objects with a technical function and with a physical structure
consciously designed, produced and used by humans to realise its function
(see note 9). In short, a technical artefact is a physical object with a techni-
cal function. This characterisation of a technical artefact makes it a hybrid
kind of object which does not fit in either the physical or the intentional
conceptualisation. Looked upon as merely physical objects, technical arte-
facts fit into the physical conceptualisation of the world; the way the arte-
fact works can be explained in terms of causal processes. But as a mere
physical object, it is not a technical artefact. Without its function, the object
loses its status as a technical artefact. This means that technical artefacts
cannot be described exhaustively within the physical conceptualisation,
since it has no place for its functional features. But neither can it be
described exhaustively within the intentional conceptualisation since its
functionality must be realised through an appropriate physical structure and
the intentional conceptualisation has no place for the physical features of
a technical artefact (see note 10). Hence the conclusion that technical arte-
facts have a dual nature: on the one hand they are physical, on the other
intentional objects.
The inclusion of the context of human action into our analysis of artefacts
needs some clarification, since we have characterised technical artefacts
earlier as physical objects with technical functions. I have included the
context of human action because it makes no sense to speak about technical
functions without reference to a context of human action. As remarked
earlier, functional discourse is part of the intentional conceptualisation of
the world; it is meaningless to speak about technical functions without a
The main difference between Simons analysis and ours is that the latter
gives a much more prominent and explicit place to a context of human
action in analysing the nature of technical artefacts. The advantage of this
is that it brings much more into the open the dual nature of technical
artefacts: we cannot make sense of technical artefacts without taking into
consideration their physical structure, but also not without their context of
intentional human action. Within Simons analysis this dual nature stays
more implicit and is related to the two different perspectives on technical
artefacts, namely the perspective of the inner environment (physical
structure) and the perspective of the outer environment (context of
human action).
the task of the designer to fill this black box with a physical structure such
that this structure will realise the intended function. The output of a design
process, therefore, is a description of a physical structure which adequately
performs the function, that is, with a design of the technical artefact (which
may be taken to include the user manual).
What kind of design methods are used by designers to bridge the gap
between the two modes of describing technical artefacts?
How are we to interpret the role of these design methods in bridging
the gap between the two conceptualisations of the artefact. In other
words, can we provide a rational account of the use of these design
methods, showing why their use is successful, given the conceptual gap?
How do designers explain the function of an artefact in terms of its
structure?
How can a function be explained in terms of a physical structure, given
the conceptual gap between the two kinds of descriptions involved (see
note 14)?
The final topic that I would like to draw attention to concerns the quality
of a design, in particular the notion of a successful design. It is self-evident
that design methodology has to establish some criteria for the quality, the
success and the failure of design processes if we are to take its normative
So, what are the criteria for quality on the basis of which design processes
may be evaluated? In line with their process orientation, design methodolo-
gists seem to have approached this problem primarily from the point of
view of the organisation and management of design processes. There are
many prescriptive phase diagrams of how to split up the overall design
process into various parts. The suggestion is implied, explicitly or
implicitly, that following these diagrams will lead to or at least contribute
to the quality (success) of the design process. Thus, implementing
adequately the prescriptive phase diagram becomes a criterion for success.
Without an assumption of this kind, the rationale behind these diagrams
becomes problematic. This may be part of the answer, but it is highly
questionable whether it addresses the real issues involved. It is not difficult
to imagine, and probably has often actually been the case, that a design
process follows painstakingly all the required procedures and nevertheless
its outcome is deemed a failure by the people involved. In such cases, the
design process has to be considered a success, whereas its outcome is a
failure (the proverbial successful operation with a dead patient). Con-
versely, a badly organised and poorly managed design process may lead
to an excellent design.
The relationship between the quality of a design process and the quality
of its outcome does not seem to be straightforward. Abiding by the rules
of procedural rationality is not a sufficient criterion for success (neither
does it seem to be a necessary criterion). More is involved, namely the
criteria in terms of which the outcome of a design process is evaluated.
So, we arrive at the question: What is a good or successful design? That
itself is a complicated issue and it is doubtful that there is one set of criteria
that is universally valid in every context. In our analysis of technical arte-
facts we have distinguished so far two different contexts of human action,
namely the design context and the use context. It is not at all self-evident
that the same criteria for quality apply in both contexts. Within a design
context, a general criterion for success may be that a proposed design meets
all the specifications and constraints. A particular design that satisfies this
criterion may nevertheless be considered a failure in the context of use
because it does not meet the expectations or satisfy the needs of the users;
the latter will be their criterion of success. This situation may be due to,
for instance, poor communication between designers and users about the
Apart from the context of design and the context of use, technical artefacts
figure in many other contexts of human action, such as the context of
production, context of maintenance, context of consumer markets, etc.
Each of these contexts has its own criteria for quality and success which
may be relevant to the way the quality of the design of the artefact is
evaluated. Aesthetic criteria pose a problem of their own in evaluating the
quality of a design because it is a problem to find objective standards for
these criteria (see note 17). Moreover, the importance of these criteria var-
ies strongly over different engineering domains (for instance, in many areas
of electrical and mechanical engineering they are almost irrelevant,
whereas in architecture they are important). There is but one conclusion
to be drawn from the foregoing, namely that a clear insight into the notion
of the quality (success) of a design or a design process is lacking.
Acknowledgements
I would like to thank the members of the Department of Philosophy of the
Delft University of Technology for their valuable comments on an earlier
version of this paper.