Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Background, Motivation and Goals

Conceptual design typically is characterized in terms of evolution of both the design problem and the solution, often described as a process of co-evolution. This characterization distinguishes design from routine problem solving: in problem solving, the problem remains fixed and only the solution to the problem evolves; in design, the problem and the solution co-evolve. While aspects of problem solving are now understood well enough to be implemented in computers, the process of co-evolution of the problem and the solution in design is not yet understood equally well.

Recently, Maher and Tang [1] and Dorst and Cross [2] have proposed computational models of the co-evolution of design problems and solutions. The right side of Fig. 1, which starts at time t + 1, illustrates Maher and Tang’s model: A formulation of the design problem at time t + 1 focuses the search for a design solution. A design solution at time t + 1 may potentially lead to a revised problem formulation at time t + 2, which focuses the search for a new design solution, and so on.

Fig. 1
figure 1

This figure contrasts our model of problem evolution by analogy (left side of the figure) with problem-solution co-evolution (right side of the figure, adapted from Maher and Tang). P represents a design problem, Se represents an existing analogical solution, Sn represents a new design solution

Full size image

We have observed a complementary process in our studies of biologically inspired design: evolution of design problems based on analogies to already known design cases. The left side of Fig. 1 illustrates this process: a formulation of a problem at time t, P(t), leads to an analogy to an already existing solution Se(t) to a known problem. The existing solution then helps extend and expand the problem formulation into P(t + 1), which may result in the construction of a new solution or another analogy to another existing case. We call this process analogical problem evolution. Figure 1 as a whole indicates the process of problem–solution co-evolution including analogical problem evolution: at any step in the process, the formulation of the problem may lead to an analogy to an existing case or the generation of a new solution.

The context in which our observations are made, biologically inspired design (also known as biomimicry or bionics), espouses the use of biological systems as analogues for designing engineering systems [3–7]. In earlier work, we have reported on several findings from our studies of biologically inspired design: In Helms et al. [8] we described problem-driven design and solution-based design as two fundamental processes of biologically inspired design, and also presented a classification of design errors often made in the design processing. Similarly, in Helms et al. [9] we presented data indicating that the use of Structure-Behavior-Function models (SBF, [10]) of biological systems enhances reasoning as compared to textual descriptions as well as textual and diagrammatic representations of the systems. These findings informed the development of tools and techniques for teaching biologically inspired design [11–14]. Other researchers have followed similar research methodologies, coupling empirical studies with tool development (e.g. [15–17]).

Four basic questions in analogical design, including biologically inspired design, are why, what, how and when [18]: Why is knowledge transferred from a source case to a target problem; What knowledge is transferred; How is the knowledge transferred; When does the knowledge transfer occur. In Vattam et al. [12] we found not one, but several answers to the why, what, how, and when questions. In particular, we found that in biologically inspired design, biological designs are used not only for generating design ideas, but also for refining problem definitions, explaining proposed design concepts, and evaluating candidate design solutions. The work we describe here builds on this line of research. In particular, it examines the role of biological analogues in problem evolution from problem inception to conceptual design.

Tracking Problem Evolution

To describe the process of analogical problem evolution, we need a scheme for consistently describing the design problem at a point in time so that we can identify the changes that occur over time. Most modern textbooks on design describe at least partial design problem representations (e.g. [19–21]) has noted, the scope and efficacy of the various problem representation schemes reflects the perspective adopted. In biologically inspired design, Dinar et al. [22] and Helms [23] have proposed two problem representation schemas. For this case study we use a simplified version of the problem schema developed in Helms [23] to represent the problem as a set of functions and constraints.

Problem Schema

We use a problem schema that specifies design problem along two dimensions: (1) the functions desired of the artifact, and (2) the specifications and constraints of the artifact.

Functions Desired of the Artifact

The literature on design contains several distinct and coexisting characterizations of a function. Erden et al. [24] review many functional descriptions in engineering. Borgo et al. [25] formally characterize several functional representation schemes. Carrara et al. [26] suggest that different notions of function coexist in the design literature, including function as the intended state or result of the system, function as a change to substances flowing through a system, and functions as actions the device must perform on an environment in the form of (subject, verb, noun) tuples. In this work, we adopt the last meaning of function above, where the subject is the to-be-designed artifact, the verb reflects the action in question, and the noun reflects the object on which the subject is acting, which we call function-object. In many cases, the noun is the same as the subject e.g. to move self, to clean self, etc. In other cases multiple function-objects may be required.

Functional hierarchy is prevalent in design theory [21, 27], representing a system/sub-system hierarchy in which the function of the sub-system contributes to the function of the larger system. Thus, system S1 performing function F1 is comprised of sub-systems S1−1, S1−2, … S1−n, which perform sub-functions F1−1, F1−2,…F1−n. Each sub-system can then recursively be defined by additional sub-systems and sub-functions. In this sense the functions can be seen as additive, or And-type conjunctions. In order to accomplish F1, the system must perform all sub-functions F1−1 And F1−2 And…And F1−n. In design thinking, designers also consider multiple alternative functions that can be represented as Or-type conjunctions. Chandrasekaran [28] provides an analysis of AND/OR function hierarchies, including the implications of such hierarchies for computational search.

Artifact Specifications and Constraints

Artifact specifications designate properties and values, quantitative and qualitative, of the artifact being designed. Many artifact specifications are constraints, which designate properties and values of the designed artifact terms of inclusion or exclusion such as “must”, “cannot”, or “should”. Other artifact specifications may denote options, which make explicit certain possibilities for properties and values that may be associated with the design artifact, expressed in terms like “could”, “might”, or “possibly” to name a few. Where a constraint is a statement such as “the design must use lightweight materials”, an option may be “the design could use lightweight metal foam”; both talk about the properties of the material from which the artifact will be manufactured, however, one expresses an absolute condition to be met (albeit qualitatively), while the other provides an alternative to be considered.

Artifact specifications can also apply to either manufacturing or performance aspects of the problem. Additional sub-types include: time, shape, structure, material, energy, information, and cost.

Relationships Among Functions and Specifications in the Problem Schema

Several kinds of relationships may exist among the functions and specifications. First, as described above, there may be function → sub-function relationships of both AND and OR types. Furthermore we commonly see function → specification relationships in which a particular function (e.g. propel self through air) implies certain constraints (e.g. material property must be lightweight).

Solution Schema

Since in tracking problem evolution, we are also interested in describing the relationship between problem concepts and existing solutions, we also need a scheme for describing design solutions. Fortunately, there already exist many formal languages from which we may draw, including Functional Basis [29], SAPPhiRE [30], and SBF [10, 31]. In this study, we leverage SBF, a solution modeling schema already created and vetted in earlier work on biologically inspired design [11, 12, 32].

Case Study

Study Context and Participants

Each fall term since 2005, Georgia Tech’s Center for Biologically Inspired Design has offered a senior-level, project-based interdisciplinary course in biologically inspired design (ME/ISyE/MSE/PTFe/BIOL 4740). Faculty members from Georgia Tech’s Schools of Biology, Mechanical Engineering, and Industrial and Systems Engineering jointly teach the course. The course typically attracts 40–45 (mostly) undergraduate students every year. The class composition too is interdisciplinary: the 2009 class comprised of 15 biology students, 11 mechanical engineering students, and 13 students from a variety of academic disciplines.

The 2009 ME/ISyE/MSE/PTFe/BIOL 4740 course was structured into lectures, found object exercises, and a semester-long design project. The semester-long design projects group an interdisciplinary team of 4–6 students together based on similar interests. Instructors ensure that each team has at least one designer with a biology background and a few from engineering disciplines. Yen et al. [13, 14] describe the pedagogy in ME/ISyE/MSE/PTFe/BIOL 4740 in detail.

In 2009, each design team in the ME/ISyE/MSE/PTFe/BIOL 4740 class was tasked with a high-level problem related to building more sustainable homes. Topics included sensing, energy, environment, and resource management. Each team was asked to research their problem and design a solution based on one or more biological systems. Students were responsible for finding, understanding and applying biological systems relevant to their problem. Each team had one or more faculty as mentors who gave expert advice as and when needed. All teams presented their problem and initial design concepts during the middle of the term, then submitted final designs during the last two weeks of class along with a final design report.

The case study in this paper derives from one of the term-long design projects from the 2009 ME/ISyE/MSE/PTFe/BIOL 4740 class. The case was selected from an average performing but well functioning team as representative of a typical design project, with a straightforward design outcome. The design team was formed by the instructors based on student preferences, and consisted of one student each from biology, mechanical engineering, electrical engineering, math, and material science majors. The team was asked to focus on energy generation in the context of sustainable housing. The term-long design project led to a biologically inspired color changing cover for solar thermal water heaters to prevent overheating.

Protocol Study

We analyze the case study using content-oriented protocol analysis [33–35]. Since our case study extends over a term-long trajectory, rather than verbal protocol transcripts, we use documents produced in the context of a class on biologically inspired design as our data source. These work documents are coded and analyzed according to the schema described previously. We refer to each coded element in the schema as a concept.

Data Gathered

We gathered data at four stages to track the progression of the design problem over time. As part of their homework, each design team was required to provide their interpretation of the problem they were working on. The first homework assignment was due 2 days after the assignment of the problem topic. The design team had a single in-class discussion among themselves about their problem. Four of five students turned in a one- to two-page problem description. We used the text of the most comprehensive student description as our data at this stage.

The second stage was the midterm presentation delivered the students. Students were instructed in the midterm presentation to provide (1) an updated problem description, (2) five biological sources to serve as potential sources of inspiration, (3) to demonstrate their understanding of how each biological system worked, and (4) to show how they could apply each source to their problem. We used the design team’s presentation slides and notes as the data at this stage.

The third stage occurred after students were provided feedback from instructors on their midterm presentation. The assignment was the same as the assignment used to collect the first data point; a one- to two-page text-only problem description submitted by each student. We used the text of the problem description of the same student as in the first assignment.

The fourth data point was the final presentation made by the design team. The assignment included the same elements as the midterm presentation, with the addition of a description of the final design and a qualitative analysis demonstrating the viability of the new design. Again, we used the presentation slides and notes as the data from this stage.

Analytical Methodology

Only the text content, including bullet points, formulae, tables and text annotations, from each of the four design documents were considered in this study. Problem descriptions were provided in text only format, and were structured in complete sentences. Presentation material contained less structured text, including tables, bullet points, formulae and tables.

Text was divided into phrases, each of which encapsulated a single schema concept. Some concepts, such as referencing a biological or existing man-made solution, are short and straightforward, such as “the desert snail.” Other concepts such as “so that it is cooler within the shell than the outside air and ground” are more verbose, but encapsulate essentially a single concept: the degree to which the function “cool” must perform.

Relationships were inferred directly from text. If a solution concept was mentioned e.g. “the desert snail cools itself” with respect to a relevant problem concept e.g. “the designed system must cool itself”, the solution was tagged to the problem concept. In this case we say the solution “desert snail” is related to the problem concept, the function “system cools itself”. Another non-biological example is the phrase “we typically think of voltaic cells creating current”, in which voltaic cells are an existing solution, and creating current is a function of that solution (the phrase “we typically think of” is a meta-level design phrase, which is ignored for this analysis.)

As an example of the encoding, take the following text:

The snail shell structure is stand alone and has the ability to passively dissipate heat by using the heat gradient so that it is cooler within the shell than outside the air and ground. This would be helpful for allowing the interior of a structure with solar panels to remain cool. Currently solar panels are rigid and typically pretty sensitive.

In Table 1 we provide a representative sample of text and the breakdown and coding for it. The details of the notation used for coding is not of much importance here, but should provide the reader with a firm grasp of the protocol used. Some cases of encoding text are ambiguous. For example, in Table 1 it is not clear that “stand alone” is indeed a function. This term has potentially many implications for additional specifications and functions. However, lacking explicit elaboration, we make our best guess about the designer‘s intent. The total number of concepts encoded for each of the four data points was stable, varying between 106 to 124 total concepts, with a total of 466 concepts encoded among the four stages. However, the types of concepts and the concepts themselves changed significantly from one state of processing to another.

Table 1 Sample encoding from problem description 2
Full size table

Of the 466 concepts, 35 were not directly related to the design per se, for example the meta-comment “this would be helpful” listed in Table 1. Of the remaining 431 concepts, 24 concepts could not be clearly encoded as a function, a specification/constraint, or neither. This accounts for roughly 5 % of the total number of concepts that were encoded. We consider an ambiguous encoding as any encoding that could reasonably be considered in one or more encoding categories. All encoding was conducted by the first author of this paper and the definition of whether a single encoding was ambiguous or not was at the author’s discretion. Ambiguous concepts are included in the analysis that follows, categorized as the single concept most relevant in the author’s opinion. Some concepts such as perceived deficiencies and performance criteria, were not represented in this encoding schema.

Figure 2 provides a complete visual representation of the encoding of a single design document (problem description 2). One can see from the visual representation the large number of functions relative to other concepts. Solid lines represent function/sub-function or system/sub-system relationships. Dotted lines represent relationships between either existing solutions, new solution concepts, or specifications/constraints and functions. Existing solutions with an asterisk (*) are biological.

Fig. 2
figure 2

Visual representation of complete coding of problem description 2

Full size image

Data

We first present a descriptive account of how the design unfolded, followed by a quantitative description of the design documents, using the language of the problem schema. Both the descriptive account and quantitative analysis focus on the analogical problem evolution.

Descriptive Summary

The team began with the open-ended problem of sustainably generating energy for a house. After an initial meeting, the problem description document identified a range of types of sustainable energy—wind, solar, water, geothermal—discussing solutions such as wind turbines, photovoltaic cells, towers of liquid sodium heated through reflected light, chemical batteries, and storage of energy for later use using compressed air. The document also mentioned fat as a means of storing energy in biology. Cost was highlighted as a salient constraint on their design. The document discussed different places in which the current technologies were used: from coastal areas, to farms and cities; they also discussed relevant weather conditions, such as the amount of wind or sun, and extreme weather conditions. Performance characteristics were universally vague, of the character “more efficient” or “costs less.” Cost was the only constraint discussed but only in vague terms, e.g., noting that cost is a consideration.

The midterm documents discussed existing technological solutions of photovoltaic cells and coal plants. A wide range of biological sources were considered, including the desert snail, diatoms, photosynthesis, enzyme reactions, and the lotus leaf. Descriptions of the relevant functions of each biological source were provided; for example, the function of the desert snail is heat dissipation, which is performed by the structure of its shell. The midterm documents proposed solution-modifications to the photovoltaic cell, derived from each of these biological solutions. Thus, in the case of the self-cleaning lotus leaf, the documents proposed a self-cleaning photovoltaic cell. Solution proposals were little deeper than a function-structure pairing, none of which were (directly) developed further.

In the midterm documents, we noticed the addition of new functions, cleaning-self and dissipating heat, directly associated with biological solutions, and the dropping of other heat related functions, such as storing and directing heat, as the mirror/heat tower was dropped from the discussion. The environment, desert, from the mirror/heat tower solution remains in place, and is also related to the desert snail. Furthermore, we note the addition of the criteria “passively” connected to both functions attached to the biological solution. Manufacturing also is a rising concern, as the ability to reproduce materials and effects is highlighted.

At the third stage, the problem description continues its focus on solar panels and photovoltaic cells, and with all of the biological sources mentioned previously, except diatoms, which appear to have been dropped. Heat dissipation is discussed, but the design team now focuses on flexible, moldable and self-cleaning surfaces, derived again from the lotus leaf, and on a newfound perceived deficiency in current solar panels—rigidity. The environment under consideration shifted from a desert focus to an environment with greater temperature range, as well as the need to physically connect their solution to a home. Manufacturing nano-scale materials is again a manufacturing constraint, as well as the need for materials to be sustainable. There is also a shift in the problem focus from passive response to increased efficiency.

In the final design, the design team arrives at its first instantiated solution (in terms of conceptual rendering, shown in Fig. 3), which focuses on the functions of regulation and cooling, rather than self-cleaning and flexibility discussed heavily in the previous problem description.

Fig. 3
figure 3

Final design concept rendering

Full size image

The design team appears to have radically changed the problem, moving from photovoltaics to solar thermal collectors for water heating, which run the risk of overheating and damaging their internal structure. The new solution proposed is a dynamic feedback regulation mechanism from the enzymes discussed in the midterm, which is combined with a mechanism from a newly introduced biological organism, the tortoise beetle, which uses its color changing shell for camouflage. The designers intend to use a mechanism similar to that used by the shell of the tortoise beetle to alter the color of the thermal collectors to change the amount of heat captured, depending on the internal heat of the unit.

In this case study, the designers shift from the problem concepts of a self-cleaning, flexible solar panel to the concepts of self-regulating, cooling thermal solar collectors. While this appears to be a significant shift in the problem, we can see the incremental nature of the process. Using and managing heat has been embedded in the teams thinking all along, from the mirror/heat tower, to the desert snail, to the environment of the desert, to the concept of dynamically responding to the environment. These concepts were accreted into the designers’ problem schema from references to a number of solutions that were investigated along the way. When a new problem concept arose—overheating—the team was able to quickly pivot to the new problem focus and come up with a dramatic, creative solution.

Quantitative Summary

After coding the design documents, we analyzed the concepts represented in the problem schema, as well as references made to existing manmade solutions, biological solutions and new solutions. Table 2 shows summary statistics for function and specification/constraint concepts for each of the four stages, as well as the number of solutions at each stage. At this first level of description, some things already stand out. First, the number of functions considered at each stage remains between 20 and 25 until the final design, where it drops to 9. This seems to suggest that the designers were open to many possible combinations of functions for accomplishing their design objective, until the final design was instantiated. Second, the number of specifications/constraints is relatively very low, never more than 6. Of the 14 total, four were cost-related and three were sustainable materials related. Again, this seems to suggest that the designers wanted to maintain an open problem description as long as possible.

Table 2 Summary statistics, number of unique concept instances
Full size table

We observe that after a strong emphasis on man-made solutions in the initial stage, existing solutions references are rather evenly split in the next three stages, trending down slightly in the final stage. The number of new solutions discussed moves from one (the level of specificity for which was literally, “the new solution”), to seven—an explosion of independent solution ideas—back to a single final new solution in the end. While the trends in solution generation are not particularly surprising, we find the fact that designers consistently reference about the same number of existing solutions throughout the design cycle curious.

With respect to the number of functions, Table 3 considers the follow-through of each function from one stage to another. That is to say, did functions mentioned in earlier problem statements carry through to future problem statements? We see that from the initial generation of 25 functions, three of those functions carry forward into the Midterm, seven are considered in problem description 2 (PD2), and two (“generate energy” and “capture energy”) follow through to the final. Likewise 17 new functions appear in the Midterm description, one of which (“adjust flow”) appears in the final design. Fewer new functions appear in the third stage, just 10; of which 1 (“keep cool”) makes it into the final model. In the final stage, there are more new functions than old. Five new functions appear in the final problem description document, while four have been carried through from previous descriptions. This alone tells a very interesting story. In this ill-defined design problem context, we see a great deal of exploration. Fifty-seven unique functions are considered, only nine of which eventually make it into the final solution. Over 80 % of the functions considered are discarded along the way.

Table 3 Function concept carry over
Full size table

Solution Relationship Data

In this paper we will consider only one more level of detail in the data; the relationship of solutions to the concepts in the problem model, Tables 3, 4 and 5.

Table 4 Function concepts by solution reference
Full size table
Table 5 Specification/constraint concepts by solution reference
Full size table

For any concept in the problem model (function or specification/constraint), that concept may be associated with: (1) an existing solution, either man-made or biological, (2) a new solution, or (3) not associated with another solution. Tables 3, 4 and 5 show for each stage the numbers of function and artifact specifications respectively and whether they are associated with (1) an existing solution, (2) a biological solution, or (3) no solution. We note that the numbers in these tables may sum to be greater than the total number of concepts reported in Tables 2 and 3, as each concept may be associated with one or more solution category. For example if both a biological and a non-biological solution were mentioned with respect to a particular function, such as reflect light, we would get two tallies for that concept. Likewise multiple solutions in the same category could reference the same concept, for example two separate manmade solutions may have mentioned light reflection.

Table 4 shows the number of function concepts in the problem statement that referenced an existing manmade solution, a biological solution or had no reference to any existing solution. This table shows an interesting trend that provides insight into the process of biologically inspired design. Table 4 shows that the design team initially conceptualizes functions in their problem description largely (18 out of 29 references) in terms of existing manmade solutions. In the midterm stage, functions in the problem description are largely (12 out of 22) referenced in relation to biological solutions. This suggests that designers are re-conceptualizing their problems at least in part by identifying and transferring potentially useful functional concepts from biological solutions to their problem model.

In the third stage, manmade and biological solution transfers are roughly equivalent, while in the final stage, the point of design instantiation, about half of the functions discussed in the final problem description originated from existing biological solutions. In total, 65 % (60 of 92) of function concepts can be attributed to existing (man-made or biological) solutions.

The trend for specification/constraint in Table 5 with respect to existing and biological solutions is clear. Problem specifications and constraints, for example “must use sustainable materials,” are not associated with, at least not explicitly in this case study, other solutions. Many of the specifications were with regard to cost and sustainable materials, which were likely inferred from the design context of “sustainable housing.”

Summary of Analysis

Our analysis of the above data suggests that the design team broadly explored different aspects of the problem description; committing to few concepts rigidly, holding open possibilities until the right confluence of problem description and the descriptions of existing solutions emerge to form a cohesive pair. This finding is similar to Dorst and Cross [2] with one major difference: as opposed to generating early solutions to problems as they are formulated, our designers employed other, in particular analogical, strategies to generate problem concepts and enrich their problem descriptions. Our study is quite clear on this point; using analogies to existing design cases is a powerful way to formulate the design problem.

Designers appear to tentatively adopt problem aspects from existing solutions, in particular functional aspects, temporarily appending them to an overall problem description. What makes some concepts stay while others are abandoned is not yet clear from our data. We speculate that the early function-solution pairs seen in the design trajectory were evaluated and abandoned for lack of knowledge or manufacturing know-how. This suggests an evaluation-pruning function early in the design process. Another point is that in addition to solution analogy and solution evaluation, other methods are clearly at work enhancing the problem description. Analogical transfer accounts for at most 65 % of the new functions seen in this example, and for none of the specification/constraints. Analogical transfer seems to be limited in this case study to only certain classes of concepts.

Current and Future Research

This paper uses a simple problem schema to show the relationship between existing solutions and design problem conceptualization. To increase the value and reliability of these studies, we are currently validating a more robust problem schema and coding methodology using 37 problem description instances and standard inter-rater reliability. In addition, this new schema is being used to more thoroughly analyze a number of additional, semester-long case studies of biologically inspired design. In Fall 2011, the problem schema and theory developed here were deployed as a new pedagogical tool in the ME/ISyE/MSE/PTFe/BIOL 4740 class. Further, much as previous empirical findings [8, 12] informed the development of an interactive design environment called DANE for supporting aspects of biologically inspired design [11] this new schema is being used as the basis for an interactive tool that assists with problem evolution, analogy identification and evaluation, and solution generation. Helms [23] provides an initial outline of the new interactive tool.

Conclusions

The development of both design pedagogy and design technology depends on our understanding of design problems, products and processes. In this paper, we analyzed the process of the evolution of a problem in biologically inspired design from its inception through conceptual design. We draw two main conclusions from this work, one from the perspective of biologically inspired design and the other from the perspective of problem evolution in design in general. With respect to why and when analogies are used in biologically inspired design, we found that analogies are used for identifying, formulating, and transforming design problems very earlier in the design process. In addition, we have a partial answer to what is transferred; in this case study, we found that functions were transferred from biological designs to engineering problems, but specifications and constraints were not. Secondly, in the more general context of design as a whole, evolution of design problems typically is viewed as a co-evolution of design problems and solutions. Our analysis of the case study of design in this work suggests that significant problem evolution may occur independent of the generation of a new design solution for that problem, and that existing solutions to related problems serve as analogies that influence the way in which the problem is formulated.