ArticlePDF Available

A design method and computational architecture for generating and evolving building designs /

  • White Lioness Technologies

Abstract and Figures

"October 2004" Thesis (Ph.D.)--The Hong Kong Polytechnic University, 2005. Includes bibliographical references.
Content may be subject to copyright.
The aim of this thesis is to contribute to the development of a practical
evolutionary design approach — incorporating both design methods and
software systems — that would allow a design team to evolve designs
that they find surprising and challenging. This thesis has developed an
overall framework that supports such an evolutionary design approach.
Genetic and evolutionary algorithms and software systems attempt
to harness the power displayed by natural evolution. These algorithms
and systems have been successfully employed during the design process
in a number of different design fields. However, they have been limited to
tackling a very narrow range of well-defined engineering problems. Typ-
ically, the evolutionary system is used to optimise certain parameters
within a predefined parametric design. Due to a number of fundamental
problems, the evolutionary approach has had limited success in evolv-
ing the overall configuration and organization of complex designs. This
thesis investigates and proposes how these problems can be overcome for
building design.
The primary problem to be overcome is generating designs that in-
corporate an appropriate level of variability, which is referred to as the
variability problem. This affects both the performance of the evolutionary
system and predictability of the types of designs that are produced. In an
ideal system, performance is high and predictability is low. However, due
to the variability problem, this is difficult to achieve. If design variability
is very restricted, then performance may be high but predictability will
also be high. If design variability is very unrestricted, then predictability
may be low but performance will also be low. In order to evolve surpris-
ing and challenging designs, a system is required that both performs well
and evolves unpredictable designs.
The proposed generative evolutionary design framework allows the
design team to restrict design variability by specifying the character of
designs to be evolved. This approach is based on the notion of a design
entity that captures the essential and identifiable character of a family of
designs. This design entity is called a design schema. The design team
encodes the design schema as a set of rules and representations that can
be used by the evolutionary system. The system can then be used to
evolve designs that embody the encoded character.
The framework consists of two parts: a design method and a com-
putational architecture. The design method consists of two phases: a
generalization phase to develop and encode the design schema, and a
specialization phase to evolve a specific design by using the encoded
schema. In the first phase, the design team develops the schema with a
type of design project in mind. However, the specific project does not
yet need to be known. In the second phase, the schema is applied to
a specific project and designs are evolved and adapted to the context
and constraints of the project. One key advantage of this design method
is that the encoded design scheme can be re-applied to many different
Two key requirements for the design method are that it should be
conservative and synergetic. It should be conservative in that it should
only deviate from existing design methods and processes where absolutely
necessary. In practice, many designers follow a design process similar to
the schema based process - a personal architectural character is cultivated
during a lifetime of work and adapted for particular projects. This makes
it easier for design teams to adopt the proposed method. The second key
requirement is for a synergetic design method. It should be synergetic in
that the contrasting abilities of the design team and the computational
system should be exploited in a way that is mutually beneficial. The
design team focuses on the creative and subjective task of developing
and encoding the design schema, and the computational system is used
for the repetitive and objective task of evolving alternative design models.
The second part of the framework is the computational architecture.
This architecture specifies a system that can be used to run the evolution-
ary process. Its two key requirements are scalability and customizability.
The architecture should be scalable in that the performance of the evo-
lutionary system should not degrade unacceptably when used to evolve
large and complex designs. Scalability is achieved by using a parallel
computational model that reduces execution time, in combination with
a decentralised control structure that improves the robustness of the sys-
tem. The architecture should be customisable in that it should allow the
design team to change and replace the evolutionary rules and representa-
tions. Customizability is achieved by breaking the system down into two
parts: a generic core and a set of specialised components. The generic
core does not need any modification by the design team and can be re-
used within any project. The specialised components, on the other hand,
have to be specified by the design team. These components include a set
of routines that encapsulate the rules and representations that constitute
the encoded schema.
The feasibility of the proposed generative evolutionary design frame-
work is supported by a demonstration of the process of encoding the
design schema. A design schema is introduced that defines the character
of a family of design. A crucial aspect of encoding such a schema is the
creation of a set of rules and representations for generating alternative
design models with an appropriate level of variability. The demonstra-
tion focuses on these generative rules and representations. A generative
process is developed that can generate a variety of three-dimensional
models of buildings that differ in overall organization and configuration
but that share the schema character. This generative process is used to
define generative rules and representations that are implemented as a set
of Java programs. These programs are then used to generate a popula-
tion of three-dimensional models of building design, thereby allowing the
character and variability of the designs to be verified. The feasibility of
the encoding process is successfully demonstrated.
Publications and Conferences
Patrick Janssen, John Frazer and Ming-Xi Tang (2005). Generative Evo-
lutionary Design: A system for generating and evolving three-dimensional
building models. Submitted to The Third International Conference on
Innovation in Architecture, Engineering and Construction (AEC 2005).
Patrick Janssen, John Frazer and Ming-Xi Tang (2005). A design method
and computational architecture for generating and evolving building de-
signs. Submitted to The Tenth Conference on Computer Aided Architec-
tural Design Research in Asia, (CAADRIA 2005).
Patrick Janssen, John Frazer and Ming-Xi Tang. Evolutionary Design
Exploration Systems. In Proceedings of the World IT in Construction
Conference (INCITE2004), Langkawi, Malaysia, 18-21 February 2004,
pages 79–84.
John Frazer and Patrick Janssen (2003). Generative and Evolutionary
Models for Design. In Communication and Cognition: Organic Aesthet-
ics and Generative Methods in Architectural Design, 36(3 & 4):187–215.
Patrick Janssen, John Frazer and Ming-Xi Tang (2003). Evolution Aided
Architectural Design: An Internet based evolutionary design system. In
E-Activities in Design and Design Education - Proceedings of the 9th
EuropIA International Conference (EIA 2003), Istanbul Technical Uni-
versity, Turkey, 8–10 October 2003, pages 163–172.
Patrick Janssen, John Frazer and Ming-Xi Tang(2003). Evolution Aided
Architectural Design: A method of designing sustainable buildings. In
Sustainable Environment: Quality Urban Living - Proceedings of The
Third China Urban Housing Conference, The Chinese University of Hong
Kong, 3–5 July 2003, pages 425–432.
John Frazer, Xiyu Liu, Ming-Xi Tang and Patrick Janssen (2002). Gen-
erative and evolutionary techniques for building envelope design. In Pro-
ceedings of the 5th Generative Art Conference (GA2002), Politecnico di
Milano University, Italy, 11–13 December 2002, pages 3.1–3.15
Patrick Janssen, John Frazer and Ming-Xi Tang (2002). Evolutionary
Design Systems and Generative Processes. In The International Journal
of Artificial Intelligence, Neural Networks, and Complex Problem-Solving
Technologies, March/April 2002, 16(2):119–128.
Patrick Janssen, John Frazer and Ming-Xi Tang (2001). Generative and
Evolutionary Processes in Design. In On Growth and Form: The Engi-
neering of Nature, ACSA East Central Regional Conference, University
of Waterloo, Canada, October 5–7, 2001.
Patrick Janssen, John Frazer and Ming-Xi Tang (2001). Generating-
predicting soup: A conceptual framework for a design environment. In
Proceedings of the Sixth Conference on Computer Aided Architectural
Design Research in Asia, (CAADRIA 2001) University of Sydney, Aus-
tralia, 19–21 April 2001, pages 137–148.
Patrick Janssen, John Frazer and Ming-Xi Tang (2000). Evolutionary
Design Systems: A Conceptual Framework for the Creation of Genera-
tive Processes. In Proceedings of the 5th Design Decision Support Sys-
tems in Architecture and Urban Planning (DDSS 2000), Nijkerk, The
Netherlands, August 22–25, 2000, pages 190–200.
Cristiano Ceccato and Patrick Janssen (2000). GORBI: Autonomous
Intelligent Agents Using Distributed Object-Oriented Graphics. In Pro-
ceedings of the 18th Education and Research in Computer Aided Architec-
tural Design in Europe Conference (eCAADe 2000), Weimar, Germany,
22–24 June 2000, pages 297–300.
Patrick Janssen (1999). An Embryonic Growth Process for Spatial Mor-
phology. Masters Thesis, Department of Cognitive Science and Intelli-
gent Computing, Westminster University, London, UK.
Special thanks go to my supervisor, Professor John Frazer and my co-
supervisor Dr. Tang MingXi for their continuous encouragement, sup-
port, and guidance.
This Ph.D. was undertaken in the Design Technology Research Centre
(DTRC), School of Design, Hong Kong Polytechnic University. As such,
it was part of a more general DTRC research initiative. Generative and
evolutionary design was an active focus area, with a number of Ph.D.
projects being undertaken. I would especially like to thank two fellow
Ph.D. students, Chan Kwai Hung and Sun Jian, for their generous input.
The ideas developed in this Ph.D. first germinated in 1995 while I was
completing my Diploma in Architecture at the Architectural Association,
in John and Julia Frazer’s Diploma Unit 11. During this time, I worked
closely with Manit Rastogi. These ideas were also further developed while
working with Gianni Botsford on a number of commercial projects.
Finally, I would like to thank my wife, Jacqueline Elfick, for the stim-
ulating discussions throughout this research, and for her general support
and patience in my endeavour to undertake this project.
Certificate of Originality iii
Abstract v
Publications and Conferences vii
Acknowledgments ix
Contents xiv
List of Figures xvii
I Overview 1
1 Introduction 5
1.1 Overview of problem . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Overview of evolutionary design . . . . . . . . . . 5
1.1.2 Problem identification . . . . . . . . . . . . . . . 12
1.2 Overview of research . . . . . . . . . . . . . . . . . . . . 15
1.2.1 Research objectives . . . . . . . . . . . . . . . . . 15
1.2.2 Research proposition . . . . . . . . . . . . . . . . 17
1.2.3 Significance and potential benefits . . . . . . . . . 22
1.2.4 Research methodology . . . . . . . . . . . . . . . 25
1.3 Overview of thesis . . . . . . . . . . . . . . . . . . . . . . 30
II Review of related work 31
2 Design process 35
2.1 Introduction......................... 35
2.2 Designmethods....................... 36
2.2.1 Design methods movement . . . . . . . . . . . . . 36
2.2.2 Designing as a subjective process . . . . . . . . . 38
2.3 The role of the computer . . . . . . . . . . . . . . . . . . 40
2.3.1 The changing role of the computer . . . . . . . . 40
2.3.2 Computers as design support medium . . . . . . . 40
2.4 The role of the designer . . . . . . . . . . . . . . . . . . 42
2.4.1 Problems and solutions . . . . . . . . . . . . . . . 42
2.4.2 Personal and idiosyncratic input . . . . . . . . . . 44
2.4.3 Design preconceptions . . . . . . . . . . . . . . . 46
2.5 Designideas......................... 49
2.5.1 The dominance of initial design ideas . . . . . . . 49
2.5.2 Types of initial design ideas . . . . . . . . . . . . 51
2.6 Summary .......................... 53
3 Generative techniques 55
3.1 Introduction......................... 55
3.2 Parametric approach . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Overview ...................... 56
3.2.2 Variational based parametric technique . . . . . . 57
3.2.3 History based parametric technique . . . . . . . . 60
3.3 Combinatorial approach . . . . . . . . . . . . . . . . . . 62
3.3.1 Overview ...................... 62
3.3.2 Algebra based combinatorial technique . . . . . . 62
3.3.3 Template based combinatorial technique . . . . . 63
3.4 Substitution approach . . . . . . . . . . . . . . . . . . . 65
3.4.1 Overview ...................... 65
3.4.2 Grid based substitution technique . . . . . . . . . 67
3.4.3 Shape based substitution technique . . . . . . . . 70
3.4.4 Context-free versus context-sensitive substitution
approaches...................... 75
3.5 Summary .......................... 77
4 Evolutionary computation 79
4.1 Introduction......................... 79
4.2 General architecture . . . . . . . . . . . . . . . . . . . . 80
4.2.1 Synchronous architecture . . . . . . . . . . . . . . 80
4.2.2 Asynchronous architecture . . . . . . . . . . . . . 87
4.3 Synchronous evolutionary algorithms . . . . . . . . . . . 91
4.3.1 Canonical genetic algorithm . . . . . . . . . . . . 91
4.3.2 Other common synchronous algorithms . . . . . . 96
4.4 Rules and representations . . . . . . . . . . . . . . . . . 98
4.4.1 Genotype representation . . . . . . . . . . . . . . 99
4.4.2 Developmental step . . . . . . . . . . . . . . . . . 101
4.4.3 Reproduction, evaluation and selection rules . . . 105
4.5 Summary .......................... 110
5 Evolutionary design 111
5.1 Introduction......................... 111
5.2 GADO............................ 113
5.2.1 Overview ...................... 113
5.2.2 Demonstrations . . . . . . . . . . . . . . . . . . . 117
5.3 GS.............................. 118
5.3.1 Overview ...................... 118
5.3.2 Demonstrations . . . . . . . . . . . . . . . . . . . 120
5.4 GADES ........................... 122
5.4.1 Overview ...................... 122
5.4.2 Demonstrations . . . . . . . . . . . . . . . . . . . 125
5.5 Concept-seeding . . . . . . . . . . . . . . . . . . . . . . . 126
5.5.1 Overview ...................... 126
5.5.2 Demonstrations . . . . . . . . . . . . . . . . . . . 130
5.6 Epigenetic design . . . . . . . . . . . . . . . . . . . . . . 134
5.6.1 Overview ...................... 134
5.6.2 Demonstrations . . . . . . . . . . . . . . . . . . . 136
5.7 Summary .......................... 140
III Research proposition 143
6 Design method 147
6.1 Introduction......................... 147
6.2 Overview of method . . . . . . . . . . . . . . . . . . . . 148
6.2.1 Structure of method . . . . . . . . . . . . . . . . 148
6.2.2 Schema conception stage . . . . . . . . . . . . . . 150
6.2.3 Schema encoding stage . . . . . . . . . . . . . . . 155
6.3 Key requirements . . . . . . . . . . . . . . . . . . . . . . 162
6.3.1 A conservative method . . . . . . . . . . . . . . . 162
6.3.2 A synergetic method . . . . . . . . . . . . . . . . 165
6.4 Summary .......................... 168
7 Computational architecture 169
7.1 Introduction......................... 169
7.2 Key requirements . . . . . . . . . . . . . . . . . . . . . . 170
7.2.1 A scalable system . . . . . . . . . . . . . . . . . . 170
7.2.2 A customisable system . . . . . . . . . . . . . . . 174
7.3 Overview of architecture . . . . . . . . . . . . . . . . . . 179
7.3.1 Individuals . . . . . . . . . . . . . . . . . . . . . 179
7.3.2 Specialised components . . . . . . . . . . . . . . . 182
7.3.3 Generic core . . . . . . . . . . . . . . . . . . . . . 184
7.3.4 Interactions between components . . . . . . . . . 190
7.4 Implementation strategies . . . . . . . . . . . . . . . . . 193
7.4.1 Language and technologies for the generic core . . 193
7.4.2 Language and technologies for representing indi-
viduals........................ 195
7.4.3 Language and technologies for specialised compo-
nents......................... 197
7.5 Summary .......................... 200
8 Demonstration 201
8.1 Introduction......................... 201
8.2 Overview........................... 202
8.2.1 Schema conception stage . . . . . . . . . . . . . . 202
8.2.2 Schema encoding stage . . . . . . . . . . . . . . . 204
8.3 Developmental routine . . . . . . . . . . . . . . . . . . . 206
8.3.1 Overview ...................... 206
8.3.2 Generative steps . . . . . . . . . . . . . . . . . . 209
8.4 Implementation....................... 216
8.4.1 Overview ...................... 216
8.4.2 Other routines not implemented . . . . . . . . . . 218
8.4.3 Results........................ 220
8.5 Summary .......................... 222
IV Conclusions 225
9 Conclusions and future work 229
9.1 Contributions ........................ 229
9.1.1 Summary of objectives . . . . . . . . . . . . . . . 229
9.1.2 Variability problem . . . . . . . . . . . . . . . . . 230
9.1.3 Design method . . . . . . . . . . . . . . . . . . . 231
9.1.4 General architecture . . . . . . . . . . . . . . . . 234
9.1.5 Detailed architecture . . . . . . . . . . . . . . . . 236
9.1.6 Controlled variability . . . . . . . . . . . . . . . . 238
9.1.7 Summary of main contributions . . . . . . . . . . 238
9.2 Futurework......................... 239
9.2.1 Shortterm...................... 239
9.2.2 Longterm...................... 240
9.3 Conclusions ......................... 241
Glossary 243
Bibliography 245
List of Figures
1.1 General parametric evolutionary method. . . . . . . . . . 11
1.2 General generative evolutionary method. . . . . . . . . . 12
1.3 The schema-based evolutionary design method. . . . . . 19
1.4 Computational architecture for generative evolutionary de-
signsystem. ......................... 21
1.5 Systems development research process, proposed by Nuna-
maker et al. (1991). (Diagram is redrawn from (Nuna-
maker et al., 1991).) . . . . . . . . . . . . . . . . . . . . 29
2.1 The stages of the typical 1960’s design process. . . . . . 44
2.2 Broadbent’s adaptation of the typical 1960’s design process. 45
2.3 Broadbent’s design process modified to account for the
dominance of the designers preconceptions. . . . . . . . . 46
3.1 Main inputs and outputs for the parametric approach. . 57
3.2 Optimization of yacht hull using a genetic algorithm. From
Frazer (1995b, p. 61). . . . . . . . . . . . . . . . . . . . . 59
3.3 An example of a set of rules and the corresponding forms.
From Todd and Latham (1999). . . . . . . . . . . . . . . 60
3.4 Some examples of forms generated using the Xfrog software. 61
3.5 Main inputs and outputs for the combinatorial approach. 62
3.6 A house represented as a collection of four-inch cubes.
From Mitchell (1990, p. 41). . . . . . . . . . . . . . . . . 65
3.7 Main inputs and outputs for the substitution approach. . 66
3.8 Generative sequence by Thomas Quijano and Manit Ras-
togi. From Frazer (1995b, p. 92-93). . . . . . . . . . . . 69
3.9 Generative sequence by Stefan Seem¨uller. From Frazer
(1995b,p.46-47)....................... 70
3.10 Generation of the Koch curve. . . . . . . . . . . . . . . . 71
3.11 Three space-frame designs for an air plane hanger roof.
From Shea (1997, p. 122–124). . . . . . . . . . . . . . . . 73
4.1 General evolutionary architecture for algorithms using the
synchronous evolution mode. . . . . . . . . . . . . . . . . 81
4.2 The three representations of an individual in an evolution-
aryalgorithm......................... 81
4.3 Comparing the generational, elitist and the steady-state
evolutionmodes. ...................... 84
4.4 Synchronous global parallel architecture. . . . . . . . . . 86
4.5 General evolutionary architecture for algorithms using the
asynchronous evolution mode. . . . . . . . . . . . . . . . 90
4.6 Asynchronous global parallel architecture. . . . . . . . . 91
4.7 The representation of an individual, consisting of a binary
string genotype and a real valued fitness. . . . . . . . . . 94
5.1 Optimization of supersonic aircraft . . . . . . . . . . . . 116
5.2 Alternative facade solutions generated by GS for one block
of the School of Architecture in Oporto by ´
Alvaro Siza.
From (Caldas and Norford, 2001). . . . . . . . . . . . . . 121
5.3 Alternative building forms generated by GS. Top row is
viewed from the south west, and the bottom row is viewed
from the north-east. From (Caldas, 2001, p. 256). . . . . 122
5.4 Examples of clipped stretched cubes used in the spatial
partitioning representation in GADES. From (Bentley, 1996,
p.56) ............................ 124
5.5 Examples of sports car designs at different stages of evo-
lution. From (Bentley, 1996, p. 205) . . . . . . . . . . . 126
5.6 Examples of table designs. From (Bentley, 1996, p. 173) 127
5.7 The evolutionary concept-seeding design method. . . . . 129
5.8 The two basic structural units of the Reptile System. . . 130
5.9 Enclosures growing from two different seeds . . . . . . . 131
5.10 Plan of building generated from star seed . . . . . . . . . 131
5.11 Output from evolutionary system using the evolutionary
concept-seeding method. . . . . . . . . . . . . . . . . . . 132
5.12 The Interactivator: the process of cellular division and
multiplication......................... 138
5.13 The Interactivator: the materialization of left-over cellular
material............................ 139
6.1 The rules that encode the design schema. . . . . . . . . . 162
6.2 A design process used by some designers. . . . . . . . . . 164
7.1 General decentralised evolutionary architecture. . . . . . 173
7.2 Conceptual diagram showing the division between the generic
core and the specialised components. . . . . . . . . . . . 175
7.3 The main components of the proposed architecture. . . . 180
7.4 The structure of an individual in the population, and the
four states an individual may be in. . . . . . . . . . . . . 181
7.5 Sub-representations of a partially evaluated individual. . 182
7.6 Input and output of individuals for evolution routines. . 185
7.7 Flow diagram of the main actions performed by the evo-
lutionmodules. ....................... 186
7.8 Flow diagram showing the main loop for the population
module. ........................... 187
7.9 Flow diagram showing the response of the population mod-
ule to a get-request. . . . . . . . . . . . . . . . . . . . . . 188
7.10 Flow diagram showing the response of the population mod-
ule to a post-request. . . . . . . . . . . . . . . . . . . . . 190
7.11 Individual represented using a single tree structure with
various sub-trees. . . . . . . . . . . . . . . . . . . . . . . 196
8.1 A set of generated designs. . . . . . . . . . . . . . . . . . 203
8.2 The parts of the encoded schema that have been imple-
mented and demonstrated. . . . . . . . . . . . . . . . . . 205
8.3 The eight generative steps used to generate the design
models. ........................... 207
8.4 The transformation of the grid into a design. . . . . . . . 208
8.5 Terminology used to describe entities within the grid. . . 208
8.6 Eight generative steps. . . . . . . . . . . . . . . . . . . . 210
8.7 Positioning of the grid within the site boundary. . . . . . 211
8.8 Possible positions for the stairwell. . . . . . . . . . . . . 213
8.9 Interior elevation of four possible window types. . . . . . 215
8.10 Inputs and outputs for the initialization routine. . . . . . 218
8.11 Inputs and outputs for the developmental routine. . . . . 218
8.12 Inputs and outputs for the visualization routine. . . . . . 219
8.13 First design example. . . . . . . . . . . . . . . . . . . . . 221
8.14 Second design example. . . . . . . . . . . . . . . . . . . . 222
8.15 Third design example. . . . . . . . . . . . . . . . . . . . 223
Part I
Part one consists of an introduction chapter that gives an overview
of this thesis. First, the evolutionary design approach is introduced and
certain key problems are identified. The main research objectives are
then defined and an outline is given of the research proposition. Finally,
methodological issues are discussed.
Chapter 1
1.1 Overview of problem . . . . . . . . . . . . . . 5
1.1.1 Overview of evolutionary design . . . . . . . 5
1.1.2 Problem identification . . . . . . . . . . . . . 12
1.2 Overview of research . . . . . . . . . . . . . . 15
1.2.1 Research objectives . . . . . . . . . . . . . . . 15
1.2.2 Research proposition . . . . . . . . . . . . . . 17
1.2.3 Significance and potential benefits . . . . . . 22
1.2.4 Research methodology . . . . . . . . . . . . . 25
1.3 Overview of thesis . . . . . . . . . . . . . . . . 30
1.1 Overview of problem
1.1.1 Overview of evolutionary design
The evolutionary process in nature is an extraordinarily impressive de-
sign system. Natural designs far exceed human designs in terms of com-
plexity, performance and efficiency. Evolutionary design systems aim to
automate a part of the design process by using natural evolution as a
Rather than analyzing one or even several design alternatives, evolu-
tionary systems consider whole populations of alternatives. This parallel
approach of the evolutionary process has proved to be well suited to de-
sign processes that are typically divergent and exploratory. The field of
evolutionary design has benefited from a large amount of interest and
research (Frazer, 1995b; Bentley, 1999a; Bentley and Corne, 2002).
The aim behind creating such systems is not to duplicate or mimic
an existing conventional design process. Rather, the aim is to create an
alternative design approach that allows designers to work in ways that
were previously not possible (Frazer and Connor, 1979).
Evolution in nature
In nature, the behaviour of individual organisms results in the population
as a whole evolving and adapting to the environment. Each individual
organism exists simultaneously in two related forms: as a genotype and
as a phenotype. A genotype consists of a set of genes (the organisms
DNA), where a gene can be thought of as a piece of information that can
trigger a certain developmental process to unfold. The phenotype is the
fully developed organism.
The life-cycle of an organism may be broken down into three inter-
related and overlapping steps: reproduction,development and survival.
Together, these steps result in the continuous cyclical process of life
and death that drives the evolution and adaptation of the population
as whole. The three evolution steps may be described as follows:
The reproduction step involves creating new child genotypes from
existing parent genotypes. For example, in sexual reproduction new
genotypes may be created by crossover and mutation. Crossover
interchanges sections of the genes from the parents. Mutations
change particular genes as a result of copying errors during the
process of creating the new genotype.
The developmental step involves creating a complete organism —
the phenotype — from a new genotype. Under the appropriate en-
vironmental conditions, the genes in the genotype will trigger a set
of developmental processes, which will result in the gradual growth
of an organism. In some cases, this growth process takes place in a
highly controlled environment such as the mother’s womb. In other
cases, the growth process is exposed to the exterior environment,
such as a plant growing from a seed.
The survival step involves large populations of organisms competing
— either individually or in groups — for limited resources in the
environment. Organisms that are successful in this competition
for resources tend to survive longer, and those that survive longer
are likely to reproduce more often than organisms that die early.
As a result, their genes become more common in the population.
Survival is commonly characterised as a process of natural selection,
whereby the environment kills certain organisms, thereby ‘selecting’
the remaining organisms for reproduction.
For each individual organism, these steps occur more or less sequen-
tially: first an organism is conceived; then the organism grows from a
seed or egg into the fully developed organism; and finally, if it survives,
it may have a chance of reproducing.
Evolutionary algorithms
Universal Darwinism (Dawkins, 1983) suggests that the process of evo-
lution can emerge regardless of the medium, be it biological, compu-
tational, cognitive, or through some other form. Within the computa-
tional medium, evolutionary algorithms have been highly successful in a
many domains and for a wide variety of problem types. Mitchell (1999,
p. 15-16) lists optimization, automatic programming, machine learning,
economics, immune systems, ecology, population genetics, evolution and
learning, and social systems as domains where evolutionary algorithms
have been successfully applied. Beasley (2000) gives an overview of their
application in planning, design, simulation and identification, control and
Evolutionary algorithms are in some way analogous to the process
of natural evolution. Such algorithms create a cyclical process in which
a population of individuals is continuously manipulated to ensure that
the population gradually evolves and adapts as a whole. Each individual
in the population may represent a variety of entities, including a set of
parameters in an equation, a solution to a problem, or a design that
fulfils certain requirements.
These algorithms tend to include representations and steps that mir-
ror (in highly simplified form) their natural counterparts. The genotype
representation is a highly encoded version of the entity being evolved and
the phenotype representation is a decoded version of the genotype. The
reproduction step creates new genotypes; the development step trans-
forms genotypes into phenotypes; and the survival step allows some phe-
notypes to survive.
Each evolution step requires a set of rules and representations. The
representations specify a data-structure to be used to represent a par-
ticular aspect of an individual, such as the genotype or phenotype. The
rules specify how one representation may be transformed into another
representation. For example, the reproduction rules may specify how to
transform two parent genotypes into one child genotype, and develop-
mental rules may specify how to transform a genotype into a phenotype.
Evolutionary algorithm: An algorithm loosely based on the neo-
Darwinian model of evolution through natural selection. A popu-
lation of individuals is maintained and an iterative process applies
a number of evolution steps that create, transform, and delete in-
dividuals in the population. Individuals are rated for their effec-
tiveness, and on the basis of these evaluations, new individuals are
created using ‘genetic operators’ such as crossover and mutation.
The process is continued through a number of generations with
the aim of improving the population as a whole.
Evolutionary algorithms differ from natural evolution — and from
one another — in the type of evolution steps that they use. Evolution-
ary algorithms have an additional step: they use an evaluation process
to assess the performance of each individual in the population. In na-
ture, the process of evaluation is implicitly part of the survival step. The
evaluation of an organism remains positive as long as the organism does
not die. With evolutionary algorithms, evaluation must be performed ex-
plicitly. This evaluation must ascertain how well the individual performs
with respect to one or more objectives. For each objective, an evaluation
score is calculated and stored as part of the individual. Another addi-
tional step that is commonly used is the selection step. These steps will
be discussed in more detail in chapter 4.
Evolutionary algorithms differ significantly from the natural model in
numerous other ways. Two key differences are the evolution mode and
the control structure:
The evolution mode refers to how the evolution steps process in-
dividuals in the population. In nature, the evolution steps are ap-
plied in parallel. At any moment in time, some organisms may be
in the process of being born, others may be in the process of living,
and yet others may be in the process of dying. This natural evo-
lutionary process may be described as an asynchronous evolution
mode, in that the life-cycles of the individuals in the population are
not synchronised. Most evolutionary algorithms use a synchronous
evolution mode. In this case, individuals in the population are pro-
cesses in a synchronised manner, with each evolution step being
applied to the whole population in turn. The synchronous applica-
tion of all the evolution steps to the individuals in the population
is described as a generation.
The control structure refers to how the evolution steps are con-
trolled. In nature, the evolutionary process is an emergent phe-
nomenon that arises as a result of the behaviour of individual or-
ganisms. The evolution steps are applied locally and independently
from one another. This is referred to as a decentralised control
structure. Most evolutionary algorithms uses a centralised control
structure, whereby the application of the evolution steps to indi-
viduals in the population is centrally orchestrated.
Evolution mode: The way in which the evolution steps process indi-
viduals in the population. The two main evolution modes are the
synchronous mode and the asynchronous mode. With the syn-
chronous mode, the evolutionary process stops and waits for the
processing of all individuals by one evolution step to be completed
- before proceeding onto the next evolution step. With the asyn-
chronous evolution mode, evolution steps process individuals or
small groups in the population as soon as they become available.
Control structure: The way in which evolution steps are controlled.
Two main control structures are centralised control and the de-
centralised control. With centralised control, a cyclical process in-
vokes and applies evolution steps to individuals in the population.
With decentralised control, the evolution steps are autonomous
processes that manipulate individuals in the population.
A wide range of evolutionary algorithms exist that use a synchronised
evolution mode in combination with a centralised control structure. The
four main types are genetic algorithms (Holland, 1975; Goldberg, 1989;
Jong, 1993; Whitley, 1994), evolution strategies (Rechenberg, 1973; B¨ack,
1996), evolutionary programming (Fogel, 1963, 1995), and genetic pro-
gramming (Koza, 1992). Of these, genetic algorithms are the best known
and most widely used. These algorithms will be discussed in more detail
in chapter 4 (see section 4.3 on page 91).
Evolutionary design
In the design domain, evolutionary algorithms are used to create pop-
ulations of alternative designs (Frazer, 1995b; Bentley, 1999d,c, 2000b;
Bentley and Corne, 2002; Dasgupta and Michalewicz, 1997). The indi-
viduals being manipulated by the algorithm represent possible designs.
Each design has a genotype representation and a phenotype representa-
tion. The genotype representation encodes information that can be used
to create a model of the design, while the phenotype representation is the
actual design model. This design model may be evaluated with respect
to certain design objectives, which may require information about the
environment in which the design is to be implemented and used.
Evolutionary design: A design approach that relies on evolutionary
software systems to aid in the process of designing. Such a system
employs evolutionary algorithms to evolve whole populations of
design alternatives. The software may be used to evolve complete
designs or parts of designs.
Two types of evolutionary design may be broadly identified: paramet-
ric evolutionary design1and generative evolutionary design. Parametric
evolutionary design is usually used late in the design process and focuses
on the optimization of design solutions to well-defined design problems.
An existing design is defined and parts that require improvement are
parameterised2. The evolutionary system evolves the parameter values.
1Some researchers refer of parametric evolutionary design as evolutionary design
2A parameter is a value that is assigned to a variable.
Such systems are generally described as convergent search systems that
search the parameter space for an optimal or satisficing set of parame-
ter values. Examples of parametric evolutionary design include (Rasheed,
1998; Rasheed and Davison, 1999; Dasgupta and Michalewicz, 1997; Cal-
das, 2001, 2002).
Parametric evolutionary design: A design approach that uses an
evolutionary system to search for optimal or satisficing design so-
lutions to well defined design problems. The overall design is
predefined and those parts thought to require improvement are
parameterised. This results in a parametric model into which val-
ues for parameters can be inserted to create alternative design
solutions. The evolutionary system uses a set of fitness functions
or objective functions to evolve an optimal or satisficing set of
Generative evolutionary design, on the other hand, may be used early
on in the design process and focuses on the discovery of surprising or
challenging design alternatives for ill-defined design tasks. A generative
process is created that uses information in the genotype to generate al-
ternative design models. The evolutionary system will tend to evolve a
divergent set of alternative designs, with convergence on a single design
often being undesirable or even impossible. Such systems are sometimes
described as divergent systems or exploration systems. Examples of gen-
erative evolutionary design systems include (Frazer, 1990, 1992; Graham
et al., 1993; Frazer, 1995b,c; Frazer et al., 1995b; Bentley, 1996; Rosen-
man, 1996b,a; Baron et al., 1997, 1999; Coates et al., 1999; Frazer et al.,
2000; Funes and Pollack, 1999; Rosenman and Gero, 1999; Sun et al.,
1999; Rosenman, 2000; Sun, 2001; von Buelow, 2002; Jackson, 2002).
Generative evolutionary design: A design approach that uses an
evolutionary system to evolve surprising or challenging design al-
ternatives, for ill-defined design tasks that embody multiple and
conflicting objectives. Some kind of growth process is used to gen-
erate design alternatives that vary significantly from one another.
The system then relies on either human judgement or evaluation
algorithms to evolve a population of design alternatives.
With regard to the types of designs produced, the main difference
between these two approaches relates to the variability of designs. With
the parametric approach, design variability is low. Since the designs
are all based on the same parametric model, the designs will all have
the same overall organization and configuration. With the generative
approach, the variability in designs can potentially be much greater.
Figure 1.1: General parametric evolutionary method.
The difference in design variability is related to how the developmen-
tal step is implemented. With the parametric approach, the developmen-
tal step is fairly straightforward and is based on a parametric model of
the design. The parameters are encoded in the genotype and a design
model is produced by applying the parameter values to the parametric
model. This is generally referred to as a mapping process. In the case of
generative evolutionary design, the developmental step expands a com-
pact genotype into a complex phenotype using a non-linear generative
procedure. For example, the genotype may still contain a set of param-
eter values, but rather than being applied to a static model, they are
applied to a set of growth rules that that generate design models. This
type of process is referred to as a generative process.
For both approaches, a similar design method can be identified that
involves two main stages: codifying concepts and evolving designs. With
the parametric approach, the first stages involves codifying a set of map-
ping rules and a set of evaluation rules based upon the parametric model.
With the generative approach, the first stage involves codifying gener-
ative rules and evaluation rules based on a set of generative concepts.
For both the parametric and generative approaches, the second stage
involves evolving alternative designs using on these rules. In addition,
the evolutionary process may require information about the design envi-
ronment, which must be encoded in an appropriate format. In general,
this information is usually only used by the evaluation process. Some
researchers have also proposed that in the case of the generative evolu-
tionary design, the generative process may develop designs in response
to the environment. Figure 1.1 and figure 1.2 on the following page show
the main stages of the parametric and generative approaches.
Of these two approaches, the parametric approach is the more com-
mon and well developed. However, the generative approach is potentially
much more powerful. A number of experimental generative evolutionary
systems have been developed in several different design domains. This
research will focus on the generative evolutionary design approach.
Figure 1.2: General generative evolutionary method.
1.1.2 Problem identification
Architecture is a design domain where the application of evolutionary
design could be highly beneficial. In the past, the parametric approach
has been successfully used to fine-tune a single aspect of a design at a
detailed design stage. However, being able to evolve the overall design
of a building early on in the design process would result in a much wider
range of potential benefits. For this to be possible, the design models
being evolved would need to vary significantly from one another, and as
a result the generative approach would need to be used.
Primary problem
A number of experimental generative evolutionary design systems have
been developed and these systems have had some success. These systems
use a variety of generative techniques to produce designs, such as shape
grammars,L-systems, and cellular automata. These techniques will be
discussed in more detail in chapter 3.
Examples of generative evolutionary design systems include the fol-
Baron et al. (1997, 1999) have explored systems that evolve forms
consisting of aggregations of elementary particles, called voxels. A
grid of voxels is defined and the genotype then encodes that state
of each voxel in the grid.
Rosenman (1996b,a, 2000); Rosenman and Gero (1999) have devel-
oped a number of systems for evolving two-dimensional orthogonal
plans for buildings. Plans are generated using a set of shape gram-
mar growth rules that make small modifications to an existing plan.
The genotype encodes the selection and application of rules.
von Buelow (2002) have developed an evolutionary system for evolv-
ing structural trusses. The topology of the truss is defined by a
connectivity matrix, and the geometry is define by the positions
of the joints. The genotype encodes both the topology matrix and
the joint positions.
Shea (1997, 2001, 2004) has developed as system for optimising
space frame structures. (The system developed by Shea does not
actually use an evolutionary algorithm. Instead, an optimization
technique called simulated annealing is used.) The structures are
generated using a set of shape grammar growth rules that add,
replace and modify structural members.
Coates et al. (1999); Jackson (2002) have experimented with evo-
lutionary systems that use L-Systems to generate forms. The L-
System is used to generate both two-dimensional and three-dimensional
forms. The genotype encodes the rules used by the L-System.
Bentley (1996, 1999b) has developed an evolutionary system for
evolving solid object designs. Objects are represented as a set of
non-overlapping solid primitives. The genotype encodes the po-
sition and shape of these primitives. The system uses a set of
evaluation routines to evaluate designs.
Frazer (1992); Graham et al. (1993); Frazer (1995b,c); Frazer et al.
(1995b) have developed a variety of evolutionary systems that evolve
three-dimensional forms. Forms are generated using cellular au-
tomata rules. The genotype encodes the cellular automata rules.
Many of these systems are capable of generating complex forms that
vary in overall organization and configuration. However, none of these
system are capable of evolving three-dimensional forms that resemble
The fundamental problem with the forms generated by these systems
relates to design variability. The generative and evolutionary process is
not restricted and constrained in a way that ensures that building de-
signs are produced. So far, it has been emphasised that the variability
cannot be overly restricted. But, equally important is that variability
should not be completely unrestricted. When the output is highly unre-
stricted, the process of evaluating the models may become complex, or
even impossible.
The evaluation step must perform a relative assessment of the design
models in the population at any one time. This assumes that all de-
sign models can be meaningfully compared to one another. When the
variability of design models is highly unrestricted, three main problems
related to evaluation can be identified:
First, when variability is unrestricted, the majority of models gen-
erated will be chaotic forms that cannot be interpreted, either by
the designer or the computer, as a design 3. One option is for the
evolutionary system to identify the models that can be interpreted
as designs and to discard any chaotic models. This becomes a ma-
jor task in itself. In many cases, the proportion of actual designs in
the background noise of chaotic forms is so small that it becomes
impossible for the evolutionary process to take hold.
Second, the comparison of designs employing different architectural
concepts and languages requires subjective judgements to be made.
Whether one design is better than another becomes a matter of per-
sonal taste, and as a result such judgements cannot be performed
by the computer. One option is to allow the designer to interact
with the evolutionary system so that they may selectively ‘kill’ any
designs that do not reflect their personal design ideas and beliefs.
This will become an onerous task for the designer since only a small
proportion of the designs will reflect their ideas and beliefs.
Third, the analysis and simulation of designs that vary in unre-
stricted ways is problematic. Typically, analysis and simulation
programs require designs to be specified as complex representations
that use high-level semantic concepts to describe a design. For ex-
ample, representations typically include spaces, walls and floors or-
ganised in precise arrangements. Conversely, generative programs
that generate unrestricted variability describe designs using basic
low-level geometric primitives. The task of inferring high-level se-
mantic constructs from low-level geometric primitives is complex,
if not impossible.
Despite these problems, some researchers have actively pursued the
development of evolutionary systems capable of evolving designs that
vary in highly unrestricted ways. The main motivation behind this highly
generic approach is the desire to avoid restrictive processes that may ex-
clude the best designs. For example, concerning generative evolutionary
design systems, Bentley (1999b, p. 42) writes: “phenotype representa-
tions are typically quite general, capable of representing vast numbers of
alternative morphologies (this is in contrast to representations for opti-
mization, which can only define variations of a single form).” He later
states that this approach “overcomes potential limitations of ‘conven-
tional wisdom’ and ‘design fixation’ by evolving forms without the use
of knowledge of existing designs or design components.” Although this
argument cannot be ignored, the problems identified earlier in relation to
the evaluation step must also be considered. Developing a highly generic
3The distinction between forms that are designs, and those that are not — between
designs and chaotic forms — is not based on the quality of designs, but is instead a
much coarser distinction between those forms that may be understood to be a design
— whether good or bad — and those that, due to their random and chaotic nature,
simply defy any kind of understanding.
representation that does not exclude the best designs is of little use, if it
results in the evolutionary process being severely hindered.
The main problem is finding a compromise between an evolutionary
design system that is overly restrictive but performs well, and one that
is highly unrestricted but performs poorly. This problem is referred to
as the variability problem.
Other related problems
The variability problem suggest that the variability of designs should
be restricted in some way. This results in an evolutionary system that
is limited to evolving certain types of designs. This restriction leads
to a second, related problem, which has been called the style problem
(Bentley, 1999b). The style problem relates to the re-usability of the
system. In particular, when the variability of designs is restricted in
some way, this may result in all designs having a particular ‘style’, which
in turn will result in an evolutionary system with low re-usability since
only a small number of designers are likely to approve of the style.
If re-usability is low, each design team will be required to develop
their own evolutionary system that incorporates restrictions on design
variability that they approve of. This situation is clearly undesirable
because most design teams do not have the resources, including time
and expertise, to develop such systems. An approach must be found that
both maximises the re-usability of the evolutionary system and allows the
variability of designs to be restricted.
1.2 Overview of research
1.2.1 Research objectives
The overall goal of this research is to contribute to the development
of a practical generative evolutionary design approach that would allow
the design team to evolve the overall configuration and organization of
Primary research objective
In order to achieve the overall goal set out above, the primary objective
is to develop a framework for the application of the evolutionary de-
sign approach that allows the variability problem to be overcome. This
framework is referred to as the generative evolutionary design framework.
The framework consists of two parts: a design method and a compu-
tational architecture.
The design method broadly defines a design procedure for using
generative evolutionary design. One of the tasks defined by the
design method is the task of evolving alternative designs. (Other
tasks will be discussed below.)
The computational architecture specifies the structure and organi-
zation of the software and hardware components for a generative
evolutionary design system. Such a system would be used for the
task of evolving alternative designs.
Design method: A semi-formalised design process that explicitly pre-
scribes a way of designing a type of product. The process is struc-
tured as a set of tasks to be carried out by the designer or design
team, possibly in some specific order. A design method is a con-
jecture of a potentially useful design process. It is useful to the
extent that its application will lead to products that embody cer-
tain design qualities that are seen to be beneficial or desirable.
Computational architecture: An implementation plan of how sig-
nificant software and hardware components of a computer system
are structured and organised. This includes the functions and in-
teractions of different components. Communication protocols and
data formats may also be defined.
Other related objectives
In order for the generative evolutionary design framework to be effec-
tive, both the design method and the computational architecture need
to fulfil certain key requirements. The design method should fulfil two
The design method should be conservative in that it should, wher-
ever possible, conform to existing design processes used by designers
in practice. It should only deviate from existing design processes
when it is essential to the success of the evolutionary approach.
This conservative approach minimises the changes that are neces-
sary on the part of the design team, and thereby renders it more
The design method should be synergetic in that the contrasting
abilities of the design team and the computational system should
be exploited in a way that is mutually beneficial. Through corre-
lated action, the human designers and the computational system
should be able to achieve results that would otherwise not be pos-
sible if they were applied in isolation. Such a collaboration requires
a design method where the strengths and weaknesses of the human
designers complement the strengths and weaknesses of the compu-
tational system.
The computational architecture should also fulfil two requirements:
The architecture should be scalable, allowing for the evolution of
large complex designs without performance being adversely affected.
In most cases, the developmental and evaluation steps are likely to
be the most computationally demanding. In order to avoid these
steps becoming a bottleneck, some form of parallelization will need
to be considered.
The architecture should be customisable. Since generative evolu-
tionary design is a relatively new research field, researchers are
experimenting widely. Different researchers are likely to implement
the evolution steps in a number of different ways, and the architec-
ture should make the customization of the rules and representations
used by these steps as easy as possible.
1.2.2 Research proposition
The core concept upon which the generative evolutionary design frame-
work is based is the notion of a design entity that captures the essential
and identifiable character of a family of designs. This conceptualization
is defined as a design schema.
Design schema
The design schema focuses on a designers body of work, or their oeuvre.
An intrinsic aspect of a design schema is that it is specific to one designer
or design team. Related to this, is the idea that they embody a formative
potential. Design schemas are seen as synthetic rather than analytic and
may be used to generate a range of designs that all embody the character
of the schema. Designs that embody this character are described as being
members of the schema.
Design schema: A design conceptualization that captures the essen-
tial and identifiable character of a varied family of designs by
one designer or design team. It encompasses those characteristics
common to all members of the family, possibly including issues of
aesthetics, space, structure, materials and construction. Although
members of the family of designs share these characteristics, they
may differ considerably from one another in overall organization
and configuration. Design schemas are seen as formative design
generators; their intention is synthetic rather than analytic.
When a design schema is codified in a form that can be used by
an evolutionary system, it provides a way of overcoming the variability
problem. The encoded schema allows designs to be generated that differ
widely in overall organization and configuration while at the same time
precluding chaotic designs. The task of codifying the design schema in-
volves creating a set of rules and representations that define the evolution
steps. Each evolution step is characterised as a process that transforms
input data into output data. The rules define the transformations and
the representations define the formats for the input and output data.
Design environment and niche environment
The environment for a design is defined as encompassing both design con-
straints and design context. Examples of design constraints may include
the budget, the number of spaces, floor areas, performance targets and so
forth. The design context may include site dimensions, site orientation,
neighbouring structure, seasonal weather variations, and so forth.
Design environment: The constraints and context for a particular
design. The constraints describe the requirements that the build-
ing must fulfil and may include factors such as budget, spatial re-
quirements, and performance targets. The context describes the
building site and may include site conditions, neighbouring condi-
tions and weather conditions. The design environment covers all
those conditions that influence the success or failure of the design,
but that are not part of the design itself.
The design schema is not specific to one design. When a design
schema is created, the actual design environment may not yet be known.
However, the design schema cannot be created devoid of any reference to
the environment. Instead, the design schema may be developed with a
certain type of environment in mind, referred to as the niche environment.
Niche environment: A type or category of design environment, en-
compassing a range of possible constraints and a range of possible
contexts. If a specific design environment falls in such a environ-
mental niche set, this design environment is described as matching
or falling within the environmental niche.
The design schema concept therefore entails a distinction between
two different types of environment. The design schema is adapted to an
niche environment, whereas the design model is adapted to the design
The proposed design method
The design method is the first part of the framework. It breaks the
design process down into two sequential phases. In the first phase, a
design schema is developed that may be used to evolve designs for a
Figure 1.3: The schema-based evolutionary design method.
range of different projects. In the second phase, the schema developed
in the first phase is applied to a specific project and a detailed design
proposal is developed. Figure 1.3 shows the overall structure of the design
method. The first phase may be viewed as a generalization process, and
the second phase as a specialization process.
Each of the two phases is further broken down into two main stages:
In the schema development phase, the design team develops a new
design schema that may be used in a range of different projects.
The two main stages are creating the design schema and encoding
the design schema. The first stage is a form of conceptual design,
where the design team develops an integrated set of design ideas
adapted to a niche environment. The second stage involves codify-
ing the schema in a format that is compatible with the evolutionary
In the design development phase, the design team develops a de-
tailed design for a specific design project. The two main stages
are evolving a set of alternative design models and developing one
of the designs into a detailed proposal. The first stage requires a
generative evolutionary design system for which a computational
architecture has been developed. This system uses the encoded
schema to evolve and adapt designs in response to the encoded de-
sign environment. The second stage involves developing a detailed
design proposal as in a conventional design process.
The schema development phase creates a design schema that is man-
ually adapted to an environmental niche by design team, whereas the
design development phase creates a design proposal that is automatically
adapted to the design environment by the evolutionary system. The en-
coded schema can be used in any project whose design environment falls
in the niche environment for which the schema was designed.
The design method is conservative in that the overall structure of the
design method is similar to a conventional design process commonly used
by designers in practice. Numerous studies have shown that designers
do not come to a design project with an empty mind but have a set of
strongly held preconceptions — including general philosophical beliefs,
cultural values, and specific design ideas — that they repeatedly apply in
different design projects. Such a design process is seen to share significant
similarities with the proposed design method.
The design method is synergetic in that it specifies a process where
the design team can focus on those tasks that are predominantly creative
and subjective, and where the computational system can be applied to
those tasks that are predominantly repetitive and objective. Developing
and encoding the design schema is seen as a creative and subjective task,
while generating and evaluating alternative designs is seen as primarily
a repetitive and objective task.
The proposed computational architecture
The computational architecture is the second part of the framework. The
architecture provides an implementation plan for a generative evolution-
ary design system. Such a system is required in the design evolution
stage of the proposed method discussed above. The system uses a set of
rules and representations that constitute the encoded schema.
Figure 1.4 on the facing page shows the most significant components
of the computational architecture. A single population is manipulated by
seven steps: an initialization and a termination step, four evolution steps
and a visualization step. The initialization and termination steps are used
to initialise and terminate the evolutionary process. The four evolution
steps consist of reproduction step, a development, an evaluation step and
a survival step. Each of these steps extracts a small number of individuals
from the population, processes these individuals, and either inserts the
resulting individuals back into the population or — in the case of the
survival step — deletes a number of individuals in the population. The
visualization step allows design models in the population to be visualised.
The architecture specifies a parallel implementation using a standard
client-server model in a networked computing environment. The server
manages the population of designs and performs the reproduction and
Figure 1.4: Computational architecture for generative evolutionary de-
sign system.
survival steps, while multiple client computers perform the developmental
and evaluation steps. The architecture supports scalability in two ways:
First, an asynchronous parallel evolutionary process is used that re-
duces the execution time and is highly effective in situations where
the development and evaluation steps are costly. This is especially
pertinent for evaluation clients, since the simulation or analysis of
the performance of a building design can be time consuming.
Second, a decentralised control structure is used with a client-server
model that results in a flexible and robust architecture. The archi-
tecture is flexible in that client computers can easily be added and
removed from the evolutionary process. The architecture is robust
in that it can cope with failure of client systems in a graceful man-
In order to support a high level of customizability, the architecture
breaks down the evolutionary system into two main parts: the generic
core and a set of specialised components. The generic core can be re-used
in any design project and does not require any modification. In order
to function, the generic core must invoke the services of the specialised
components. These components are completely customisable and must
be defined by the design team. Three types of specialised components
may be defined by the design team: routines,data-files and applications.
Routines encapsulate the rules and representations used by the evo-
lutionary system. The design team must create a set of such rou-
tines that together constitute the encoded schema. The encoded
schema can be changed without requiring any changes to be made
to the generic core.
Data-files encapsulate information about the design environment.
These data-files constitute the encoded environment. The data-files
can be changed and replaced independently of both the generic core
and the routines that define the encoded schema.
Applications are existing software applications whose functionality
the design team may require, in particular for modelling, visualis-
ing and evaluating design models. The architecture supports the
integration of such applications in the evolutionary system. The
networked client-server models allows these applications to be exe-
cuted by clients running any operating system, as required by the
1.2.3 Significance and potential benefits
The schema based evolutionary design approach has a number of poten-
tial benefits over existing design processes. Three potential benefits are
highlighted: the first focuses on the ability to evolve designs for buildings
that consume less energy; the second focuses on encouraging experimen-
tation and innovation in the design process; the third focuses on allowing
the client to gain more control over the design process.
Low-energy architecture
Sustainability has recently become an important issue in many domains,
including building design. Sustainable development ensures that the
needs of the present are met without compromising the ability of fu-
ture generations to meet their own needs (WCED, 1990, p. 8). In or-
der to make development in a particular environment (either Earth as a
whole or some region of it) sustainable, the impact of humans on that
environment must be kept in certain limits (sometimes described as the
‘carrying capacity’ of that environment). The environmental impact can
be described by the following formula (Sylvan and Bennett, 1994, p. 47):
Environmental Impact = Population ×Consumption ×Technology
To reduce the environmental impact, the size of the human population
must be reduced, the consumption per member of the population must
be reduced, or improvements in technology must be made that reduce
the impact of consumption.
For the designers of buildings, one of the main ways of reducing the
environmental impact is by reducing the consumption element in the for-
mula. In particular, building designers can design buildings that are well
adapted to their environment, thereby reducing the energy consumed in
their operation and maintenance. This has been highlighted by Maver
and Petric (2003), who write: “Central to the concept of sustainability,
at least in the climatic region of northern Europe, is the issue of en-
ergy consumption. Leaving aside the energy embodied in the production
and transportation of the materials for building, the energy expended in
maintaining the building stock at acceptable levels of thermal comfort
accounts for more than half of the total energy budget.”
Maver and Petric (2003) then asks: “Better design; but how?” This
question highlights the fact that adapting a design of a building to its
environment is not straightforward. The ability of the human designer to
foresee the future consequences of the numerous and interrelated design
decisions made during the design process is limited, particularly when
considering design decisions made early on in the design process. The
complexity of the design task is typically so great that the designer will
need to rely on the rule of thumb and their gut feeling when it comes
to making early design decisions. The consequences of these decisions
will only become clear later in the design process when it is likely to
already be too late to explore alternative avenues. Even if further time
and resources are available, only a small number of alternatives could
ever be feasibly explored.
The schema based design approach uses an evolutionary system rather
than human designer to explore these different alternatives. Such a sys-
tem is inherently parallel in its mode of operation and is able to explore
large numbers of possible alternative designs. The evolutionary process
will ensure that the population of design models will gradually adapt
to the design environment in which they are being generated and evalu-
ated. (This approach has been explored by Caldas (2001); Caldas et al.
(2003); Caldas and Norford (2004) for parametric evolutionary design.)
By creating designs that are appropriately adapted to the environment,
the schema based design approach may help to reduce the consumption
per member of the population.
Experimentation and innovation
The design of a building is generally a one-off endeavour. Due to this one
off nature of building design, the costs of any project-specific experimen-
tation and innovation must all be borne by a single client. Frazer (1995b)
writes: “Construction remains labour-intensive: it has never made the
transition to a capital intensive industry with adequate research and de-
velopment capabilities. It has been left largely to individual architects to
take the risk of performing experimental and innovative prototyping in an
uncoordinated and romantic or heroic manner. The ensuing (inevitable)
failures have been catastrophic for both society and the architectural
The schema based design approach provides an alternative focal point
for experimentation and innovation that is not project specific. The
design schema can be developed over a large number of projects. The
costs of any experimentation and innovation expended on developing
the design schema may be shared between multiple projects. This is
particularly relevant to design schemas that predefine a particular type of
structural and constructional approach, including defining specific types
of components and types of materials. In such cases, experimentation
and innovation may involve building and testing numerous prototypes
that explore these structural and constructional possibilities.
This approach to experimentation and innovation is similar to the
approach of mass-customization of consumer products. Mass customiza-
tion allows “the same large number of customers can be reached as in
mass markets of the industrial economy, and simultaneously they can
be treated individually as in the customised markets of pre-industrial
economies” (Davis, 1987, p. 169).
Client role
From a client perspective, the design process may sometimes be perceived
as somewhat opaque and mysterious. The schema design approach may
provide a model of client interaction that empowers the client to ex-
periment with the trade-off’s that commonly emerge when developing a
This client interaction model focuses on the second phase the de-
sign development phase. This phase consists of model evolution and
detailed design. During model evolution, the client guidance would cen-
tre on complementing the largely quantitative predictions performed by
the evolutionary system with qualitative human judgements. During
detailed design, the client guidance might centre on making choices con-
cerning details and materials to be used, taking into account the cost
An important aspect of this guidance is that it may require little
professional and technical knowledge. The design team together with
the technical software consultants would develop the design schemas,
the standard details and configure the applications. The client could
choose (or purchase) a design schema from their favourite designer and
develop a design proposal with limited assistance from the design team.
For example, as is common when purchasing a new car, the client might
select from a predefined list the preferred types of accessories and interior
finishes to be applied to the skeletal model (with cost implications being
display back to the client).
During the 1970’s, the ABACUS unit at Strathclyde University fol-
lowed a similar approach, where programs were developed that allowed
the end users to create their own designs. In one experiment, teachers
were able to use specially developed software to create designs for nurs-
ery schools that were within budget and performed well at a technical
level (Aish, 1977). Frazer et al. (1980); Frazer (1982, 1995b) has also
developed a number of tangible interface system that allow prospective
building users to explore different design solutions.
Lawson (1997, p. 292) summarises this approach as “using the com-
puter to de-skill parts of the process to the point where it could be
conducted by non-experts. This illustrates one of the generic possibil-
ities offered to us by computer systems. They can sometimes be used
to reduce the expertise needed to carry out the task to the level of the
novice. In this case the skills needed to draw out a design were reduced to
assembling simple shapes on a computer screen allowing nursery school
teachers to produce designs which could be compared with those pro-
duced by experienced and skilled architects.”
1.2.4 Research methodology
In both the natural and cultural sciences, methodological pluralism4has
led to the development of a vast variety of research methods. The ma-
jority of these can be described as descriptive research methods in that
they focus on describing the way the world is. This research is concerned
with contributing to the development of an evolutionary design approach
that does not yet exist. This research is inherently prescriptive and as a
result, research methods must be used that support this approach.
Many attempts have been made to develop prescriptive research meth-
ods5. Such research methods are common in design, engineering (Simon,
1981; Cross, 1993; Warfield, 1994; Cross, 2000) and computer science.
All these disciplines are predominantly prescriptive. However, for this
research, the methods developed in these disciplines are seen to be of
limited value, either because they do not directly address the issues in-
volved developing a computational system or because they tend to focus
only on the technical implementation aspects of the computational sys-
A research area with more appropriate types of research methods is
the relatively new field of Information Systems 6. Despite the fact that
design systems might fall outside what is commonly understood to be
an Information System, many of the research methods developed in this
field are in fact suitable to this investigation.
Research frameworks
Information Systems researchers have proposed a number of research
frameworks that include both descriptive and prescriptive research meth-
ods (Iivari, 1987; Nunamaker and Chen, 1990; Nunamaker et al., 1991;
4Methodological pluralism is the belief that there is not one correct research
method, but that there are many different methods for different purposes. (Mor-
gan, 1980; Polkinghorne, 1983; Hirschheim, 1985).
5Prescriptive research methods are described by a variety of terms including sys-
tems development,artefact building, and engineering type research.
6A common definition of the aim of Information Systems research is “the effective
design, delivery, use and impact of information technologies in organizations and
society” (Keen, 1987). The field is also known by a number of other names such as
Management Information Systems,Information Management and Informatics. These
names are largely synonymous; see (Davis, 2000)
Iivari, 1991; March and Smith, 1995; J¨arvinen, 1996; Iivari et al., 1998;
arvinen, 1999, 2000).
Typically, such research frameworks describes a long term research
activity that will encompass a variety of individual research projects,
each focusing on a particular type of research. Such frameworks identify
specific research methods that are applicable during different stages of
research, some of which are prescriptive and some of which are descrip-
The frameworks differ in how the break down the research activity.
Generally they will include three key stages (in some cases broken down
into smaller stages): conceptualization,implementation and evaluation.
The conceptualization stage includes the development of user meth-
ods, theoretical models and system architectures. Generally, this
stage does not encompass implementation although some experi-
ments and simulations may be performed to verify and demonstrate
the feasibility of the system. (For example, see experimentation, as
defined in Nunamaker et al. (1991).)
The implementation stage includes both the development of proto-
type ‘proof-of-concept’ systems as well as the development of fully
articulated production systems aimed at the target users. Based on
the architecture developed in the previous stage, a detailed specifi-
cation for the implementation of the system will need to be devel-
The evaluation stages includes performance testing, case studies,
field studies, and so forth. If the system being evaluated is a pro-
duction system, a realistic evaluation in the social and organiza-
tional context for which it was designed may be carried out.
A research project will tend to focus on one stage of the research and
will use the methods appropriate to that stage. The evaluation stage
tends to use descriptive research methods, whereas the first two stages
— conceptualization and implementation — typically rely on prescriptive
research methods.
Individual research projects are assumed to link together in complex
ways, thereby resulting in the long term research activity that covers the
various research stages. The outcome of some projects may require a
return to some earlier stage, while in other cases the output may become
the foundations for research in the next stage.
For example, one project may develop and implement a particular
prototype. If unexpected difficulties and constraints are encountered
during implementation, the next research project may need to return to
the conceptualization stage to modify the methods, models and architec-
tures. On the other hand if the implementation project was successful,
the next project may attempt to test and evaluate this prototype ac-
cording to a set of benchmarks and criteria. Nunamaker et al. (1991)
write that “development is an evolutionary process. Experiences gained
from developing the system usually lead to further development of the
system, or even the discovery of a new theory to explain newly observed
Only projects that focus on the latter stages are able to realistically
evaluate a system. The output from individual projects at earlier stages
in the research activity need to be judged in some other way. Various
researchers have argued (March and Smith, 1995; J¨arvinen, 1999, 2000)
that the output from any project — including those focusing on the
development and implementation stages — should be judged based on
its value or utility to a community of users. They suggest that this
measure of usefulness should take into account the existing context and
environment in which the output is being put to use. An output that is
original in some way, is deemed to be research, provided that it has a use
that is seen to be of some importance. The research contribution lies in
the novelty of the output and in the persuasiveness of the claims that it
is effective. Actual performance evaluation is not required at this stage.
Systems development research process
Nunamaker et al. (1991) see systems development as a research strategy
that fits comfortably into the category of applied science, belonging to
the engineering, developmental and formulative types of research. The
development of a method or system is viewed as “a perfectly acceptable
piece of evidence (an artefact) in support of a ‘proof’, where proof is taken
to be any convincing argument in support of a worthwhile hypothesis.
System development could be thought of as a ‘proof-by-demonstration’.”
They describe a general research process through which a particular
concept will progress. This overall process may encompass a number of
individual research projects. Nunamaker et al. (1991) write that “a con-
cept with wide-ranging applicability will go through a research life-cycle
of the form: concept - development - impact.” Imagination and creativity
in the concept stage leads to experimental design and implementation re-
search in the developmental stage, which may eventually lead to research
into user productivity and acceptance in the impact stage.
The research process consists of five key research stages:
The construction of a conceptual framework. Researchers should
justify the significance of the research question pursued. An ideal
research problem is one that is new, creative, and important in
the field. If the framework proposes new methods, techniques or
designs, researchers may elect to develop a demonstration that val-
idates the proposed methods, techniques or designs.
The development of a system architecture. Researchers should
put the system components into perspective, specify the system
functionalities, and define the structural relationship and dynamic
interactions among system components. The system architecture
provides a roadmap for the system building process.
The analysis and design of the system. Researchers should consider
and evaluate alternative approaches to implementation. A detailed
specification to be used as a blueprint for the implementation of
the system needs to be developed. Such a blueprint would need to
determine data-structures, databases and knowledge bases must be
The building of the (prototype) system. Researchers should demon-
strate the feasibility of the design and the usability of the func-
tionalities by implementing a system. The prototype may also be
further developed into a product that can be transferred into an
organization. The building process can provide insights that may
be helpful in redesigning the system.
The observation and evaluation of the system. Researchers should
test the performance and usability of the system, as well as observe
its impact on individuals, groups and organizations. The test re-
sults should be interpreted and evaluated based on the conceptual
framework and the requirements of the system defined in earlier
Figure 1.5 on the next page shows the overall process. A particular
research project is likely to focus on one stage, with the output from one
research project providing the foundations for the next one.
Scope of this research project
This research project focuses on the first three stages of the research
process defined by Nunamaker et al. (1991). For the first stage, a design
method is developed; for the second stage, a general system architecture
is developed; and for the third stage a detailed system architecture is
developed. The stages involving the implementation and evaluation of
the system are not included in this research.
The long term goal is to develop a user-friendly system with a compre-
hensive interface targeted at designers and architects. In order to achieve
this goal, the core evolutionary engine must first be implemented, tested
and evaluated. Such a process would no doubt result in a variety of
modifications and improvements to the core system.
The main outputs developed by this research are as follows:
The design method for evolutionary design. This method provides
a design procedure for the design team to use the evolutionary
The computational architecture for an evolutionary design system.
This architecture provides a plan for researchers to implement the
evolutionary system.
Figure 1.5: Systems development research process, proposed by Nuna-
maker et al. (1991). (Diagram is redrawn from (Nunamaker et al., 1991).)
Both the design method and the architecture are based on a number
of previous models, methods and systems. By comparative analysis, this
research highlights various aspects that are novel. In order to judge the
value or utility of these novel aspects, different users need to be consid-
ered. The eventual target users of an evolutionary system are a design
team that includes people with advanced computational skills. The de-
sign method is directed at these users. The computational architecture
is not directed towards designers, but towards fellow researchers and ex-
perimenters in the field of design computation, especially the field of
generative design.
The design method and the architecture should be judged based on
their value to their respective communities of users. In both cases, this
value is supported by a demonstration created to verify the feasibility of
design schema concept. This concept is seen as the core concept upon
which both the design method and the computational architecture are
For the demonstration, an example of a design schema is first de-
scribed. This design schema defines a family of building designs that
share the same overall character. A generative process capable of pro-
ducing designs that embody this character is described. The process of
encoding the design schema using routines, data-files and applications is
described. Three of the routines — the initialization, developmental and
visualization routines — are implemented and a variety of designs are
In addition to the demonstration, various arguments are made in
this thesis to support the design method and the computational archi-
tecture. The key requirements identified earlier also emphasise value
and utility. For the computational architecture, the requirement for cus-
tomizability ensures that researchers are able to experiment with a wide
variety of evolutionary rules and representations, and the scalability re-
quirement ensures that researchers will be able to evolve large complex
building forms. For the design method, the conservative requirement re-
lates to minimising the changes the design team need to instigate, while
synergetic requirement relates to harmonising the working relationship
between the design team and the computational system.
Finally, three broad potential benefits of the evolutionary design ap-
proach have been identified: increased levels of adaptation to the environ-
ment; increased levels of experimentation and innovation; and increased
levels of client participation in the design process. These potential ben-
efits further emphasise the value of the overall approach.
1.3 Overview of thesis
This thesis is divided into four parts. Part one consists of this introduc-
Part two reviews work related to this research, and consists of four
chapters: chapter 2 gives an overview of research into the design process;
chapter 3 gives an overview of various generative techniques; chapter 4
gives an overview of evolutionary computation; and, chapter 5 describes
a number of evolutionary design systems.
Part three presents the main proposition made by this thesis, and
consists of three chapters: chapter 6 describes the evolutionary design
method developed in this research; chapter 7 describes the computational
architecture developed in this thesis; and, chapter 8 demonstrates the
process of encoding a design schema.
Part four presents conclusions and future work.
Part II
Review of related work
Part two consists of four chapters that discuss the main areas of
research upon which the generative evolutionary design framework is
Chapter 2 discusses the design process, and in particular methods
and theories related to this process. The importance and necessity
of design preconceptions in the design process are emphasised.
Chapter 3 introduces a variety of techniques to generate three di-
mensional form. These techniques may be used to create the rules
and representations required by the developmental step.
Chapter 4 reviews the field of evolutionary computation. The ma-
terial covered is not specific to the design domain. Two compu-
tational architectures are identified, and the most common algo-
rithms are discussed. The rules and representations used by these
algorithms are described.
Chapter 5 describes a number of evolutionary design systems. Five
different systems are discussed, of which two are parametric and
three are generative.
Chapter 2
Design process
2.1 Introduction . . . . . . . . . . . . . . . . . . . 35
2.2 Design methods . . . . . . . . . . . . . . . . . 36
2.2.1 Design methods movement . . . . . . . . . . 36
2.2.2 Designing as a subjective process . . . . . . . 38
2.3 The role of the computer . . . . . . . . . . . . 40
2.3.1 The changing role of the computer . . . . . . 40
2.3.2 Computers as design support medium . . . . 40
2.4 The role of the designer . . . . . . . . . . . . 42
2.4.1 Problems and solutions . . . . . . . . . . . . 42
2.4.2 Personal and idiosyncratic input . . . . . . . 44
2.4.3 Design preconceptions . . . . . . . . . . . . . 46
2.5 Design ideas . . . . . . . . . . . . . . . . . . . . 49
2.5.1 The dominance of initial design ideas . . . . . 49
2.5.2 Types of initial design ideas . . . . . . . . . . 51
2.6 Summary . . . . . . . . . . . . . . . . . . . . . 53
2.1 Introduction
This chapter introduces a variety of design methods and theories. It
consists of four main sections:
In section 2.2, design methods are introduced. The overall ap-
proach and goal of creating such methods is discussed. Although
the design methods of the 1960’s aimed to provide a single ratio-
nal and objective procedure for designing, later methods allow for
subjectivity and ambiguity.
In section 2.3, the role of the computer in the design process is dis-
cussed. Since the 1960’s, computers have gradually become more
prominent, but they have also become more subservient to the tra-
ditional design process. Recently, a number of researchers have
suggested that the computer is once again being used to support
more unconventional design processes.
In section 2.4, the role of the designer in the design process is dis-
cussed. Research that emphasises the subjective and ambiguous
nature of design is discussed. In order to tackle any moderately
complex design task, the designer must introduce personalised and
idiosyncratic preconceptions. Two types of preconceptions are dis-
cussed: a general design stance and more specific design ideas.
In section 2.5, research relating to how preconceived design ideas
are used in the design process is discussed. A number of different
theoretical frameworks are introduced.
2.2 Design methods
The process of designing has been described as an “imaginative jump
from present facts to future possibilities” (Page, 1966, quoted in Jones
(1970)). Throughout history, design methods have been invented with
the intention of rationalising and formalising this jump.
2.2.1 Design methods movement
Designing has often been characterised as a problem solving endeavour
where the problem consists of a list of constraints and requirements and
the solution fulfils these requirements. This approach culminated in the
design methods movement.
The term ‘design method’ is perhaps most closely associated with
attempts, after World War II and during the 1960s, to create a design
science (Cross, 2001). In particular, the design methods movement hoped
to create design methods that were based on science, technology and
rationalism. The design methods movement received much attention
from the design research community. It was part of a more general quest
to develop a design science.
Cross (2001) writes: “The concern to develop a design science thus led
to attempts to formulate the design method — a coherent, rationalised
method, as the ‘scientific method’ was supposed to be... So we might
conclude that design science refers to an explicitly organised, rational,
and wholly systematic approach to design; not just the utilization of
scientific knowledge of artefacts, but design in some sense as a scientific
activity in itself.” The quest for a design science was a major motivation
in defining design as a problem solving endeavour. In this sense, the quest
for a design science may be thought of as being the broad framework
which subsumes the design methods movement.
By framing design as a problem-solving enterprise, it became natu-
ral to talk of problem definitions, sub-problems, parameters, variables,
optimal solutions, and so forth. The two key proponents of the design
methods movement were Christopher Alexander and John Christopher
First generation design methods
In the 1980 conference entitled Design : Science : Method, Broadbent
(1981) describes the design method developed by Alexander:
“Christopher Alexander... had developed a Design Method
which consisted of breaking the problem down into small
components, sorting these by computer into those which in-
teracted with each other and ‘solving’ the problems of each
group by drawing a diagram, a piece of design geometry by
which the conflicts were resolved between the components in
each group.
Initially, the ‘bits’ were ‘Misfit Variables’ - small statements
concerning the problem... He had had further thoughts by
1967 about the nature of the diagrams by which small plan-
ning ‘conflicts’ in the building could be resolved, such dia-
grams were now called The Atoms of Environmental Struc-
The ‘Atoms’ could be drawn because they resolved simple
conflicts of, say, people’s ‘tendencies’ to walk into a building
from a certain direction. These, for Alexander, were matters
of ‘fact’, which had nothing to do with feeling or opinion.
The designer’s task was to ‘resolve’ any ‘conflicts’ in such
‘tendencies’ by his ‘Atoms’ of geometry” (references omitted).
These early methods, developed during the 1960’s, were criticised for
being “mechanistic, over-simplistic, joyless, or as denying the essentially
creative nature of design” (Jacques, 1981), and soon became discred-
ited. By the early 1970s both Alexander and Jones had abandoned the
methods that they had pioneered a decade earlier. Broadbent (1981)
identifies the 1967 Symposium on Design Methods in Architecture as the
key turning point, with the symposium being organised to include spe-
cific confrontation between those “representing a mechanistic, quantified
view of design” and those “concerned, above all, with the ‘human-ness’
of human beings”.
Second generation design methods
As a result of these criticisms, a second generation (Rittel, 1973) of meth-
ods emerged that differed from the earlier methods in two important re-
spects: first, the idea of optimal design solutions was rejected in favour of
the notion of satisficing design solutions (introduced by Simon (1981));
and second, the idea of the omnipotent designer was rejected in favour of
the notion of user participation. Cross (1993) writes: “The first genera-
tion (of the 1960s) was based on the application of systematic, rational,
‘scientific’ methods. The second generation (of the early 1970s) moved
from attempts to optimise and from the omnipotence of the designer
(especially for ‘wicked problems’), towards recognition of satisfactory or
appropriate solution-types... and an ‘argumentative’, participatory pro-
cess in which designers are partners with the problem ‘owners’ (clients,
customers, users, the community).”
Despite the shift in approach, the second generation methods still
framed design as a problem solving endeavour and remained in the broader
design science framework. Although the approach had become less sim-
plistic and deterministic, designing nevertheless remained a question of
discovering a satisficing solution to the design problem using rational
means. Whereas first generation methods supposed that the omnipotent
architect was best placed to make such discoveries, the second generation
methods proposed the community as better placed to make such discov-
eries. Broadbent (1981) writes: “No one was to be an ‘expert designer’.
Designers had made a mess of things, and if they were to exist in the fu-
ture, they should be mere technicians, converting to physical form what
the community said it wanted.”
As a result many of the second generation methods were similar to
their first generation counterparts. For example, Alexander became dis-
illusioned with the computer (Alexander, 1971) — seeing the precision
required by the computer as being incompatible with creativity — and
subsequently modified his method to exclude the computer. The modi-
fied method was called A Pattern Language (Alexander et al., 1977), the
core of which consisted of 253 rules, called Patterns. Alexander defines a
Pattern as a “three-part rule, which expresses a relation between a cer-
tain context, a problem, and a solution” (Alexander et al., 1979). The
designer — who might actually be the client or the user rather than the
architect — would apply the Patterns to the design problem in a struc-
tured way to build up a new design solution. Broadbent (1981) described
Alexander’s modified method (Alexander et al., 1977, 1979) as follows:
“Having been transmuted once into ‘Atoms’ his ‘Misfit Variables’ then
became ‘Patterns’ of specific problems. Then they became parts of A
Pattern Language (1977)... Each Pattern consists of a general statement
— very like one of the old Misfit Variables — supported by photographs
and text. Most Patterns are summarised in the form of a diagram, very
like one of the old Atoms.”
2.2.2 Designing as a subjective process
Much of the research into design methods during the 1960s hoped to
create a design process that would somehow exclude all forms of subjec-
tivity, thereby disallowing any personal creativity and intuition. The idea
was that if the analysis of the ‘problem’ was sufficiently thorough, the
‘solution’ would emerge directly from the analysis. Furthermore, a objec-
tive procedure was sought that prescribed exactly how such a thorough
analysis might be performed.
In the 1970s, subjectivity was once again readmitted into the design
process. However, it was the users rather than the designers who were to
have a subjective input, and once again with this input ‘optimal’ designs
were to be created. Broadbent (1988) and Lawson (1972) have outlined
these developments and highlighted a series of fundamental flaws and
In the 1980s, the rationalistic approach to design was almost com-
pletely rejected, with many designers instead focusing on symbolic form.
Jonas (1997) describes this as a kind of liberation: “They presented
themselves as sort of egocentric artists, which in fact was also a step
of liberation and emancipation from the burden of the great but un-
achievable aims and claims (to work for a better society) in the era of
Inherent in the changing attitudes towards design methods over the
decades was a split between the rational techniques and more intuitive
techniques. Jones (1974) writes: “They all wanted a complete recipe...
Many people wanted this and perhaps all students wanted it all the time.
But I feel one should resist any such thing if one’s to continue living...
I found a great split had developed between intuition and rationality,
Today, notions of creating ‘optimal’ designs are no longer realistic.
In Design in Architecture, Broadbent (1988, p. 463-464) writes “Gone
are the days when architects believed that, given sufficient analysis, they
could design the perfectly ‘functional’ building. They could never, in any
case because... there really is no such thing.” Throughout his book, he
emphasises that it is a mistake to try and establish a once-and-for-all
sequence which, when applied, would lead automatically to ‘optimum’
Design methods are therefore understood to describe a much broader
category of methods, and may include methods that do not assume that a
rational approach to design is preferable. Some methods use random and
accidental techniques to generate new designs, with some designers even
resorting to ‘random drawings’ (Cross, 1999). For example, McLachlan
and Coyne (2001) discusses the role of accident in the design process, and
describes a design method used by Coop Himmelblau: “Himmelb(l)au
developed plan forms from a metamorphosed image of their own faces,
drawn over and over until the eyes became spaces in the city, and the
stripes on their shirts became lines of solid mass that gradually evolved
into built forms.” This is not to say that the methods developed by the
design methods movement are excluded, but rather that these methods
are seen as just one of many types.
2.3 The role of the computer
2.3.1 The changing role of the computer
The use of computers in design has a short history; their use was first
seriously considered in the 1960’s, with the design methods movement.
During these early days, researchers has ambitious hopes for the role of
the computer might play in design. Computer programs were envisaged
that aimed to support design approaches that were new and challeng-
ing. Since then, computers have gradually become more prominent in
all aspects of life, including design. However, when the mechanistic ap-
proach to design became discredited, the computer also seems to have
been rejected. Like Alexander, many felt that computers were somehow
incompatible with creativity and humanity (Alexander, 1971). In de-
scribing Alexander’s new state of mind, Broadbent (1981) writes: “The
application of any method, particularly and computer methods, required
a precision of approach which simply destroyed the frame of mind from
which creative design could emerge. The act of designing required a
tranquillity which simply could not be achieved with the computer.”
Although computers have played an increasingly prominent role in
design, the nature of this role has changed. Whereas early computer
systems supported new ways of working, later systems were totally sub-
servient to the conventional design process. These new systems focused
on reimplementing manual tasks in digital form, with minimal disruption
to the design process as it existed. The computer no longer had a role in
the creative design process and was relegated to the support of manual
chores. A typical example is a drafting software that simply recreates
the drawing board methodology on a computer.
Recently, the role of the computer in the design process has once again
become ambitious. Today, a whole variety of tools and applications exist
to support design techniques that would have been inconceivable without
2.3.2 Computers as design support medium
Schmitt (1999) discusses the future of computer-aided design, and writes:
“Drafting is not the main purpose of computers in architec-
ture any more. The computer is constantly changing its role
and appearance, and becoming faster and more powerful in
supporting designers every year. It was once useful to com-
pare the computer to an electronic pencil or to a sophisti-
cated typewriter. At the end of the twentieth century, this
view would be a dangerous misrepresentation of the machine,
as it has moved into new areas of support. It can act as a
medium, and is in some cases, already a partner.”(Schmitt,
Schmitt (1999) discusses two distinct roles for the computer: the com-
puter as a mere tool (Frazer, 1991) and the computer as a design support
medium. The computer as a mere tool must “prove itself in eliminat-
ing previously human activities with less cost and higher quality.” The
computer as a design support medium “is an interactive counterpart, not
necessarily an intelligent being, but something that has knowledge and
capabilities to offer in the area that we are interested in.” Whereas the
computer as a mere tool tends to emulate existing office instruments,
the computer as a design support medium “simulates new design instru-
ments, unthinkable without the computer. These instruments can turn
into self-generating and self-referential systems.”
As examples of computers as mere tools, Schmitt lists “word proces-
sors, when seen as replacing typists; spreadsheets, when seen as replacing
calculators; CAD programs, when seen as replacing electronic pencils;
office automation systems, when seen as a collection of desktop activi-
ties; rendering programs, when only seen as a way to impress clients.”
For computers as a medium, Schmitt discusses a number of recent tech-
nologies under the following headings: ‘The Internet as an information
source for architects’, ‘Data Bases - Building Memories’, ‘Drawing and
Modelling’, ‘Simulation’, ‘Virtual reality’, ‘CSCW: a new kind of team
work’, ‘The Virtual Design Studio (VDS): Multiplying Time’, ‘Engineer-
ing Data Management Systems (EDMS)’ and ‘Facility Management’. In
each case, the use of these technologies in the design process is discussed.
Schmitt is highly critical of the role of computers as mere tools in
the design process. He argues that to design highly complex artefacts
with computer programs that simulate an electronic pencil makes little
sense. Instead, he urges designers to make the best use of the powerful
communication and simulation technologies that are now available. He
“If architects want to keep and to improve their role in the
building process in the future, they need to employ the com-
puter more effectively. This could include its use as a design
support medium that assists designers in areas where they
do not have sufficient knowledge or competence themselves.
The most obvious application for the computer as a medium is
interactive simulation. More advanced applications are com-
puter supported methods and agents.” (Schmitt, 1999)
Paradigms of computer-aided design
The idea of a machine as a partner is also proposed by Mitchell (1994).
Mitchell (1994) has identified three different paradigms, which he de-
scribes as designing as problem-solving,designing as knowledge-based ac-
tivity, and designing as social activity.
Designing as problem-solving: This paradigm first emerged in the
1960’s with Herbert Simon’s book. The problem is formulated by
specifying a domain of possible solutions, a test which can be ap-
plied to distinguish acceptable candidate solutions for unacceptable
ones, and the resources available for solving the problem. The prob-
lem is solved by searching for solutions. Many narrowly specialised
design sub-problems can be solved in this way. One practical ap-
proach is to divide the labour between the human and the com-
puter, which has led to the typical CAD systems and the use of the
computer as a ‘mere tool’.
Designing as a knowledge-based activity: This paradigm emerged
in the 1980’s. A suitable formalism for the expression of design
knowledge was first required, which was used to create knowledge
bases that captured what successful designers knew. These knowl-
edge bases were used to solve design problems by applying auto-
mated reasoning procedures to the facts of the specific design situ-
ation combined with the facts and rules contained in these knowl-
edge bases. One approach for expressing design knowledge was to
use predicate logic. Another was to develop shape grammars (see
next chapter) that captured knowledge about how various physical
components could be combined. Mitchell highlights that the fun-
damental weakness of such systems is that the knowledge base can
never be complete and accurate. (See (Coyne et al., 1990).)
Designing as a social activity: This is a more recent paradigm.
There are multiple agents, some are human and some are soft-
ware programs. Each agent has its own (not necessarily consistent,
comparable, or compatible) knowledge base and problem-solving
capabilities, and interacts over the network. These agents pro-
ceed by exchanging proposals, arguments and counter-proposals
and counter-arguments, and they seek to form consensus. They
import knowledge into the common pool, they construct some com-
mon intellectual ground, and they sometimes change each other’s
minds. There are conflicts, ambiguities, and misunderstandings
that they must resolve. Key requirements are efficient networks
and communication infrastructures.
Mitchell sees the last paradigm as the future of computer-aided de-
sign. In this paradigm, the computer is seen as a networked medium
consisting of a variety of software agents that can automate labourious
or difficult tasks.
2.4 The role of the designer
2.4.1 Problems and solutions
Today, the ‘design problem’ is widely regarded as ill-defined. (See, for
example, Cross (1999) in which the views of a large number of ‘expert
designers’ are discussed.) An ill-defined problem is one in which the re-
quirements do not provide sufficient information to enable a solution to be
found. Such problems require additional information to be discovered,
created and invented. Design problems, like most everyday problems,
tend to be ill-defined in an extreme way in that the additional informa-
tion is far greater that the information contained in the stated require-
ments. The process of discovering, creating and inventing the additional
information is an essential part of the design process. Archer (1979)
writes: “Some of the necessary further information may be discoverable
simply by searching for it, some may be generatable by experiment, some
may turn out to be statistically variable, some may be vague or unre-
liable, some may arise from capricious fortune or transitory preference
and some may be actually unknowable. In addition, once known, some
of the requirements may turn out to be incompatible with one another.”
In 1967 Churchman (1967) related how Professor Horst Rittel pro-
posed that a class of ill formulated complex social systems problems that
involved many decision makers, and whose ramifications were thoroughly
confusing, might be referred to as wicked problems. Design problems
have since also become known as a wicked problems (Lawson, 1994, p. 2)
. Churchman writes “The adjective ‘wicked’ is supposed to describe the
mischievous and even evil quality of these problems, where proposed ‘so-
lutions’ often turn out to be worse than the symptoms.” The wickedness
of the problem relates to the fact that the problem includes the task of
discovering, creating and inventing the additional information.
Archer (1979) describes the relationship between problem and solu-
tion as follows: “The first thing to realise is that ‘the problem’ in a design
problem, like any other ill-defined problem, is not that statement of re-
quirements. Nor is ‘the solution’ the means ultimately arrived at to meet
those requirements. ‘The problem’ is obscurity about the requirements,
the practicability of envisagable provisions and/or misfit between the
requirements and provisions. ‘The solution’ is a requirement/provision
match that contains an acceptably small amount of residual misfit and
Some theorists have altogether rejected the idea design is about prob-
lem solving . For example, Glanville (1998) writes: “Other aspects (e.g.
solving a stated problem), although often understood as crucial, are not,
I maintain, central to the study of the design act, no matter how im-
portant. Problem solving is its own discipline. I am happy to leave it
to those interested.” In a footnote he adds: “Some postulate primitive
problem solving as a first venture towards design. History is as much a
construction as any other account. I do not deny problem- solving and
design coincide. But I insist design takes a space of its own.”
Figure 2.1: The stages of the typical 1960’s design process.
2.4.2 Personal and idiosyncratic input
The typical 1960’s design process
The typical 1960’s design process consisted of five core stages: briefing,
analysis, synthesis, evaluation, and implementation. Figure 2.1 show
this typical process. Analysis, synthesis, and evaluation were the three
core stages that related directly to the process of designing and were
generally assumed to be applied multiple times at different scales. For
example, Jones (1970, p. 63-69) uses this typical structure1to discuss the
design process. Jones writes: “These can be described in simple words
as ‘breaking the problem into pieces’, ‘putting the pieces together in a
new way’, and ‘testing to discover the consequences of putting the new
arrangement into practice”’.
Jones acknowledges that the synthesis stage cannot rely purely on the
analysis stage. Jones writes: “This is the stage when judgements and
values, as well as technicalities, are combined in decisions that reflect
the political, economic and operational realities of the design situation.
Out of all this comes the general character, or pattern, of what is being
designed, a pattern that is perceived as appropriate but cannot be proved
to be right” (Jones, 1970, p. 66).
The reference to ‘judgements and values’ suggests that some addi-
tional kind of input is required from the designer. But it is not clear what
kind of input this might be. The methods discussed by Jones indicate
that this input focuses primarily on redefining the problem. However, in
areas such as architecture, the input from the designer will be much more
dramatic and substantial. Most designers will impose a complex set of
personal beliefs, values and ideas onto the designs that they create.
1Jones (1970, p. 63-69) refers to analysis, synthesis and evaluation as divergence,
transformation, and convergence.
Figure 2.2: Broadbent’s adaptation of the typical 1960’s design process.
A modified design process
Broadbent (1988, p. 463-466) has developed a design model that includes
such inputs as preconceptions. Broadbent writes: “The presumption
behind much theorising of the ’60s was that somehow the Process would
generate the form. But it rarely happened like that for the obvious
reason that most architects approach most of their designing with certain
preconceptions concerning, not just the partie of the building type in
question but also, specifically, the style.”
He modifies the typical 1960’s design process and inserts ‘precon-
ception’ as an extra input (at right angles to the flow) into ‘synthesis’.
Broadbent writes: “Different architects, according to their ‘paradigmatic’
stance, will, given the same brief and even the same analysis come up
with quite a different syntheses: Modern, Post-Modern or whatever...
In other words whatever kind of analysis has been brought to bear that
architect, conditioned by the ‘paradigm’ in which he works, will bring
in sideways to the Process the kind of design he wanted to do anyway!”
Figure 2.2 shows Broadbent’s modified diagram.
The modified diagram would seem to be a more accurate depiction
of the design process in fields such as architecture. Nevertheless, Broad-
bent’s description of this process would suggest that the preconceptions
are actually more important than any analysis. In such a case, the pre-
conceptions would be the starting point for any design process, and these
preconceptions would be adapted to fit the design task, with the design
analysis coming in ‘sideways’.
This dominance of the preconceptions of the designer is confirmed
when a the work of most designer is analysed. In nearly all cases, the
same set of beliefs and values may be identified in all the designs, with
some designers repeatedly exploring the same specific design ideas. For
example, in an interview, Frank Gehry describes his design process as
Figure 2.3: Broadbent’s design process modified to account for the dom-
inance of the designers preconceptions.
“I was not conscious that it (the Bilbao Guggenheim) had
something to do with what I did before until later because
you know, I’m just looking at what I see. I tend to live in
the present, and what I see is what I do. And what I do
is react. Then I realise that I did it before. I think it is
like that because you can’t escape your own language. How
many things can you really invent in your lifetime. You bring
to the table certain things. What’s exciting, you tweak them
based on the context and the people: Kerns, Juan Ignacio,
the Basques, their desire to use culture, to bring the city to
the river” (Bruggen, 1997, p. 33).
In order to account for the dominance of the preconceptions, the
typical 1960’s design process may be further modified. Figure 2.3 shows
the modified process.
2.4.3 Design preconceptions
When considering the nature of design preconceptions, two types of pre-
conceptions can be identified: a general design stance and a specific set
of design ideas.
The design stance encompasses the broad beliefs and values that a
designer holds. Designer may have the same design stance through-
out their lifetime.
The design ideas are related to the design stance, but are much
more specific to particular types of projects and environments.
Design stance
Broadbent (1988, p. 463-466) describes general types of preconceptions
as the designer’s paradigmatic stance. Such a stance may have been
developed over a number of decades and may encompass broad philo-
sophical beliefs, cultural values and perhaps some whimsical tendencies.
A client’s decision to employ a particular design team is likely to based
— at least in part — on the paradigmatic design stance of the design
team in question.
Lawson describes this design stance as a set of guiding principles.
“The designer does not approach each design problem
afresh with a tabula rasa, or a blank mind, as is implied
by a considerable amount of the literature on design meth-
ods. Rather, designers have their own motivations, reasons
for wanting to design, sets of beliefs, values, and attitudes.
In particular, designers usually develop quite strong sets of
views about the way design in their field should be practiced.
This intellectual baggage is brought by the designer into each
project, sometimes consciously and at other times rather less
so... Whether they represent a collection of disjointed ideas, a
coherent philosophy or even a complete theory of design, these
ideas can be seen as a set of ‘guiding principles’.” (Lawson,
1997, p. 162)
Lawson describes how these guiding principles may differ in content
from one designer to the next, and also how they are used in different
ways. In terms of content, Lawson lists six types of constraints that play
an important part in defining the guiding principles of a designer: client
constraints, user constraints, practical constraints, radical constraints,
formal constraints and symbolic constraints. The attitude of the designer
towards these constraints, may to a large extent define their guiding prin-
ciples. For example, classical architects such as Vitruvius, Renaissance
architects such as Palladio and Alberti, and modernist architects such as
Le Corbusier all developed a strong set of formal constraints, defined as
a set of geometric and proportional rules.
Rowe (1987) has developed a similar concept, that he refers to as a
designers theoretical position. The theoretical position consists of a set of
general arguments and principles that may be either explicit or implicit.
In some cases, the theoretical position is well defined, in other cases it is
more implicit and vague. Most theoretical positions in some way attempt
to address the question: “What is proper architecture?”.
Rowe creates an analytical framework to describe and compare dif-
ferent types of theoretical position. The framework frames a theoretical
position as a three stage argument that progresses from general state-
ments to specific types of architecture. The three stages are labelled
as orientation,architectural devices, and production. These stages are
described as follows:
Orientation covers the critical stance and larger purpose of the
Architectural devices refers to architectonic elements and leitmotifs
(for example, Le Corbusier’s five points) that describe the position’s
Production describe a family of buildings identified by some label
(‘brutalist’, for example).
According to Rowe, a theoretical position can be characterised as an
argument that first sets out a broad orientation, this orientation will
support certain architectural devices, and these devices will in turn lead
to certain types of architectural production.
Rowe discusses a number of examples of theoretical positions. For
example, he describes the functionalist position as follows (Rowe, 1987,
p. 124). The orientation envisages architecture as a matter of efficiently
accommodating the requirements in a manner consistent with material
composition and construction. “Architecture must be made of the ‘right
stuff’ and in the ‘right way’ without superfluous ornament or artifice”.
Under architectural devices, three devices are highlighted: the explicit
expression of a building structure and process of fabrication, a spatial
organization that grows directly from the program of uses, and a concern
with standardization and systematic organization. The production is
epitomised by the International Style “with its ubiquitous array of steel,
concrete and glass commercial buildings, each consistent in basic format,
regardless of location and resulting differences in cultural setting.”
Design style
For a particular designer, the design stance is not thought of as a choice,
in the sense that they may choose one stance or another. Rather, the
stance is inherent in the way that they operate, and often constitutes a
set of strongly held beliefs. The term style may not be appropriate to
describe design stance. Style refers to a recognisable set of features of
designs created during a particular historical period, whereas the design
stance is a set of principles particular to one designer.
Lawson (1997, p. 163-166) highlights the fact that, although most
architects have a clear design stance, rarely do they describe themselves
as working in a particular style. Lawson writes: “Many architects today
regard the style of architecture more as inventions of the critics than as
sets of rules that they themselves follow.”
In extreme cases, the design stance may become a moral stance, with
the designer claiming their principles to be a set of universal truths,
often related in some way to proportions and harmonies found in nature
(Watkin, 1977).
2.5 Design ideas
2.5.1 The dominance of initial design ideas
As well as the overall design stance, designers will generally tackle a
particular design task with certain design ideas. These ideas will be
compatible with their design stance, but will be much more specific to
the design task being considered. They reflect the design stance combined
with a ‘gut feeling’ inspiration on how to approach the design task.
Primary generators
Drake (1979) conducted a series of interviews with British architects
about their intentions when designing local authority housing. Through
these interviews, Drake highlights how many architects (but not neces-
sarily all architects) latch onto a relatively simple set of related concepts
and ideas early on in the design process. Drake refers to this concept as
aprimary generator.
Concerning such primary generators, Drake emphasises three key
They are developed early on in the design process, prior to a de-
tailed analysis of the design problem.
They are not created by a process of reasoning, but are instead an
“article of faith on the part of the architect”.
They provide a framework that defines and directs the overall de-
sign approach. In particular, the primary generators structure the
problem definition, rather than visa versa.
Drake concludes that early on in the design process, designers “fix on a
particular objective, or small group of objectives, usually strongly valued
and self imposed, for reasons that rest on their subjective judgement
rather than being reached by a process of logic”.
Lawson (1997, p. 188) describes a series of protocol studies2of de-
sign exercises supporting the conclusions reached by Drake (see Eastman
(1970) and Agabani (1980)). Lawson (1997, p. 194) also emphasises
the importance of these design ideas in the overall design process. In
addition, Lawson stresses that the number of primary generators may
be small. Lawson (1997, p. 194) writes: “Good design often seems to
have only a few major dominating ideas which structure the scheme and
around which the minor considerations are organised. Sometimes they
can be reduced to only one main idea known to designers by many names
but most often called the ‘concept’ or the ‘parti’ ”.
2Protocol studies attempt to understand the personal cognitive design process by
studying designers in the act of designing.
Enabling prejudices
Further evidence supporting the idea of the primary generator has also
been collected by Rowe, using protocol studies and analysis of written
sources. Three case studies of designers in action were analysed, and an
attempt was made to reconstruct the sequence of steps, moves and other
procedures used. In addition, further examples of the design process,
taken from various written sources, were also analysed.
One of the key characteristics to emerge was the dominance of initial
design ideas on the rest of the design process. Rowe (1987, p. 31)
writes: “Initial design ideas appropriated from outside the immediate
context of a specific problem are often highly influential in the making of
design proposals. Quite often references are made to objects already in
the domain of architecture. On other occasions, however, an analogy is
made with objects and organizational concepts that are further afield and
outside architecture”. Rowe refers to these initial ideas and references as
enabling prejudices.
Based on the case studies and written sources, Rowe emphasises two
key points about such enabling prejudices:
They are more important than the problem conditions and tend to
be the driving force behind the whole design process.
In many cases, they are not discarded at the end of a project,
but instead become long-lasting themes explored through multiple
The first point regarding the dominance of these design ideas is simi-
lar to the conclusions reached by Drake and Lawson. Rowe (1987, p. 32)
highlights “the tenacity with which designers will cling to major design
ideas and themes in the face of insurmountable odds. Often the concept
the designer has in mind can only come to fruition if a large number
of apparently countervailing conditions can be surmounted”. One of the
many examples that Rowe discusses is the account by Richard Rogers (as
presented in Suckle (1980)) of the tension between the central design idea
and the technical requirements for the Centre Pompidou in Paris. The
central idea of an ‘inside-out building’ constructed from a prefabricated
kit of parts resulted in a wide range of problems requiring the develop-
ment of unorthodox methods of design, fabrication and construction.
To illustrate the second point, Rowe discusses the design ideas of
John Johanson (once again, from Suckle (1980)). Johanson develops an
analogy between architecture and electronic circuitry, with the circuits
chassis representing the structural frame, the circuit components repre-
senting the functional enclosures, and the circuiting system representing
channels for the circulation of people and mechanical systems. Johanson
explores and applies this analogy in a number of projects. Thus, Rowe
(1987, p. 31) writes: “Sometimes these analogies serve a designer’s pur-
pose for more than a single project and thus become incorporated as a
central part of that individual’s design thinking”.
Design ideas as working methods
Frazer (1974); Frazer and Connor (1979); Frazer (2002) describe a general
design methodology common to many design fields that develop design
ideas through multiple projects.
Frazer conceptualises the design ideas as being embedded in the work-
ing methods of designers, and that it is these methods that “characterise
their ‘style’ ”. Furthermore, Frazer highlights how aspects of these meth-
ods are explicitly defined in many offices as standard details, templates,
procedures, and so forth. He describes this methodology as both per-
sonal because it is particular to one designer, and generic because this
designer will use it in multiple projects. Frazer writes:
“It is common to find sets of standard details in archi-
tects’ offices that serve to economise in time, ensure details
are well tested, but also to ensure a consistency of detailing
and to reinforce the house style. In many offices this extends
to design procedures, approaches to organization and so forth.
The same is true of industrial designers where again stylis-
tic characteristics such as details, colour, preferred materi-
als give economy, consistency, quality control and identifiable
house style... The identifying characteristics often go through
changes during the development of the designers, sometimes
with abrupt changes as with Le Corbusier, but usually a con-
tinuous progression can be seen. The stylistic characteristics
can continue with an office, studio or company, long after the
death of the original designer.”
Frazer makes two important points about design ideas:
They are developed on a long-term basis through multiple projects.
They are embedded in the practical working methods used by de-
signers, encompassing procedures, tools and data.
2.5.2 Types of initial design ideas
The design ideas of a particular designer must be compatible with their
overall design stance. However, beyond this requirement, the develop-
ment of design ideas may be based on a variety of factors. Rowe (1987)
and Lawson (1997) have both developed frameworks that define a num-
ber of different types of design idea. Rowe’s framework conceptualises
design ideas as a type of design heuristic, while Lawson’s framework sees
design ideas as resolving specific design constraints.
Design ideas as design heuristics
Rowe conceptualises these design ideas in the form of heuristics that will
frame problem formulation and guide the search for design solutions.
Rowe (1987, p. 76) defines the term ‘heuristic’ broadly, highlighting that
“the heuristics employed by designers may be quite subjective, having
evolved from prior personal experience”.
Rowe presents five classes of heuristics:
Anthropomorphic analogies rely on physical actions of the human
body (such as moving, sitting, standing, and so on) as a driving
Literal analogies rely on existing form-giving configurations (which
includes both iconic and canonic analogies, as defined by Broadbent
Broadbent (1988)) as a driving force.
Environmental relations relies on the concept of appropriate re-
lations between the environment and the building (including cur-
rently significant issues of sustainability).
Typologies rely on past solutions at a variety of scales (including
complete building types, organizational templates, and prototype
for parts of buildings) as a driving force.
Formal languages are generalizations of other design ideas — in
particular typologies and environmental relations — that consist of
guiding structures or rules that manipulate formal design elements.
These heuristics constitute different types of analogy and reference
that a designer may use to drive the design process forward. They are
not mutually exclusive, and tend to be used in combination. In addition,
they may be developed through repeated application, or they may be
created for one project and subsequently discarded.
Design ideas as resolution of constraints
Researchers have also made a distinction between design ideas that result
from specific aspects of the design environment, and design ideas that are
more general and that may be applied to a range of different projects. For
example, Rowe (1987, p. 2) describes two styles of designing: “Sometimes
the unfolding of a design is strongly influenced by constraints derived
from the initial setting of the problem, such as the context in which
the building is to be built or its social purpose. On other occasions the
process seems to be more determined by a designer’s personal attitudes
and prejudices towards such things as functional expression or modes of
fabrication technology.”
Lawson (1997, p. 189-202) conceptualises design ideas as constructs
that are developed to resolve specific constraints. Such constraints may
either be existing in the design problem, or may be self-imposed by the
designer. Lawson argues that most designers will be highly selective
in deciding which constraints to focus on, and during the early design
stages, the number of constraints to be considered is likely to be small.
In order to investigate how initial design ideas are used in practice,
Lawson (1997, p. 189-202) analyses the design presentations of three
groups of students working on the same problem. Each group of students
chose to focus on a different set of constraints — either self imposed
or existing — and as a result, each group developed a fundamentally
different set of design ideas.
Lawson identifies three main types of constraints:
The existing constraints specified in the design requirements
The existing constraints related to the design context, such as the
The self-imposed constraints, embodied in their design stance.
These three types of constraints result in three types of design ideas
that are fundamentally different from one another.
2.6 Summary
This chapter has discussed the design process, focusing mainly on meth-
ods and theories developed from the 1960’s onwards. The main points
are as follows:
The methods and theories of the 1960’s and 1970’s suggested that
the design process should be highly rational and objective, and in
many cases it was assumed that one correct design method could
be defined. Today, many researchers describe the design process
as process of negotiation between multiple participants, involving
people and systems interacting together and exchanging informa-
tion and knowledge that tends to be incomplete, inconsistent and
The roles of the computer in the design process has changed. In the
1960’s and 1970’s, researchers proposed computer systems that sup-
ported completely new ways of working. In the 1980’s and 1990’s,
computers in design became much more prominent, but they were
generally used to support conventional working methods. More re-
cently, the role of the computer is again becoming more ambitious,
with computers being used to support non-conventional design pro-
When designers approach a design task, they have a set of design
preconceptions that are personal and idiosyncratic. Designs task
are typically ill-defined and ambiguous, and as a result such pre-
conceptions are required to develop a design. Preconceptions are
an important and necessary ingredient in the design process. Two
types of preconceptions exist: a general design stance that encom-
passes the philosophical beliefs and cultural values of the designer,
2.6. SUMMARY 54
and specific design ideas that are applicable in certain types of
design projects.
A number of researchers have explored the role of design ideas in the
design process. Different types of design ideas have been identified.
In particular, design ideas may be project specific, or they may be
more generic and applicable in a variety of projects.
Chapter 3
Generative techniques
3.1 Introduction . . . . . . . . . . . . . . . . . . . 55
3.2 Parametric approach . . . . . . . . . . . . . . 56
3.2.1 Overview . . . . . . . . . . . . . . . . . . . . 56
3.2.2 Variational based parametric technique . . . 57
3.2.3 History based parametric technique . . . . . 60
3.3 Combinatorial approach . . . . . . . . . . . . 62
3.3.1 Overview . . . . . . . . . . . . . . . . . . . . 62
3.3.2 Algebra based combinatorial technique . . . . 62
3.3.3 Template based combinatorial technique . . . 63
3.4 Substitution approach . . . . . . . . . . . . . . 65
3.4.1 Overview . . . . . . . . . . . . . . . . . . . . 65
3.4.2 Grid based substitution technique . . . . . . 67
3.4.3 Shape based substitution technique . . . . . . 70
3.4.4 Context-free versus context-sensitive substitu-
tion approaches . . . . . . . . . . . . . . . . . 75
3.5 Summary . . . . . . . . . . . . . . . . . . . . . 77
3.1 Introduction
This chapter consists of three sections, each introducing a different ap-
proach to creating programs that generate three-dimensional forms. These
approaches may be used within the developmental step of an evolutionary
system in order to create alternative design models. The first approach is
the parametric approach, and is used by parametric evolutionary design
systems. The second and third approaches — referred to as the com-
binatorial and substitution approaches — are more flexible. Generative
evolutionary design systems may use a combination of any of these three
approaches in order to generate a variety of design models.
For each approach, two more specific techniques are identified.
In section 3.2, the parametric approach is described, which involves
generating forms by varying a number of parameters. Two tech-
niques are introduced that differ in how the parameters affect the
final form. With the variational technique, parameters are assigned
to variables associated with a model of the form. Parametric mod-
elling systems use this technique. With the history based technique,
parameters are assigned to variables associated with a sequential
procedure for creating a form.
In section 3.3 the combinatorial approach is described, which in-
volves generating forms by combining a predefined set elements.
Two techniques are introduced that differ in how elements are com-
bined. With the algebra technique, a set of element types are de-
fined together with a set of operations for manipulating these ele-
ments. This technique is highly flexible, and is implemented within
most standard CAD packages. With the template technique, an
organizational template is defined into which elements can be in-
In section 3.4, the substitution approach is described, which in-
volves generating forms by starting with a seed form and repeatedly
substituting parts of this form with new parts. Two techniques are
described that differ in how the substitutions are performed. With
the grid based technique, a grid is defined and substitutions are
performed within this grid. Cellular automata are the best known
example of this technique. With the shape based technique, sub-
stitutions are performed based on the geometry of the individual
shapes. Fractals, shape grammars and L-systems are well known
3.2 Parametric approach
3.2.1 Overview
The parametric approach allows a variety of designs to be generated
by varying constraints associated with either a model or a procedure.
For example, a model may be created that defines certain dimensions
as variable parameters, thereby allowing a variety of forms to be gen-
erated by varying those parameters. However, the parametric approach
is not limited to varying simple dimensional parameters. The paramet-
ric approach is understood to cover what can be found in the literature
under other headings such as relational modelling, variational design,
Figure 3.1: Main inputs and outputs for the parametric approach.
constraint-based design, and so forth. In the broader sense, the para-
metric approach can be thought of as varying constraints, where dimen-
sional parameters are just one type of constraint. Monedero (2000) gives
an overview of various types of parametric modelling approaches. He
describes a constraint as follows: “A constraint is a relation that limits
the behaviour of an entity or group of entities... Parallelism, perpendic-
ularity, tangency, dimensionality are geometric constraints. But a model
can also be based on formula like area = force/pressure. Constraints can
also be specified as conditional relations...”.
Two parametric techniques
Monedero highlights two techniques to parametric modelling: the vari-
ational based parametric technique and the history based parametric
With the variational technique, a model of the form to be generated
is first defined. The model incorporates a set of constraints defined
as equations. The entire system of constraints for the design is
solved simultaneously by a constraint solver. Unlike the history
based technique, the variational technique generates a form without
making reference to the sequence of modelling operations used to
create the form.
With the history based technique, a form is incrementally con-
structed by a form generating procedure. This procedure consists
of a sequence of operations, with each operation requiring certain
data values. The form can subsequently be modified by manipu-
lating either the operations themselves or the data values used in
a particular operation.
3.2.2 Variational based parametric technique
Creation of parametric model
With the variational approach, a model of the form to be generated
must be predefined. The model may be a topological description of a
complex form with a number of associated variables. A parameter is a
variable to which other variables are related, and these other variables
can be obtained by means of parametric equations. In order to generate a
form, the generative program requires a system capable of resolving these
equations. Models may be irresolvable as a result of being either under
constrained or over constrained. An under constrained model cannot be
resolved because some additional parameter must still be specified. An
over constrained model cannot be resolved because of the existence of
some contradiction.
Concerning the variational approach, Monedero writes: “Parametric
design based on variational geometry can recompute a design taking into
account that actual situation, independently of the sequence that has
been followed to reach this situation. The method relies on the descrip-
tion of parameters by means of equations and the availability of a system
able to solve them.”
Simple example
A simple example is given by Mitchell (1977, p. 40-43), when he models
a rectangular room by defining three variables: d1 represents the length,
d2 represents the width, and d3 represents the height. One of the vertices
of the room is defined as being fixed, and the other seven vertices can be
calculated from the three variables. By substituting different values for
the variables, different rooms can be generated.
More generally, this example can be described in terms of the degree
of freedom (DOF) of the model. Monedero (2000) writes: “An object in
a space, defined by the three co-ordinates of their N-vertices will have
3NDOF. To compute the new geometry, after any of these vertices have
changed, 3Nequations (with 3Nvariables) will have to be solved.”The
room has eight vertices and as a result may potentially have 24 DOF.
The 24 equations can all be solved using the three variables described
by Mitchell — d1,d2, and d3. The room model defined by Mitchell
therefore has zero DOF which means that it is neither under-constrained
nor over-constrained.
A serious drawback with this technique is that the model must, to
a large extent, predefine the topology of the form, The forms generated
are therefore very similar. In addition, as the complexity increases, the
process of solving the equations becomes computationally expensive.
Yacht hull forms
As well as defining flat surfaces, the vertices can also define control points
on curved surfaces. For example, Graham et al. (1993) (see also (Frazer,
1995b, p. 61)) used a variational parametric program in order to generate
curved forms that represented yacht hulls. This was part of a larger
system that used genetic algorithms in order to optimise the performance
of racing yacht hulls. A model of the yacht hull was created in which the
fairing of the curves of the hulls profile were defined by a set of control
points. The variational parametric program generated alternative yacht
hulls by varying these control points.
Figure 3.2: Optimization of yacht hull using a genetic algorithm. From
Frazer (1995b, p. 61).
The examples of the room and the yacht are fairly simple. The varia-
tional parametric approach is capable of generating forms that are much
more complex. In particular, this technique is dependent upon the equa-
tions being solvable, rather than on the complexity of the model.
Waterloo Station
Variational based parametric modelling techniques were used in the de-
sign of the Waterloo railway station in London Szalapaj (2000, p. 135).
The arched roof of the train shed follows the curve of the railway, and in-
creases in span down the length of the station. The roof is supported by
a series of three-pin arches that change as the roof changes width along
the curved tracks. A single parametric model of an arch was modelled,
such that it encoded the underlying design rules for the whole family of
arches. The complete roof model was then created by instantiating a
series of these parametric arches, each with a different value for the span
Szalapaj (2000, p. 135) writes:
“The parametric model can be extended from just the de-
scription of arches, through to the description of the connec-
tions between pairs of arches. This model can in turn be ex-
tended to the whole shed form, so that when any dimensional
change is made, it is propagated through the whole model.
Parametric expressions, therefore, allow users to change the
values of key parameters, and to observe the propagation of
changes on dependent expressions, and hence upon the de-
Figure 3.3: An example of a set of rules and the corresponding forms.
From Todd and Latham (1999).
pendent geometry. This is often referred to as strategic ma-
3.2.3 History based parametric technique
Creation of parametric procedure
Monedero describes the history based parametric technique as follows:
“A graphically interactive parametric modeller allows the user to cre-
ate a master model that can be used as a base to input parameters to
the system and to request from the user the specification of constraints
that will fix the model through a closed description of its components.”
In general, a form generating procedure is defined. A variety of forms
can be generated by manipulating the constraints associated with this
The FormGrow program
An example of a history based parametric program is FormGrow, devel-
oped by Todd and Latham (1992, 1999), which artists can use to generate
three-dimensional forms. FormGrow builds three-dimensional models of
abstract organic forms using a set of growth rules. The basic growth
process creates a compound form by duplicating a specified input form.
When the input form is duplicated, it is subjected to a series of trans-
lations and transformations as specified by a list of rules. For example,
the ‘stack’ rule will stack the input forms on top of each other, while the
‘grow’ rule will scale the input form each time it is duplicated. The input
form can either be a primitive shape such as a sphere, or it can itself be
a compound form. A simple script language allows the input forms and
the translation and transformation rules to be specified.
Figure 3.4: Some examples of forms generated using the Xfrog software.
The Xfrog program
Another history based parametric program is Xfrog (Lintermann and
Deussen, 1999), a program that allows the easy generation realistic flow-
ers, bushes and trees. More generally, the program can be used to gen-
erate a huge variety of hierarchical structures. In this case, a graphical
interface allows the user to easily create a set of nodes and links that
encapsulate the generative rules used to generate the structure. Lin-
termann and Deussen write: “The nodes of the graph are components
that represent parts of a plant, and the edges denote creation dependen-
cies... components encapsulate data and algorithms for generating plant
elements. Generally, three categories exist: one group of components cre-
ates graphical objects like stems, twigs, leaves or geometrical primitives;
the second multiplies other components; the third applies applies global
modelling techniques.” An example of the first type of component is a
simple primitive like a cone. An example of the second component is the
‘PhiBall’ component which arranges child components on the surface of
a sphere by the golden section algorithm. The parameters include the
number of times to duplicate a child, the radius and the opening and
closing angle of the spherical section, and the size of the children and
their influence on the placement. An example of the third component is
the ‘Patch’ component which specifies free-form deformations by moving
control points. These three components can be combined and customised
in order to encapsulate a set of rules that can generate a configuration
of a few hundred cones.