1. INTRODUCTION
Architectural design is not a linear process; it involves the stages of proposition, testing, refinement, analysis, and rejection, but not necessarily sequentially. For example, in a study of Frank Gehry's office, Boland et al. (Reference Boland, Collopy, Kalle and Youngjin2008) describe Gehry's design process as existing in a “liquid” state for a long period before eventually becoming “frozen” into a proposition for a building. During the liquid state, drawings and models are made, tested, and rejected, being refined until a “final” solution is crystalized. In this way, Gehry et al. explore and respond to different aspects of the design problem, alternatively shifting the focus from formal solutions to contextual problems, technological challenges, and functional optimization. For Gehry's team, this shift from problem definition and analysis to solution proposition and testing is often signaled by the decision to digitize a physical model for further refinement and development. While Gehry's forms and buildings may appear to be more challenging than those of many other architects, his team follows a much more common cyclical design process, which reflects architects’ thoughts, actions, and behaviors as they shift their focus from considering design problems to testing design solutions. The parallel development of problems and solutions in this “liquid state,” which many architects follow, is called coevolution.
The concept of the coevolution of a design “problem space” and “solution space” has been proposed by Maher and Poon (Reference Maher and Poon1996). Design is a process that develops or formulates a problem and ideas for a solution, in parallel (Dorst & Cross, Reference Dorst and Cross2001). It has even been suggested that this coevolution of design problem and solution spaces is an indicator of creativity in design (Maher & Tang, Reference Maher and Tang2003). However, the medium or environment in which the design process is undertaken (be it physical and sketch based, or digital and CAD based) also has a significant effect on designers’ cognitive processes (Chen, Reference Chen2001; Mitchell et al., Reference Mitchell, Inouye and Blumenthal2003). One particular medium, the parametric design environment (PDE), has become increasingly prevalent in architectural design in recent years. According to Kolarevic (Reference Kolarevic2003), the change in designing associated with parametricism is characterized by a rejection of the static solutions offered in conventional design systems and the adoption of intelligent systems. This change is claimed to have rendered design processes both more flexible and more productive. Various studies support this view, arguing that parametric tools can advance design processes in a variety of ways (Qian et al., Reference Qian, Chen and Woodbury2007; Schnabel, Reference Schnabel2007; Abdelmohsen & Do, Reference Abdelmohsen and Do2009; Iordanova et al., Reference Iordanova, Tidafi, Guité, De Paoli and Lachapelle2009). However, there is a lack of empirical evidence supporting an understanding of designers’ behavior in the PDE. This paper focuses on exploring the coevolution of design problem and solution spaces in PDEs.
In order to examine the way designers think and act in a PDE, the designers’ cognitive activities while they are designing in a PDE are studied. In the study reported here, eight designers were asked to complete an architectural design task in a PDE. Protocol analysis (Ericsson & Simon, Reference Ericsson and Simon1993; Gero & McNeill, Reference Gero and McNeill1998) was then employed to examine the designers’ behavior and identify the cognitive activities associated with problem–solution coevolution in PDEs.
2. BACKGROUND
2.1. Parametric design
Parametric design is a digital design method that is characterized by rule algorithm design and multiple solution generation (Abdelsalam, Reference Abdelsalam2009; Karle & Kelly, Reference Karle and Kelly2011). As Woodbury (Reference Woodbury2010) argues, it supports the creation, management, and organization of complex digital design models. The term “parameters” is used to describe factors that determine a series of variations leading to a potentially infinite range of possibilities being generated (Kolarevic, Reference Kolarevic2003). In the architectural design industry, parametric design tools are mainly used for complex form generation, multiple design solution optimization, as well as structure and sustainability control. Common parametric design software includes Generative Component from Bentley Corporation, Digital Project from Gehry Technology, and Grasshopper from McNeel. Scripting tools, for authoring and defining parameters, include Processing based on the Java language, Rhino script, and Python script, based on VB language from McNeel. In this study, we chose Grasshopper as the PDE because it is an advanced environment for facilitating conceptual design and a relatively popular tool in the architectural profession.
Researchers have suggested that parametric tools support the design process in various ways. For instance, Iordanova et al. (Reference Iordanova, Tidafi, Guité, De Paoli and Lachapelle2009) examined students’ behavior when using parametric design software and found that ideas were generated more rapidly in PDEs, while more variations also emerged simultaneously. Schnabel (Reference Schnabel2007) argues that PDEs are beneficial for generating unpredicted events and for accommodating changes. However, researchers have typically studied design behavior in PDEs by using informal observation techniques and interviews with students in a studio or workshop setting. Such approaches typically lack empirical evidence and can provide only a very limited understanding of designers’ behaviors. This empirical gap is addressed in the present study by adopting the method of protocol analysis, a method used for in-depth or detailed analysis of any number of cases or participants. Lee et al. (Reference Lee, Gu, Jupp and Sherratt2012) have demonstrated the use of protocol analysis to evaluate creativity in PDEs. Using the same method, Chien and Yeh (Reference Chien and Yeh2012) explore “unexpected outcomes” in PDEs. Results of these studies both confirm the viability of the method and also suggest that some conditions in PDEs can potentially benefit the designers’ process.
2.2. Problem–solution coevolution in design
Design is not just a linear process of finding solutions to an initial given task or requirement; it is also about redefining and reframing the design problems that have been provided (Asimov, Reference Asimov1962; Schön & Wiggins, Reference Schön and Wiggins1992; Suwa et al., Reference Suwa, Gero and Purcell2000). During the design process, designers continue to redefine their design intentions, searching for alternative resolutions. This iterative process, which revisits both problems and solutions during the design process, should not simply be regarded as a cyclical series of events, because with each recursion in the process, the parameters have evolved and shifted. Previous studies show that the expert design process also involves a close interaction between representations of problems and solutions (Cross, Reference Cross2011). The coevolution of design problem and solution spaces is one possible way to conceptualize the design process. Instead of seeing design as a process of progressive refinement (concept design, to schematic design, to developed design), design could be analyzed through the way the cognitive effort shifts between the consideration of problems and solutions (Maher & Poon, Reference Maher and Poon1996; Dorst & Cross, Reference Dorst and Cross2001). Design is a process that uses analysis, synthesis, and evaluation as it shifts between the design problem and possible solutions (Asimov, Reference Asimov1962; Lawson, Reference Lawson1997; Cross, Reference Cross2011). It is during this process that designers formulate critical questions and explore answers, and thus the developing relationship between the “problem space” and the “solution space” is at the core of the coevolution model of design. Maher and Poon (Reference Maher and Poon1996) and Dorst and Cross (Reference Dorst and Cross2001) each use this model to suggest that the coevolution of design problem and solution spaces has a close correlation with the occurrence of design creativity.
The concept of problem–solution coevolution is described by Maher and Poon (Reference Maher and Poon1996; Fig. 1). Although it was developed for computational exploration (from an AI perspective), the model also describes a common design process. In the coevolution model, the problem space (P) and solution space (S) interact over time (t; Fig. 1). Designers start by analyzing the initial design requirements and formulating the design problem, P(t). While exploring possible design solutions S(t) for the problem P(t), new intentions are added into the problem space over time P(t + 1). This is a core process for coevolution in design, and particularly so when the solution does not satisfy a key requirement; by changing or adapting the requirements and intentions, a satisfactory problem and solution pair could be generated (Maher & Poon, Reference Maher and Poon1996; Dorst & Cross, Reference Dorst and Cross2001).
Fig. 1. The coevolution model based on Maher and Poon (Reference Maher and Poon1996).
In a development of Maher and Poon's coevolution model, Dorst and Cross (Reference Dorst and Cross2001) propose a refined version that further illustrates the creative process from a behavioral perspective. Their study employed the method of protocol analysis, in which nine industrial designers were observed. In their model (Fig. 2), the designers start from a design problem space P(t), and develop a partially structured problem [P(t + 1)△], which is then used to develop a partially structured solution space [S(t + 1)△] of S(t). This process is repeated throughout the design progress, as Maher and Tang (Reference Maher and Tang2003) suggest, with the transition between design problem and solution occurring in cyclical iterations until a satisfactory solution is developed. Dorst and Cross further argue that this coevolution process is vital to support the highest level of creative design (Cross & Cross, Reference Cross and Cross1998; Dorst & Cross, Reference Dorst and Cross2001). While the focus of the present paper is not explicitly on creativity in the design process, there are, as this past research suggests, several indicators of creative potential in the coevolutionary design process, which the present research can consider in the context of PDEs.
Fig. 2. The coevolution model based on Dorst and Cross (Reference Dorst and Cross2001).
3. APPLYING THE FUNCTION–BEHAVIOR–STRUCTURE (FBS) ONTOLOGY TO EXPLORE THE COEVOLUTION PROCESS IN PDES
3.1. Protocol studies using the FBS ontology
Protocol studies record and convert qualitative verbal and gestural utterances and actions into quantitative research data (Ericsson & Simon, Reference Ericsson and Simon1993; Gero & Mc Neill, Reference Gero and McNeill1998). They have been used extensively in design research to develop an understanding of design cognition (Suwa & Tversky, Reference Suwa and Tversky1997; Atman et al., Reference Atman, Chimka, Bursic and Nachtmann1999; Kan & Gero, Reference Kan and Gero2008). In such studies a common coding scheme used for design analysis is based on the FBS ontology (Gero, Reference Gero1990; Gero & Kannengiesser, Reference Gero and Kannengiesser2004), which has since been applied to a variety of studies on designers’ cognitive behavior (Gero & McNeill, Reference Gero and McNeill1998; Kan & Gero, Reference Kan, Gero, McDonnell and Lloyd2009; Lammi, Reference Lammi2011; Tang et al., Reference Tang, Lee and Gero2011; Kan & Gero, Reference Kan, Gero, Petre and van der Hoek2012).
The FBS ontology (Fig. 3) contains three classes of concepts: function (F), behavior (B) and structure (S). Function represents the intentions or purposes of the design; behavior represents how the structure of a designed artifact achieves its functions, either derived (Bs) or expected, from (Be) structure; and structure represents the components that make up an artifact and their relationships. Figure 3 identifies and numbers the eight design processes derived from this ontology: formulation, analysis, evaluation, synthesis, documentation, and three types of reformulation (–1, –2, and –3). Among the eight design processes, the three types of reformulation are said to be the dominant ones, potentially capturing innovative or creative aspects of designing by introducing new variables or directions (Kan & Gero, Reference Kan and Gero2008). The present study of coevolution in PDEs adopts the FBS ontology as its central theoretical framework because it clearly distinguishes the eight types of design processes, which provides opportunities to examine design cognition in detail (Kan & Gero, Reference Kan, Gero, McDonnell and Lloyd2009). Kan and Gero (Reference Kan, Gero, Petre and van der Hoek2012) apply the FBS ontology to a study of software designers’ behavior, suggesting that the method was effective for encoding programming/rule-based activities across different design disciplines. Given that PDEs enable scripting/programming activities, it is anticipated that the FBS scheme will be able to encode both geometric modeling and rule-based algorithmic activities effectively. For this study, one of the original codes in the FBS ontology, description (D), has been excluded because in PDEs this process rarely occurs. For example, whereas in the sketching environment there is a regular need to document or describe design decisions and actions (D), parametric modeling tools automatically document and describe a three-dimensional model directly from the actions of programming and scripting and as part of the consideration of structure (S). Therefore, the present study does not include a consideration of the description (D) code.
Fig. 3. The function–behavior–structure ontology based on Gero and Kannengiesser (Reference Gero and Kannengiesser2004).
3.2. Two levels of design activities in PDEs
The ways in which parametric design is used by architects are not well understood, which is why some argue that parametric design “requires a deeper understanding of how it can support our intentions as architects” (Sanguinetti & Kraus, Reference Sanguinetti and Kraus2011, p. 47). Compared to traditional design environments, in PDEs architects not only design by applying specialist knowledge but also define rules and their logical relationships using parameters (Abdelsalam, Reference Abdelsalam2009). Woodbury (Reference Woodbury2010) claims that in the PDE, designers need a different kind of geometric knowledge that can “predict persistent effects to understand the diversity and structure of the mathematical toolbox, and to shuttle between the intended effect and mathematical invention that models it.” This implies that designers need to know how the mathematical tools will work in the design development processes in addition to their base architectural knowledge. As Aranda and Lasch (Reference Aranda, Lasch, Sakamoto and Ferré2008) observe, the parametric design process mediates between two worlds. The first is an abstract and coded system from which complex spatial forms emerge through rule-based mathematical expressions. The second world is the space where the designers apply their design knowledge to address the needs of people, cultures, communities, and cities. When an architect models a building form using parameters, he must assess variations, design data flow routes, and adjust the values of parameters, and revise rules. At this time, the architect is thinking about not only the particular building design but also the rule design. It is through the control of logical relationships between forms and functions that the possibilities for design solutions are heightened (Hernandez, Reference Hernandez2006; Karle & Kelly, Reference Karle and Kelly2011).
Therefore, in a typical parametric design process, there are design activities on two levels: the design knowledge level and the rule algorithm level. In the design knowledge level, architects make use of their design knowledge, including, for example, how to adapt a building to the site, how to shape the way people use the building, and how to satisfy the requirements of their clients. At the rule algorithm level, designers apply design knowledge through the operations of the parametric design tools, including defining the rules and their logical relationships, choosing the parameters suitable for a particular purpose, and importing external data into the proposed rules. During the design process, designers progress by applying specialist knowledge; in some parts (viz., the rule algorithm level), they apply design knowledge indirectly by defining rules and their logical relationships, and this is known as parameterization. In order to capture the processes involved in designing in PDEs, the main class of variables from the original FBS ontology that have been used, which are also referred to as cognitive design issues or just design issues, are R, F, Be, Bs, and S. Each variable is then further decomposed into the two levels of design activities: the design knowledge level, denoted by the superscript K, and the rule algorithm level, denoted by the superscript R (Fig. 4). This does not require an extension of the ontological variables because each decomposition is an instantiation of the base ontological variable.
Fig. 4. Applying the function–behavior–structure ontology in the parametric design environment.
3.3. Interpretation of FBS coding in a PDE
1. Requirement (R R) in the rule algorithm space: Requirement (R) variables include “all requirements and constraints that were explicitly provided to the designers at the outset of the design task” (Gero et al., Reference Gero, Kannengiesser, Pourmohamadi and Gero2014, p. 286). Within the context of the present study, requirement (R) codes refer to these moments when designers considered or reviewed the content of the design brief provided. Because there is only design related information in the brief, all the requirement variables will be coded as R K. Therefore, there will be no instances of “requirement” variables at the rule algorithm level (R R).
2. Function (F R) in the rule algorithm space: In the FBS ontology, function (F) variables describe “the teleology of the object, which means ‘what it is for’” (Gero & Kannengiesser, Reference Gero and Kannengiesser2004, p. 374). Function F is the purpose or intention of a design, which shapes the idea in designers’ cognitive thinking. The concept of F does not vary between different design environments. The claim is that design tools do not affect the “function” of the design. In the PDE, the architect still needs to consider design intention and decide which factors to parameterize or constrain and where to assign the weight for specific factors (Ottchen, Reference Ottchen2009, p. 23). Therefore, in PDEs F variables comply with the original understanding of function in the FBS model. Thus, if designers talk about the design intention or purpose, the segments should be coded as “function” (F K). When designers talk about function of the rule, it is about the effect they want the rule to achieve. These segments are coded as expected behavior of the rule (BeR). Therefore, there will be no instances of “function” variables at the rule algorithm level (F R).
3. Behavior (B) in the rule algorithm space: In the FBS ontology, behavior (B) variables “describe the attributes that are derived or expected to be derived from the structure variables of the object, which means ‘what it does’” (Gero & Kannengiesser, Reference Gero and Kannengiesser2004, p. 374). There are two types of B: expected behavior (Be) and behavior derived from structure (Bs). In PDEs, B variables express different meanings at the rule algorithm level.
• Be: A Be is one where “designers use theory or experience to speculate what effect could fulfill a purpose before a specific structure is proposed” (Jiang, Reference Jiang2012, pp. 36–37). This interpretation has been well understood at the design knowledge level. When it comes to the rule algorithm level, expected behavior of the rule (BeR) means that designers set up algorithm goals or think about the way to achieve those goals in the rule algorithm space (Table 1).
• Bs: A Bs is an actual behavior. At the design knowledge level, Bs represents an evaluation of existing geometry/structure, while at the rule algorithm level, Bs signifies an evaluation of the structure of the rule algorithm. When designers examine the current rule, the segments will be coded as “BsR” (Table 2).
4. Structure (S) in the rule algorithm space: In the FBS ontology, structure (S) variables describe “the components of the object and their relationships, which mean ‘what it is’” (Gero & Kannengiesser, Reference Gero and Kannengiesser2004, p. 374). In the design knowledge space, structure (S) variables refer to the elements or relationships of the geometries, whereas in the rule algorithm space, it is defined as the structure of the rule algorithm: the components of rules and their relationships for parameterization. In PDEs, designers also produce form as geometry, that is, structure in the design knowledge space. This can be modeled by directly applying design knowledge, or through the rule algorithm. In the latter case, a set of parameters and parametric commands will be used. Designers define relationships to connect these elements to form the rule algorithm. When designers organize the structure of rules or make parametric commands, the segments will be coded as S R (Table 3).
Table 1. Expected behavior interpretation in the rule algorithm space (BeR)
Table 2. Structure behavior interpretation in the rule algorithm space (BsR)
Table 3. Structure interpretation in rule algorithm space (SR)
3.4. Problem–solution division in the PDE
This paper adopts the problem and solution division identified in the FBS model (Jiang et al., Reference Jiang, Gero, Yen and Gero2014) to distinguish problem-related and solution-related design issues. In the FBS ontology, problem-related issues include design consideration about requirements (R), function (F), and expected behaviour (Be). Solution-related issues involve design considerations about structure (S) and behaviour derived from the structure (Bs).
Based on Jiang et al.’s problem and solution division, Table 4, and the understanding of the two levels of activities in the PDE (Fig. 4), design problem-related issues and design solution-related issues are further divided into: problem-related issues at knowlege level (P K, including R K, F K, and BeK), problem-related issues at the rule algorithm level (P R, including BeR); solution-related design issues at the knowlege level (S K, including BsK and S K) and solution-related design issues at the rule algorithm level (S R, including BsR and S R), as shown in Table 5. This division is consistent with the characteristics of parametric design in that designers not only think about problems from the design perspective but also have to formulate problems using rule design, which is essential in the PDE.
Table 4. Mapping function–behavior–structure design issues and processes onto problem and solution spaces (Jiang et al., Reference Jiang, Gero, Yen and Gero2014)
Table 5. Mapping function–behavior–structure design issues onto problem and solution spaces in the parametric design environment
4. EXPERIMENT SETTING
The study reported in this paper is based on the work of eight designers, who are all professional architects with an average of 8 years of experience, and with no less than 2 years of experience using parametric design. In the experiment, each designer was required to complete a defined architectural design task in a PDE. During the experiment, both designers’ activities and their verbalizations (“thinking aloud”) were videorecorded including a screen capture program and the recorded data subsequently used for the protocol analysis. The design environment was Rhino and Grasshopper, a typical PDE. Designers were given 40 min for the design session, along with time to allow for familiarization with the particular systems being used. The design task was a conceptual design for a commercial building containing specific functions and located on a premodeled site (Fig. 5), which was provided to each designer. Because this study focused on exploring designers’ behavior at the conceptual design stage, participants were required to only consider concept generation, simple site planning, and general functional zones. No detailed plan layout was required. The tasks were both open and general enough to provide designers with the freedom to enable various possible strategies to be applied during the parametric design process. As a result, designers exhibited their own typical ways of approaching parametric design so that some of our findings may begin to be generalized. During the experiment, designers were not allowed to sketch manually, so almost all their actions occurred on the computer to ensure that the design environment was purely within the PDE. All of these controls were put in place to limit any variables that could potentially bias the study.
Fig. 5. Site model provided to the designers during the experiments.
5. EXPLORING THE IMPACT OF RULE ALGORITHMS ON THE COEVOLUTION PROCESS IN THE PDE
5.1. General results
In order to produce robustness of the protocol coding results, two rounds of segmentation and coding were conducted with an interval of 2 weeks between them. Following the two segmentation and coding rounds, an arbitration session was carried out to produce the final protocol from the combination of the two rounds. The percentage of agreement between the two rounds was 83.4%, (SD = 5.7%) and between the individual rounds and the final arbitrated results, 91.5% (SD = 3.1%). These percentages are indicative of the methodological reliability of the coding process and results. Analysis of the eight protocols revealed the mean total numbers of segments was 244 (SD = 29.7, where a segment is the division of protocols into individual units; in the current research, the division was based on the FBS ontology and coresponded to design issues). The mean time spent on the design sessions was 48.4 min (SD = 7.4), and over 92.2% of all segments were coded using the FBS model. Noncoded segments include those concerned with communication and software management.
The distributions of “design issues” in the protocols, both at the knowledge and the rule algorithm levels in the PDE, are shown in Figure 6. From Figure 6 it can be seen that solution-related design issues (Bs and S) have the highest frequency, and there are fewer problem-related issues (R, F, and Be). Qualitatively, the rule algorithm plays an important part in both Be and S. Particularly from the Be result, we can infer that designers set rule algorithm goals/requirements and consider the way to achieve the rule algorithm goals frequently in the PDE. The quantitative anlysis of FBS design issue occurrences are shown in Table 6. The occurrence of design issues was normalized by dividing them by the total number of coded design issues. The results indicate that designers spent most cognitve effort on the structure-related design issues, which consist of S K (21.56%) and S R (20.49%). These are followed by BsK (23.55%) and BsR (5.18%). Considerably less effort was spent on R K (1.52%) and F K (5.09%).
Fig. 6. Design issue distribution at both the design knowledge and rule algorithm levels in the parametric design environment.
Table 6. Design issue analysis
5.2. Transition patterns between the design problem and solution spaces in the PDE
The nature of the transitions between problem space and solution space, which is critical to the concept of coevolution (Dorst & Cross, Reference Dorst and Cross2001), can be examined by calculating the discontinuity ratio of the designers’ design process, a value which can indicate the frequency of interactions between design problem and solution spaces. The discontinuity ratio is the ratio of the number of transitions to the overall number of segments [Eq. (1)]. This ratio represents the frequency of transitions between the problem and solution spaces in a given period. The higher values of this ratio indicate that interactions between design problem space and solution space occur more frequently, which suggests a productive coevolution process.
$${\rm discontinuity\ ratio} = \displaystyle{\sum\nolimits_{\rm transition\ number} \over \sum\nolimits_{\rm overall\ segments\ number}} \times 100\%.$$The discontinutiy ratios of transition between the design problem and solution spaces in the PDE are shown in Figure 7. The numbers on the arrows represent the average (of eight participants) discontinuity ratio of each transition during the entire design process. For instance, for designer E, the number of transitions from P R to S K is 11, the overall coded segment number is 243, thus the discontinuity ratio of P R to S K is 11/243 = 4.53%. Table 7 shows the quantitative analysis of the transitions between design problem space and design solution space.
Fig. 7. Discontinuity ratios between the design problem and solution spaces.
Table 7. Transition occurrences between design problem space and design solution space
As shown in Figure 7 and Table 7, the discontinuity ratios of transition from design problem space to solution space (18.29%) and from design solution to problem space (18.39%) are similar. Within this the dominant ones are between P R and S K (with discontinuity ratios of 8.65% and 8.09%), and between P R and S R (with discontinuity ratios of 5.80% and 5.05%). From this we can infer that the transitions tend to remain within the design knowledge level or the rule algorithm level and less frequently occurs across different levels. Although the transition across different levels occurs less frequently, among the transitions across different levels, there are relatively more between P R and S K (with discontinuity ratios of 2.74% and 3.49%), which might mean that designers sometimes reframe the design problem space or requirements at the rule-algorithm level based on design-knowledge-related considerations. One example of S K to P R that occurs frequently in the PDE is that designers set new rule-related design goals based on the evaluation of the geometry model at the design knowledge level. The pattern that most infrequently appears is the transition between P K and S R (with discontinuity ratios of 1.66% and 1.20%). In particular, there is only a very small percentage for the occurrence of the transition from S R to P K (with discontinuity ratio of 1.20%), which suggests that designers rarely reframe design problems at the design knowledge level based on the rule algorithm solution.
5.3. Transition patterns across the whole design session
In order to further articulate the eight types of transitions (as outlined in Fig. 7 and Table 7) between the problem space and solution space across the design session, the distribution of the discontinuity ratio of each transition in the PDE is presented in Figure 8. The horizontal axis in Figure 8 is the design session divided into ten subsessions, deciles, each with an equal number of segments, while the vertical axis represents the average discontinuity ratio (of the eight participants) of the transition patterns in each decile of the design session.
Fig. 8. Distribution of the discontinuity ratios in the parametric design environment across time.
In the following description, we define the “early design stage” as the period 1–3.3 on the horizontal axis, the “mid-design stage” as 3.4–6.7, and the “end design stage” as 6.7–10. The descriptors are thus time based, rather than a direct indicator of the degree to which a design has been completed.
The eight types of transitions between the design problem space and design solution space are shown by the eight lines in Figure 8, respectively, representing P R to S R, P K to S K, P R to S K, P K to S R, S R to P R, S K to P R, S K to P R, and S R to P R. At the early design stage the dominant transition is between P K and S K. At the mid-design session, the dominant transition is between P R and S R, although the transition from S K to P K is still active. There are more transitions between P R and S R toward the end of the design session. We can infer from this that, at the beginning of the design session, the coevolution process is focused on the design knowledge level; at the mid-design session, the coevolution process is active at both design knowledge and rule algorithm levels; and at the end of the design session, it is more focused on the rule algorithm level. The reason for this pattern may be that at the beginning designers considered the brief from the design knowledge perspective, which is similar to common architectural practice. Later, designers started using the rule algorithm process to implement their goals or concepts. During this process, designers continued to redefine the design problem while they were searching for solutions at a design knowledge level. This is supported by observations of the experiment, which noted that designers tended to start from the brief, then analyze the site, and then develop basic concepts. In the next stage, designers started considering the form or structure of their design, and the rules to implement them. That is, they set rule algorithm goals and explored different ways to achieve them. Meanwhile, designers constantly returned to the design knowledge level to evaluate the current design, and in this way, the initial concept was developed and evolved gradually. At the end of the session, designers concentrated on the rule algorithm design and tried to finalize the model using rules.
5.4. A model of coevolution process in the PDE
The transition processes between design problem and solution spaces at both the design knowledge level and rule algorithm level are shown in Figure 9. The horizontal moves indicate the problem space (P) evolving from time t to time t + 1. The vertical moves are processes where “the problem leads to the solution” or “the solution refocuses the problem” (Maher & Poon, Reference Maher and Poon1996). These moves comply with Maher and Kundu's (Reference Maher, Kundu, Gero and Sudweeks1993) finding that design requirements would change with the design solution: the solution space S(t) is not only a space where a design solution can be explored but also prompts new requirements in P(t + 1) that were not in the original problem space P(t). Figure 9 illustrates a model of the coevolution process in the PDE as identified from this study. The details of this model are further articulated in Figures 10, 11, and 12.
1. Figure 10 presents the coevolution of the problem and solution spaces at the rule algorithm level (indicated as dashed arrows). This coevolution process frequently occured in the PDE. Designers explored solutions for the rule algorithm goals/requirements, P R(t), from the solution space S R(t); they refined or added new requirements to reformulate the rule algorithm problem P R(t + 1).
2. Figure 11 presents the coevolution of the problem and solution spaces at the design knowledge level (indicated as solid dashed arrows). This is the most frequently occurring coevolution process in the PDE. This behavior is similar to that in traditional design environments (Maher & Poon, Reference Maher and Poon1996; Dorst & Cross, Reference Dorst and Cross2001).
3. Figure 12 presents the coevolution process across the design knowledge level and the rule algorithm level (indicated as solid arrows). In this coevolution process, designers started from the problem space at the design knowledge level, P K(t). During the exploration in the solution space S K(t), there were new requiremements emerging at the rule algorithm level. The design problem space at the rule algorithm level P R(t) was refined. Then the exploration of a design problem and solution changed the direction to the rule algorithm level. This is a process in the PDE, in which designers explore the design solution and reformulate the problem across the design knowledge level and the rule algorithm level.
Fig. 9. A model of the coevolution process in the parametric design environment.
Fig. 10. The coevolution process at the rule algorithm level.
Fig. 11. The coevolution process at the design knowledge level.
Fig. 12. The coevolution process across the design knowledge level and the rule algorithm level.
6. CONCLUSION
Design may be conceptualized as a special class of problem-solving processes (Simon, Reference Simon1969) where the problems are either not clearly defined (Maher et al., Reference Maher, Poon, Boulanger, Gero and Sudweeks1996; Chi, Reference Chi1997) or ill defined (Simon, Reference Simon1973; Corne et al., Reference Corne, Smithers, Ross, Gero and Tyugy1994). This is why, in a design process, designers constantly return to the design problem space to reformulate the challenge they are facing (Simon, Reference Simon1973). Through the interaction between cognitive activities in the design problem and solution spaces, the design is progressed until a “satisfactory” outcome is identified (Maher & Tang, Reference Maher and Tang2003). As Cross (Reference Cross2011) and Schön (Reference Schön1983) have suggested, creative design is a process of exploration; during the process, problem and solution spaces are evolving and unstable until fixed by an “emergent” bridge, or a satisfactory problem–solution pair. This coevolution process is significant for understanding the design process.
Parametric design differs from design that uses traditional geometrical modeling because it is reliant on rule algorithms that must operate in parallel with other traditional design behaviors (Yu et al., Reference Yu, Gu and Ostwald2012). In this paper, we have studied the coevolution process in the PDE by examining empirical data derived from experiments with professional designers. The data was generated by employing the protocol analysis method. Through this study the parametric design process has been categorized by a two-level model of design activities: design knowledge and rule algorithm. From the results of the experiment, this division is capable of capturing parametric design behaviors in a sufficiently comprehensive manner that they can help us to understand the design process in this environment.
Based on the division of design activities into two levels, and by calculating the frequency of transitions between the design problem and solution spaces, three particular characteristics of the coevolution process in the PDE have been identified. The first of these is that the coevolution process typically occurs at the individual design knowledge level or rule algorithm level, and only relatively infrequently do transitions occur across the two levels. Second, the designers’ coevolution process is focused on the design knowledge level at the early design stage, while they use more cognitive effort at the rule algorithm level toward the end of the design session. Those activities that are, therefore, most representative of operations in the PDE (activities on the rule algorithm level) play a more important role in the later stages of the session than in its earlier stages. Third, a model that illustrates the main coevolution process in the PDE has been proposed. In this model, three main coevolution subprocesses are identified: coevolution at rule algorithm level, coevolution at the design knowledge level, and coevolution across the rule algorithm and design knowledge levels. The proposed model assists in formally understanding designers’ behavior in terms of interaction between problems and solutions when designing in PDEs.
Rongrong Yu is a PhD candidate in the School of Architecture and Built Environment at the University of Newcastle. Her PhD study is currently focused on exploring designers’ behavior in parametric design. Her research interests include computer-aided design, architecture design theory, design cognition. She has published journal and conference papers related to the topic.
Ning Gu is a Senior Lecturer at the School of Architecture and Built Environment at the University of Newcastle. He currently supervises four PhD students and a number of Honours research students. His research has been in the broad area of design computing and cognition since 1999. His career highlights include leading and participating in various Australian Research Council (ARC) Discovery and Co-operative Research Centre for Construction Innovation projects. The outcomes of his research have been documented in over 130 peer-reviewed journal and conference publications.
Michael J. Ostwald is an ARC Future Fellow and Dean of the School of Architecture and Built Environment at the University of Newcastle. He is a Visiting Professor at RMIT and was previously a Professorial Research Fellow at Victoria University Wellington. Michael is Co-Editor in Chief of the Nexus Network Journal: Architecture and Mathematics, and he is on the editorial boards of ARQ and Architectural Theory Review.
John S. Gero is a Research Professor in architecture and computer science at the University of North Carolina, Charlotte, and a Research Professor in the Krasnow Institute for Advanced Study in Computational Social Science at George Mason University. Previously he was Professor of Design Science and Co-Director of the Key Centre for Design Computing and Cognition at the University of Sydney. He has published over 50 books and 600 research papers. His research has been cited over 4,500 times in the last 5 years.
