Reymen, I.M.M.J., Hammer, D.K. (2000) “Design method supporting regular reflection on design situations”, Third
International Symposium on Tools and Methods of Competitive Engineering, April 18-21, 2000, Delft, The
Netherlands, in Proceedings of the Third International Symposium on Tools and Methods of Competitive
Engineering, ed. Horvath et al., Delft University Press, Delft, The Netherlands, pp. 325-338.
DESIGN METHOD SUPPORTING REGULAR REFLECTION ON
DESIGN SITUATIONS
I.M.M.J. Reymen
Stan Ackermans Institute
Eindhoven University of Technology
The Netherlands
D.K. Hammer
Faculty of Mathematics and Computing Science
Eindhoven University of Technology
The Netherlands
ABSTRACT
This paper describes a domain-independent
design method developed to support designers
during the whole design process. The goal of the
design method is to make designers more aware
of the design situation at important points of the
design process. A design situation at a certain
moment in time is defined as the state of the
product being designed, the state of the design
process, and the state of the design context. The
design method supports the creation of a
description of the design situation at the
beginning and at the end of important design
sessions. A design session is defined as a period
of time during which designers are working, for
example, from 9 to 12 o’clock. The design
philosophy that underlies the design method is
also described. In this philosophy, the design
process is seen as a sequence of state transitions.
KEYWORDS
Design philosophy, design session, description of
a design situation, design context, state transition.
1. INTRODUCTION
Designers in practice are often not aware of the
design process and of the design context they are
working in. This is one of the observations made
during the case studies (Reymen, 1998) we
conducted as part of this research. Designers are
usually only focused on (part of) the product they
have to design. However, the design process and
the design context also influence the product
being designed. The product, the design process,
and the design context at a certain moment are
closely linked to each other. Their states
determine the design situation.
Awareness of the design situation at certain
moments during the design process can be
important for four reasons.
− First, making a design situation explicit
creates a more profound base for decisions.
− Second, the design situation influences the
next action to be taken in the design process.
Being aware of the situation can be of
strategic importance.
− Third, to improve the current design process,
it is important to relate it with the state of the
product being designed and with the design
context at that moment.
− Finally, awareness of the design process is
also important to learn from the current
process and to improve design skills for
future design processes.
Designers can become aware of design situations
by reflecting on these situations. These
reflections must not interrupt the creative
processes. Therefore, it would not be desirable to
be constantly aware of the complete design
situation. Neither would it be useful to reflect
only at the beginning or at the end of the
complete design process. Reflecting regularly
about the design situation, at important points of
the design process, seems useful. This is also
concluded in (Dorst, 1997). Dorst observes that a
designer is inside a design process (thrown into a
situation) and is not always in the position to
consider the process critically and rationally.
Therefore, a designer that wants to be in control
of the design process must step out of the
‘designerly way of thinking’ (Cross, 1994) every
now and then.
Most designers in practice are not used to reflect
regularly on design situations. In addition, in
current design education, reflection on design
situations is not a real topic. This creates the need
for supporting designers with methods and tools
for reflection.
The goal of this work is to develop a domainindependent design method to support regular
reflection on the design situation. We strive for a
domain-independent approach because we feel
that designing in different disciplines has much in
common. Furthermore, domain independence is
also necessary for investigating the design
activities in multidisciplinary teams. Finally, such
a generic approach can generate new views on the
traditional design process of a given discipline.
In order to be useful, the generic methods and
tools must, of course, be tailored to the specific
needs of the specific design disciplines.
In the next section, the research methodology is
briefly described. Section 3 describes a model of
the design process and the underlying design
philosophy. The design method itself is described
in Section 4. The results are discussed and
compared with existing literature in Section 5.
The paper ends with a conclusion and an
overview of further research.
2. METHODOLOGY
This research is part of an explorative study,
namely the Ph.D. research of the first author. The
investigation includes a literature study and
empirical research with case studies. Design
projects in three disciplines (architecture,
mechanical
engineering,
and
software
engineering) have been compared in a cross-case
analysis. A design philosophy, common for the
three disciplines, is being developed and used for
the development of domain-independent design
support. A design frame, the described design
method, and a derived tool are currently being
developed as possible support. The design
philosophy offers descriptive knowledge. The
design frame, method, and tool can be categorised
as prescriptive. The design method and tool will
be tested by design students and designers in
practice.
3. DESIGN PHILOSOPHY AND
MODEL
The design process can be described from
different points of view. Typical examples are the
creative, social, iterative, or informationprocessing views. Designing can also be
described as a situated activity (Dorst, 1999). It is
not possible to give a general definition of
designing. In (Dorst, 1999), it is stated that
designing can (generally) be viewed from two
sides: rational problem solving and reflective
practice.
A design philosophy reflects one or more of these
viewpoints. It is a way of thinking about how
design is, might be, or should be done. In the
literature, different design philosophies exist. A
design model is a representation of a particular
aspect of a design philosophy. The design process
is also captured in many different design models,
depending on the viewpoint on designing. For
many design models, the design philosophy is not
made explicit. Examples of design philosophies
and design models can be found in (Evbuomwan
et al., 1996).
In this investigation, the design process is viewed
as a sequence of state transitions. A design
situation is seen as a state and design activities
cause state transitions. This viewpoint is chosen
because it suits the goal of the research: It is
intuitive and easy to understand and it offers a
clear view on designing. A disadvantage is that it
is a mechanistic and abstract view on the complex
human activity of designing.
The above viewpoint is elaborated in a design
philosophy developed to describe our point of
view on designing and to offer concepts for the
development of the design method and tool. The
design philosophy can also be combined with
other philosophies, for example, with the
philosophy that sees designing as a creative
process. The design philosophy is represented in
a design model.
The design philosophy is described in Subsection
3.1. The resulting model of the design process is
presented in Subsection 3.2.
3.1. Design philosophy based on
state-transition systems
The design philosophy is based on the
mathematical concept of state-transition systems,
developed in computer science. Many processes
can be described as state-transition systems: for
example, workflow processes, logistics processes,
and assembly processes. The design philosophy
presented here uses this concept to describe
design processes. Only the external behaviour of
designers and not the cognitive aspects of
designing are described.
The design philosophy is a set of concepts,
explained by definitions. Only the basic
definitions of state-transition systems are used
and translated to design processes. The
definitions are formulated from a pragmatic point
of view and are not necessarily completely
correct from an epistemological and ontological
point of view. The vocabulary is chosen to
resemble the terminology used in design practice,
but domain independent.
In the next paragraphs, general definitions
concerning state-transitions systems with
accompanying examples are given. These general
concepts are adapted to modelling the design
process and are illustrated with ‘design’
examples. First, the concept of a state is
described. This results in the definition of a
design situation. Then, design activities are
defined as actions causing state transitions. A
definition of the design process is given in
Paragraph 3.1.3. Paragraph 3.1.4 introduces the
concept of a design task. Finally, in Paragraph
3.1.5, a definition of designing is derived.
3.1.1 A design situation as a state
In the theory of state-transition systems, a state is
defined as a set of values for all properties and
factors describing an entity at a certain moment in
time. In this definition, an entity is an object or a
process. An entity is for example a football or a
cooking process. A property is an internal
characteristic of an entity. An entity can have a
set of properties. A property can have a set of
values. A property is for example the colour of
the football or its position. The values of these
properties can be ‘white’ or ‘yellow’ and ‘on the
ground’ or ‘in the air’. A factor is something
external that can influence an entity. An entity
can have a set of factors influencing it. A factor
can have a set of values. A factor influencing the
football is for example the foot or head of a
football player. The value of this factor is the
‘force’ and ‘direction’ of the kick. Whether a
factor really influences an entity depends on the
state of the entity. Not all factors are relevant at
any given moment. A state at a given moment is
thus described by the values of all properties and
factors at this moment. For example, the state of a
football might be ‘white’ and ‘on the ground’.
An object representation or a process
representation is a description of the set of
properties and values of this object or process.
Many different representations can be made of
one entity. A representation can also be made on
different media: text, drawings, models, computer
visualisations, prototypes, or mental images. For
example, a representation of the football is a
textual description or a drawing.
Different
representations of the same entity are not always
consistent. A mental representation can be
different
from
the
existing
physical
representations.
The above mentioned terminology can be
translated to the context of designing as follows.
An entity is a product or a design process. A
detailed definition of a design process is given in
Paragraph 3.1.3. A product is an artefact (that
must be designed) satisfying a human need, for
example, a garden house. This artefact can be a
physical object or a process. Examples of objects
are production machines, buildings, or software
programs. Examples of processes are social
processes,
design
processes,
production
processes, or logistics processes. In the remainder
of this paper, the concept of product being
designed is used because the product itself does
not exist yet during the design process. The life of
a product is represented by its product lifecycle.
This is a representation of the product evolution,
starting from need, continuing with design,
production, use, and reuse, and ending with
decommissioning.
A design property is defined as an internal
characteristic of the product being designed or of
the design process. A design factor is something
external that influences (properties of) the
product being designed or the design process. A
design factor has the potential to influence the
final product or the design process. The influence
can be in the past, present, or future. Design
factors are not determined by the designer(s);
they are part of the design context. The design
context is defined as the set of factors influencing
the product being designed and the design process
at a certain moment. In the remainder, design
properties and design factors are just called
properties and factors.
Examples of properties of a product are the
dimensions and the kind of coating of a garden
house. Values for these properties are: ‘2.5m
high’, ‘1.8m wide, ‘1.8m long, and ‘coating with
ingredients’ X’. Properties of a design process are
for example duration and cost, but also the mood
of the designer and his/her experience with the
design of this kind of products. Related values are
‘halfway estimated duration’, ‘$15000 spent
already’, ‘just married’, and ‘large experience’.
Possible factors in the design context are
dimensions
of
production
machines,
environmental laws; values for these factors are
‘maximum volume of one plank’, ‘only coatings
allowed without ingredients ‘Y’’.
Designers transform only representations of the
product and not the product itself. A product
representation is a description of a set of
properties and values of the product being
designed. The product representation during, or
resulting from, a design process is also called a
design. A representation of the garden house is
for example a drawing with the dimensions or a
3D model. A design-process representation is a
description of the set of properties and values of
the design process. A representation of the
product being designed or of the design process
for a specific stakeholder is called documentation.
A representation of the design process is for
example a planning or an organisation scheme. A
representation of the design context is a
description of the set of factors influencing the
product being designed and the design process at
a certain moment. For example, some factors in
the design context can be represented by a list of
dimensions of the production machines and by
laws.
The state of a product is defined as a set of values
for all properties of the product at a certain
moment in time. The state of a design process is
a set of values for all properties of the design
process at a certain moment. Finally, the state of
the design context is the set of values for all
factors influencing the product being designed
and the design process at a certain moment. The
size of the set of properties and the set of factors
depends on the level of detail to which the
product and design process are modelled.
A design situation at a certain moment is defined
as the state of the product being designed, the
state of the design process, and the state of the
design context at that moment. This means that it
is
− the set of values of all properties of the
product being designed,
− the set of values of all properties of the
design process, and
− the set of values of all factors influencing the
product being designed and the design
process.
This is illustrated in Figure 1. For example, it is
the following set of values:
− ‘2.5m high’, ‘1.8m wide’, ‘1.8m long’;
‘coating with ingredients ‘X’’ for the product;
− halfway estimated duration’ ‘$15000 spent
already’, ‘just married’, and ‘large
experience’ for the process;
− ‘maximum volume of one plank’, ‘only
coatings allowed without ingredients ‘Y’’ for
the design context.
Factors in
design
context
State of
context at t(i)
Properties
of product
+
State of
product at t(i)
time
Properties
of design
process
+
State of
process at t(i)
Design situation at time t(i)
Figure 1. A design situation as a state
The empirical basis for the concept of design
situations is illustrated in Table 1. We started
from the variables that are important in design
practice, namely product, design process, and
design context. These are observed in the case
studies we conducted as utterances of the
designers and as elements in representations of
the product and the design process. The latter
indicate decisions, which are values for properties
and factors in the philosophy. These properties
and values specify the state of the product, the
design process, and the design context. Their
combination is a design situation. This process of
conceptualisation is based on (Wester, 1991).
EMPIRICAL
Variable / product,
Category
process,
context
THEORETICAL
design
Concept
situation
Observable item
state of
product,
process,
context
values of
properties
or factors
Indicator
utterance,
element in
representation
decisions
Aspects /
Dimensions
Characteristics
Table 1. Empirical basis for the concept of design
situations
3.1.2 Design activities causing state
transitions
A change from one state to another is called a
state transition. A state determines the possible
state transitions. A transition is caused by one or
more actions. An action is executed by an actor.
For example, the state of a football at a certain
moment is the set of values ‘white’ and ‘on the
ground’. After the action of kicking the ball,
executed by a football player, the values are
‘white’ and ‘in the air’.
A goal-oriented action is called a transformation;
an action without goal is called a mutation. A
goal is defined as the end towards which an effort
or ambition is directed. For example, when the
goal is ‘make a goal’, a transformation can be
kicking the ball. An example of a mutation is a
change in the position of the ball caused by the
wind.
A state can be changed by changing properties,
factors, or values. Changes may include additions
or deletions of properties and factors. A state is
changed when at least one property, factor, or
value is changed. Every transition can comprise
one or more changes. In practice, a state is
changed by changing the representation of an
entity.
Translating these concepts to the context of
designing results in the following definitions.
Actors in the design process are called designers.
Stakeholders are actors in the design context. A
design goal can be defined as the goal of a design
activity or a design process.
A design activity is a transformation in the
direction of the design goal carried out by a
designer, causing a transition of the state of the
product being designed or of the design process.
This is illustrated in Figure 2. An example of a
design goal is to create a garden house with a
coating that guarantees a long life of the garden
house, but that is not too expensive. Design
activities can for example be fixing the estimated
life of the garden house on 15 years and
determining the ingredients of the coating.
Because a design activity is not further defined, it
can, for example, be both: making a complete
drawing of a garden house or drawing just one
line.
A design situation can be changed analogously to
changing a state. Possible state transitions are
adding or deleting properties or factors, or
changing their values. A design situation is
changed by a change in the state of the product or
of the design process, or by a change in (the state
of) the design context. When many designers are
making
changes
and
making
different
representations (mental and physical), these
representations will not always be consistent.
State of
product at t(i)
State of product at t(i+1)
State of process at t(i)
State of
process at
t(i+1)
time
Design activity
Figure 2. Design activities causing a state transition
Possible actions causing a state transition are
design activities of the designers or actions of
stakeholders in the design context. Designers can
change the properties of the product being
designed and of the design process. Stakeholders
can change factors in the design context. This
means that many more processes can change a
design situation than only the design process.
Notice that the concept of state transitions yields
a non-deterministic system. For the context of
designing, non-determinism is essential and is the
result of the free choices that can be made by the
designer. To execute transformations, creativity
of the designer is necessary.
Designers also execute actions that not directly
result in a state change, but which are necessary
to prepare such a change. Examples of such
actions are interactions between designers and
stakeholders to exchange information. The action
of a stakeholder can have a goal that may or that
may not coincide with the design goal, or that can
be independent of it.
3.1.3 A design process as a sequence of
state transitions
A process is defined as a sequence of
transformations with the same goal. The
transformations can be executed by one or more
actors, in sequence or in parallel, using one or
more aids. For example, a cooking process
consists of a sequence of actions (weighing
ingredients, preparation of food, boiling or
baking, and presentation) with the goal of making
dinner. The process is executed by a cook, using
the necessary ingredients and tools.
A process can be described by a sequence of state
transitions, i.e., a sequence of states, and a
sequence of transformations. Although the states
are ordered in time, nothing is said about the
length of the interval between the different states.
A design process is a sequence of design
activities, necessary to obtain the design goal. It
is a set of transformations executed by one or
more designers, in sequence or in parallel, using
one or more design aids, towards the design goal.
For example, the design process of a garden
house can consist of design activities executed by
the senior designer of the design department and
by some experts on coatings. They can for
example use CAD to model the garden house and
use other tools to analyse the behaviour of the
materials. Notice that the design process is, at the
same time, subject changes and the cause of these
changes.
A design goal is the goal of a design process, i.e.,
to create or improve one or more desired
representations of the product having a desired
final state. These representations must be useful
for communication within the design context and
for realisation. The design process must
eventually end with desired values for desired
properties. The final state of a product as desired
by the context and/or by the designers is reached
at the end of the design process.
3.1.4 Design task
Because designers influence the product being
designed and the design process, both are
combined in the concept of a design task. A
design task at a certain moment is a task to reach
(a sub-goal of) the design goal, starting from the
present state of the product being designed, of the
design process, and of the design context. A
design task is realised by executing design
activities. Figure 3 illustrates the definition.
State of
context
Design task
State of
product
State of
process
Design
goal
Design situation at t(i)
Design activity
Figure 3. Definition of a design task
A design task exists at every moment during the
design process. At the beginning of a design
process, the design task is defined by a
description of the desired product representation
and design process. At the end of the design
process, a design task can be defined by (a
representation of) the product and possibly
definitions of new design tasks. In practice, the
design task is not always explicitly defined.
For example, the design task halfway the design
process of the garden house can be defined by the
design goal, the present design situation, and the
desired state of the garden house and the design
process. The first is defined in Paragraph 3.1.2.
The second is given in Paragraph 3.1.1 in the
example of a design situation. The desired final
state of the garden house is for example a
complete production drawing on A2 format.
Values for the desired properties of the design
process are ‘duration of one month’ and ‘budget
of $25000’.
A design task is executed by one designer or
design team during a particular period. A specific
design task can emphasise the product or the
process. This is for example the case when either
the product or the process is standard.
Design tasks have a hierarchical relationship, as
illustrated in Figure 4. A design task can be a
well-defined part of an overall design process.
Different design tasks can be executed in parallel
or in sequence. Iteration between design tasks can
also occur. For example, the design of a garden
house can be subdivided into two different design
tasks that are related to each other: design of the
foundation and construction, and design of the
materials of the skin.
Design task
2
Design task
2.1
3.1.5 Definition of designing
As already stated in the introduction, it is
impossible to give a general definition of
designing. A definition is always part of a design
philosophy. In the design philosophy based on
state-transition systems, designing can be defined
as follows.
Designing is the activity of transforming the state
of the product being designed or of the design
process into another state towards the fulfilment
of the design goal, by transforming a
representation of the product or of the design
process.
3.2. Design model
Overall design task
Design task
1
design process, new design tasks can be created,
for example, to create a product variant or a new
version of the product.
Design task
3
Design task
2.2
The theory of state-transition systems is used to
model the design process. The design process is
seen as a finite sequence of state transitions.
Design situations can be changed by design
activities and by transformations or mutations in
the context. The goal of transformations in the
context does not necessarily coincide with the
design goal. The design model is given in Figure
5.
Context
Figure 4. Hierarchy of design tasks
A particular design task is restricted by the design
context. The design context is specific for a
certain design task on a certain moment. The
context of a design task includes all design tasks
at the same hierarchical level as well as the parent
design task. To execute a design task, also
information about the design context must be
given.
The context of a design task can change after
every transition. Factors from the design context
can for example be translated into properties of
the product being designed or of the design
process.
The different design tasks can be defined at the
beginning or during the overall design process.
The latter can be necessary when the existing
design task revealed too many problems and is
too complex, when more tasks can be executed in
parallel, or when tasks can be delegated to other
more specialised designers. Also at the end of the
Transformation
or mutation
State of
context
State of
context
State of
product
State of
product
State of
process
State of
process
time
Transformation:
Design activity
Design situation
at t(i)
Design situation at t(i+1)
Figure 5. Design model
With some explanation, the concepts and
terminology of the design philosophy must be
understandable for designers from different
disciplines. Although they usually do not use
terms like state and transition, they should
recognise what is meant with design situation,
design
activity,
product
and
process
representations, and design task. The definition
of design situation can be new because designers
are not used to consider the product, the design
process, and the design context together.
4.
the values of all properties and factors must be
made. This is explained in Paragraph 4.1.2. How
these properties and factors can be structured is
described in Paragraph 4.1.3. To inventory the
important properties and factors, a checklist can
be used, as described in Paragraph 4.1.4.
DESIGN METHOD
A design method is a set of guidelines that can be
followed by a designer. The goal of a design
method is to support the designer during (part of)
the design process. A design method is derived
from a design model.
Starting from our state-based design model, a
design method must support the designer in
structuring the sequence of state transformations
and in performing these transformations. The
design method described here supports the
designer with these two activities only indirectly:
It makes the designer aware of the current design
situation. Advantages of being aware of the
design situation have been mentioned in Section
1. The challenge of developing a design method is
to make it useful: It may not cost too much time
and designers should recognise its benefits.
In this section, our design method is presented.
First, the concepts of the design method are
described. Then, an overview of the design
method is given.
4.1. Concepts
The design method is developed to support
regular reflection on design situations. The
chosen approach is based on two main concepts.
− First, designers are supported to become
aware and reflect on the design situation by
describing it.
− Second, the overall design process is
structured into design sessions.
The first concept is based on the hypothesis that
the best way to become aware of a design
situation is to describe its relevant aspects
carefully. The second concept is based on the idea
that designers have to step out of the design
process to reflect on it. Because design sessions
are usually rather creative and unstructured, the
beginning and end of each session are the best
reflection points.
The concept of design sessions is explained in
more detail in Paragraph 4.1.1. To make a
description of a design situation, a description of
4.1.1 Design sessions
In the case studies, described in (Reymen, 1998),
we observed that there is already an inherent
structuring principle in the design process,
namely the working periods of designers. We
think that the beginning and end of such a
working period is a natural reflection point.
A design session is defined as a period of time
during which designers are working on a certain
design task. A design session is limited in time.
Breaks between sessions can be coffee or lunch,
interactions with stakeholders in the design
context, other meetings, periods spent working
for other projects, weekend, holidays, or others. A
design session can also be a group meeting.
Design sessions are usually shorter than the wellknown phases (often described in the literature
and used in practice) and these sessions exist
independent of the latter. Different design
sessions can have different length.
In our method, the design process consists of a
sequence of design sessions. A design session
consists of a number of design activities and state
transitions. Design sessions have a formalised
start and end, and are open in between. At the
beginning and end of a design session, the
designers can reflect on the design situation.
During the core of the design session, designers
can transform the state of the product being
designed and the state of the design process
towards the design goal. In other words, our
design method emphasises two important
activities, namely transformation and reflection.
This is illustrated in Figure 6.
Design
session
Design process
Reflection on
Reflection on
situation i
situation i+1
Transformations
Figure 6. Design sessions
A description of a design situation consists of a
description of properties and factors of a design
task with values for the attributes of the
properties and factors.
For design properties and factors, at least the
following attributes must be defined: label, text,
value, sources, reference, and rationale. These are
basic attributes. Attributes to distinguish and
structure the different properties and factors are
described in the next paragraph. All the attributes
have free text values. It depends on the design
situation which values are filled in. An
explanation of the different attributes and their
possible values is given below.
Label: globally unique identifier of a property or
factor, i.e., unique for the design task; for
example, ‘production machines’ for the factor
production machines.
Text: detailed description of a property or factor;
for example, the dimensions of production
machines.
Value: value (and dimension) of a property or
factor; for example, maximum volume of one
plank.
Sources: stakeholders or documents that
determine or influence a property or factor. Note
that this influence can concern all attributes.
Examples for sources are the marketing manager,
the production manager, requirements documents,
and standards.
Reference: link to additional documentation; for
example, ‘see documentation of machine layout’.
Rationale: rationale for the introduction of a
property or factor, or for the values of its
attributes; for example, ‘other dimensions will
cost too much in changing the machines’.
4.1.3 Structuring properties and factors
To describe the set of values of properties and
factors, some kind of structure is useful. Three
structuring principles are used to distinguish and
structure the different properties and factors.
These principles define five attributes that can be
added to the basic attributes to describe the
properties and factors in detail.
The first structuring principle is the subject at
hand: product, design process, or design context.
These three are the possible values for the subject
attribute. Properties can have the values product
or process. Factors have the value context. For
example, for the factor ‘production machines’, the
subject is ‘context’.
The next structuring principle is formed by the
three dimensions of the design frame of (Reymen,
1999), which is especially developed to structure
properties and factors. The three dimensions are
level, view, and time. Every property or factor
can be situated on a certain level. Properties and
factors are usually described at different levels of
abstraction. For every property and factor, one or
more points of view are important. These
viewpoints can be social, political, juridical,
ethical, economical, or other. All properties and
factors of the design task can be structured in time
by specifying at which stages in the product
lifecycle or in which processes in the product
development process the properties and factors
are important. These stages and processes are for
example the design process, the production
process, the sales process, and the re-use process.
These three dimensions determine the following
attributes: level, view, and time. The possible
values for the different attributes differ for the
different subjects. For example, for a product, the
levels can be the level of the garden house, the
level of the components, and the level of the
details. The levels for the process can be
development process, design process, and design
activity. For the context, the levels can be branch,
company, and discipline. The same holds for the
attributes view and time. For a product for
example, the values for view can be ‘use’, ‘makeability’, or ‘maintainability’ and for time ‘past’,
‘present’, and ‘future’ (or a specific process in the
product lifecycle). The values for these three
attributes can be predefined to enforce a
consistent terminology. The predefined values
can differ for every discipline, project, user, or
other.
An example can show the use of these attributes
for describing properties and factors. The factor
‘production machines’ can be situated on the
level ‘detail’, seen from the viewpoint ‘makeability’, and is important in ‘the future’
(production process).
The same structuring principle can also be used to
structure different design sessions. Designers can
decide to concentrate during a specific design
session on a certain level, on a certain viewpoint,
and on a certain process in the product lifecycle
or product development process. The values for
the three attributes are then fixed during this
session.
The last structuring principle is the idea of a
stadium. A property or factor can be a problem
statement, the definition of a requirement, or it
can already be an alternative or a solution. The
same property or factor can be described in
different
stadia.
Problem,
requirement,
alternative, and solution are different values for
the attribute stadium. Analogue values are the
following sets: issue, proposal, and decision;
question and answer. Values for the attribute
stadium can also be predefined. The values of
these attributes can be different for different
disciplines, projects, users, or other.
4.1.4 Inventorying properties and factors
To inventory all relevant properties and factors at
a certain moment, a checklist is developed. A
natural starting point for the design of a checklist
is to compare it with the explanation of the state
of a design task to an outsider. In that case, the
problem, the requirements, the alternatives, and
the obtained solutions are explained; the state of
the design process and other related processes are
given; and all factors in the context that influence
the design task are mentioned. The checklist
consists of questions about these different topics.
The topics are based on design practice and on
the literature. In case studies in design practice,
we inventoried important properties and factors
of design tasks (Reymen, 1998). Among others,
the following literature has been consulted:
(Badke et al., 1997), (Hubka, 1996), and (Hales,
1987). These describe factors influencing the
design process and/or the product. The general
structure of the checklist is domain independent,
but can be tailored to specific disciplines. The
structure of the checklist is shown in Table 2.
In the structure of the checklist, the three
subjects product, design process, and design
context and values of the attribute stadium
can be recognised.
CATEGORY
Design task
SUBCATEGORY
Name
Design team or designer
Design session
Date
Start time
DESIGN TASK (PROPERTIES)
Design process
Final result
Underlying reason
Challenge
Design team
Design aids
Stage
Problems/ Issues/
Questions
Requirements
Alternatives/ Proposals
Solutions/ Decisions/
Answers
Executed/ Planned
actions in design task
Executed/ Planned
interactions with context
Product to be
Problems/ Issues/
designed
Questions
Requirements
Alternatives/ Proposals
Solutions/ Decisions/
Answers
CONTEXT OF DESIGN TASK (FACTORS)
Design tasks
Overall design task
Related design tasks
Stakeholders and
Product lifecycle
concerns
Company and
Product planning
society
Company
Competitors
Discipline
Table 2. Structure of the checklist
4.2. Overview
This section first gives an overview of the
complete design method, then presents some
supporting documents for the design method, and
finally describes the potential use and some
advantages of the design method.
4.2.1 Complete design method
The design method that results from the
integration of the concepts presented in the
previous section can be described as follows.
A description of the design situation can be made
at the beginning and end of important design
sessions. The designers themselves have to define
what are important sessions. The actual design
situation must be compared with the previous
description of the design situation made during
the design process. Only the changes regarding
this description must be described.
VALUES
Product
Process
Context
The checklist can be used to inventory the
important properties and factors. For every
property or factor, values are then ascribed to all
attributes (basic attributes and attributes for
structuring). Table 3 gives an overview of the
different attributes and their corresponding
values.
Table 4. Predefined values for level, view, and time
ATTRIBUTE
Label
Text
Value
Source
Reference
Rationale
Subject
Stadium
Level
View
Time
VALUE
Free text
Free text
Free text
Free text
Free text
Free text
Product, process, context
Sets like problem, requirement,
alternative, and solution
Product levels, process levels,
context levels
Product views, process views,
context views
Processes in product lifecycle
and product development
process
During the core of a design session, the
representations of the product and the design
process can be transformed.
The sets of possible values for the attributes level,
view, and time can be predefined at the beginning
of the design process. A table like Table 4 can be
filled out. For a specific design session, three
values can be fixed for all properties and factors.
Views
Time
4.2.2 Supporting documents
The design method and its benefits are described
in an introduction to the designer. In this
introduction, the use of the method is explained
by means of examples. Two types of forms are
developed to be filled out by the designer. The
first type consists of the checklist with questions
about different topics, as described in Paragraph
4.1.4, and room to describe all the important
properties and factors of the specific design
situation. This form can be used at the beginning
and at the end of a design session. To describe in
detail every property and factor filled in on the
first type of form, a second type can be used. This
form consists of a list of all attributes, as
described in Paragraphs 4.1.2 and 4.1.3, and room
to describe values of these attributes. The two
types are shown in Figure 7.
Design situation
Table 3. Attributes and values
Although the same checklist is used for the
beginning and end of a design session, the
emphasis of the description differs. At the
beginning of a design session, attention is
typically focussed on the changes that occurred
between two design sessions, for example, in the
design context). At the end of a design session,
the description focuses on changes in the design
task.
Levels
Property/Factor
Properties
and factors
Attributes
Checklist
Type 1
Values
Type 2
Figure 7. Two types of forms
4.2.3 Use of the design method
The documents described in the previous
paragraph can be used by individual designers or
design teams. In design processes with multiple
teams, the project leader can already prescribe
important factors in the context. The design
method can also be used by students. Regular
reflection on the design situation can facilitate
and speed up the learning process of students.
The method is intended for simple and complex
problems, on different levels in the product
hierarchy, in different disciplines, for different
products, and for various design situations. The
method gives support during the whole design
process. The use of the method can be started at
every moment in the design process.
The method can also be used for different design
styles. For example, instead of starting with
describing the design situation, the designer can
immediately start with the core of the design
session and finally describe the changes in the
context and the design task. We recommend,
however, to make always a reflective description
at the end of the design session.
The use of the design method can be combined
with the use of other methods and techniques like
creativity techniques, CAD tools, or domain
specific methods and tools.
4.2.4 Advantages of the design method
Describing design situations with the design
method can offer designers the following. The
checklist described in Paragraph 4.1.4 can make
designers aware of the product as well as of the
design process and the design context. By making
an overview of the important properties and
factors, the danger is avoided that designers are
too much focused on unimportant aspects and
designers are aided not to forget important factors
that have to be included in the design. This can
result in more sound decisions and better design
documentation.
By describing values for the attributes based on
the three dimensions described in Paragraph
4.1.3, designers can become aware of these
dimensions. They can recognise the specific
levels and viewpoints of the properties and
factors in the design situation and the processes in
which the properties and factors are important.
Because stakeholders are interested in different
levels of detail, different aspects, and different
processes in the product lifecycle, the attributes
can also help to decide which documents are
necessary for which stakeholder.
The descriptions of the design situation can be
used by designers and researchers. The former
can use the descriptions
− as a source of inspiration for the next design
session,
− as a design-task-specific checklist,
−
as some kind of documentation, additionally
to the representations of the product and the
design process (for re-use and communication
or to build up design history),
− as a textual overview of all design
information, and last but not least
− to analyse and criticise the situation.
Researchers can use the descriptions of design
situations made by designers to inventory all
relevant aspects in design practice and to analyse
the evolution of the design process. Descriptions
made in different design disciplines can be
compared to allow the generalisation of
observations and the development of concepts for
multidisciplinary design.
5.
DISCUSSION AND COMPARISON
WITH LITERATURE
5.1 Design model
In the described design philosophy and the
corresponding design model, the design process is
seen as a sequence of state transitions. This
viewpoint does not exclude other views.
Simultaneously, the design process can be viewed
as a creative process. Since the design philosophy
makes interactions with the design context
explicit, it can also be seen as a social process.
The design process can also be seen as an
iterative process: Properties and factors are added
and deleted. The design philosophy is related to
the two sides of design described in (Dorst,
1999): problem solving as well as reflective
practice.
The concept of state transitions has already been
used in the field of design by Salustri and Venter
(1991). They defined the design process as a
series of time-dependent actions that transform
the information through a series of states. They
developed a theory that formalises design
information, rather than concentrating on the
description of the design process. They follow a
more formal approach, using symbolic logic.
5.2 Design method
The design method proposes designers to make
descriptions of design situations. In current
design practice, no descriptions of design
situations are made. However, making these
descriptions is similar to what designers already
do during a design process, namely making
representations of the product and of the design
process. (Usually, no representations of the
design context are made.)
Instead of asking designers to make descriptions
to reflect on the design situation, reflection can
also be stimulated by letting designers tell the
state of the design task and design context to
someone else. We have chosen for descriptions
because making descriptions is similar to making
representations. Descriptions also have the
advantage that they can be stored and returned to
later in the design process. Making descriptions
has the following disadvantages:
− Descriptions are only textual while designers
are often used to make graphical
representations;
− designers are not used to describe a state;
− designers dislike documenting;
− reflection on the whole design situation does
not make designing easier for the designer;
− it is an extra activity.
However, it might turn out that good descriptions
of design situations could replace some of the
other documentation.
The design method also proposes the use of
design sessions, as described in Paragraph 4.1.1.
In the literature, most design methods structure
the design process in phases, based on the state of
the process. In design practice, no design process
is really executed following these phases; two or
more phases can co-exist at the same time. Phases
are not very useful for regular reflection, because
it is unclear when one phase ends and another
starts. When using our design method, a
description of the design situation is made at the
beginning and at the end of a design session.
These shorter periods guarantee a more regular
reflection on the design situation. Because many
descriptions of design situations must be made
during a design process, the time needed for
doing so must be short. The estimation for our
description is that it takes at most ten minutes to
make one description.
The goal of the design method can be compared
to the objectives of the training developed by
Badke et al. (1999). They try to learn designers to
reflect on adequate and inadequate design
processes. Designers are taught to identify critical
situations. The training concept, however, is
completely different from the design method
described in this paper. The training asks
involvement of external observers and teachers.
As far as we know, the idea of design sessions is
not yet used for structuring design processes. The
attributes for structuring the various properties
and factors of a design situation are similar to the
ordering schemes for design information
described in (Salustri and Venter, 1991).
Different attributes are defined based on object
orientation and hypertext.
The method described in this paper can be placed
in the paradigm of reflective practice (Dorst,
1997). Reflective conversation with the situation
is stimulated by regularly making descriptions of
the design situation. In (Dorst, 1997), it is also
stated that any method for aiding design activities
must contain statements about the dynamics of a
design process, a model of the designer, and a
model of the structure of the design task. In our
opinion, the design model and design method
presented in this paper can model these three
dimensions.
6. CONCLUSIONS
This paper describes a design method and the
underlying design philosophy. The design
philosophy is based on the concept of statetransition systems: A design situation is defined
as a state; a design activity causes a state
transition; a design process is a sequence of state
transitions. The presented design method is
domain independent and aims at supporting
designers to reflect regularly on the design
situation. Forms support the designer in
describing the design situation at the beginning
and at the end of a design session. During a
design session, designers are free to transform the
state of the product and the design process in
arbitrary ways
Further research will concentrate on the
elaboration of the design philosophy and the
design method. The design model can be
extended with relations between the various
properties and factors. The intention of such an
extension is to support the designer in tracking
dependencies and asking what- if questions. The
design method can be provided with an additional
checklist for reflection. The goal of this checklist
is to ask relevant questions about the design
situation concerning the consistency between
properties and factors and the consistency
between the design tasks and the design goal.
A design tool is currently being developed to
facilitate the description of design situations and
to store the descriptions in a database. Attributes
supporting the configuration management of
properties and factors, like status and version of a
property and factor, are added to the existing set
of attributes. The tool offers possibilities to
execute queries on the different attributes and
relations in the description.
Last, but not least, all concepts have to be
validated and improved in practice. Junior
designers will test the design method and tool in
small projects. The validation will concentrate on
two questions: “Is the explicit description of a
design situation useful for reflection?” and “Are
the proposed moments for describing the situation
(beginning and end of a design session) useful?.”
Acknowledgements
We are very grateful to Kees van Overveld for his
contribution to describing design processes as a
series of state transitions. We are also indebted to
Thijs Bax, Peter Kroes, and Joan van Aken for
many fruitful discussions and remarks.
Especially, we want to thank Twan Basten for his
comments on the previous version of this paper.
References
Badke-Schaub, P., Frankenberger, E., Dörner,
D., (1997), “Analysing Design Work by Critical
Situations: Identifying Factors Influencing
Teamwork in Design Practice”, Proceedings of
the 11th International Conference on Engineering
Design, ed. by Riitahuhta, Vol. 2, Tampere,
Finland, pp. 381-386.
Badke-Schaub, P., Wallmeier, S., Dörner, D.,
(1999), “Training for designers: a way to reflect
design processes and cope with critical situations
in order to increase efficiency”, Proceedings of
the 12th International Conference on Engineering
Design, ed. by Lindeman et al., Vol. 1, München,
Germany, pp. 205-210.
Cross, N., (1994), “Engineering design
methods: strategies for product design”, Wiley,
Chichester (2nd ed.).
Dorst, K., (1997), “Describing Design: A
Comparison of Paradigms”, Ph.D. Thesis,
Vormgeving
Rotterdam,
Rotterdam,
The
Netherlands.
Dorst, K., (1999), “Two kinds of design, and
two sides of design”, Proceedings of the 12th
International Conference on Engineering Design,
ed. by Lindeman et al., Vol. 3,
pp. 1547-1552.
Evbuomwan, N., Sivaloganathan S., Jebb, A.,
(1996), “A survey of design philosophies, models,
methods and systems”, Proceedings of the
Institution of Mechanical Engineers, Vol. 210,
Part B: Journal of Engineering Manufacture,
London, UK, pp. 301-319.
Hales, C., (1991), “Analysis of the engineering
design process in an industrial context”, Ph. D.
Thesis, Eastleigh Grants Hill, UK.
Hubka, V., Eder, W.E., (1996), “Design
Science: Introduction to the Needs, Scope and
Organisation of Engineering Design Knowledge”,
Springer, Berlin, Germany.
Reymen, I.M.M.J., (1998), “Design in
Architecture,
Software
Engineering
and
Mechanical Engineering: A Comparative Study”,
Proceedings of the 4th Design Decision Support
Systems in Architecture and Urban Planning
Conference, Maastricht, The Netherlands, ISBN
90-6814-081-7 (CD-ROM).
Reymen,
I.M.M.J.,
(1999),
“DomainIndependent Description of Design Situations”,
Proceedings of the 12th International Conference
on Engineering Design, ed. by Lindeman et al.,
Vol. 2,
pp. 1215-1218.
Salustri, F.A., Venter, R.D., (1991), “Towards
a logical theory of engineering design
information”, Computers in Engineering, ASME,
Vol. 1, pp. 161-167.
Wester, F., (1991), “Strategieën voor
kwalitatief onderzoek”, Coutinho, Muiderberg,
The Netherlands (in Dutch).