Describing complex design practices with a cross-domain framework: learning from Synthetic Biology and Swarm Robotics

This paper reports on the development of a cross-domain framework for describing complex design practices. The framework is grounded in studies of two different complex design fields: Synthetic Biology and Swarm Robotics. In the first study, we interviewed practitioners in Synthetic Biology, identifying three essential aspects of complex design problems and practices. The first of these aspects is the characterisation of system complexity, the second is the design objective taken with respect to this complexity, and the third is the design approach applied to realise this objective. In the second study, we interviewed designers in Swarm Robotics, confirming the domain generality of the three aspects identified in the first study and permitting a comparison to be made of how the two fields differ from each other in these aspects. Considered together, the two studies provide the basis for building a cross-domain framework for describing complex design practices. Such a framework is presented here, not to exhaust all possible descriptions of complex design practice but rather to provide a structured yet adaptable way of highlighting the important aspects of these descriptions. Indeed, each aspect of complex design can be can be broken down into different elements depending on the design contexts under consideration. Having such a framework enables designers to identify fundamental similarities and differences both between and within fields.


Introduction
Practitioners and researchers in different engineering contexts have contributed many useful principles to guide the design, construction and control of systems.These principles typically generalise across domains and can be used to define the relationships between the structure, function and other properties of systems so that they relate to each other in favourable ways.For example, principles of modularity have been formulated, adopted and applied in product design and manufacturing (e.g.Ulrich and Eppinger 2003;Jiao et al. 2007), organisational design (e.g.Baldwin and Clark 2000) and software design (Sullivan et al. 2001;Sternberg 2011); they have also been applied in the network sciences (e.g.Newman 2006;Sternberg 2011).In recent years, design principles have started to be applied in fields outside of those traditionally associated with engineering, such as business strategy (Vinnakota and Narayana 2014), policy formulation (Bobrow 2006), crime prevention (e.g.Duarte et al. 2011), defence strategy (e.g.Tolk 2012), healthcare systems (Clarkson et al. 2004) and biology (e.g.Fu 2006).Many of these fields involve systems that are difficult to understand, predict or control, or are otherwise labelled as ''complex''.At the same time, emerging and converging technologies have increasingly blurred the boundaries between the principles and practices that apply to designed artefacts and those that apply to naturally occurring complex systems (Chen and Crilly 2014a, b).For example, distributed computer systems and the Internet have been studied as natural ecologies (Gao 2000;Forrest et al. 2005), and complex socio-technical systems are characterised as partially designed and partially evolved (de Weck et al. 2011).As such, design principles are being used to understand and modify a great variety of complex systems that have very different kinds of elements (e.g. physical, chemical, biological, human, social, logical), systems that have traditionally been the preserve of different fields (e.g.physics, chemistry, biology, psychology, sociology, computer science).
For a given complex design problem, the decision as to which principles and practices to adopt is determined by how the designer characterises (or ''frames'') the problem (Dasgupta 1989;Visser 2004;Dorst and Cross 2003).These characterisations are perspective-dependent and often influenced by the design fields that the problem is seen to belong to.This field-driven approach risks overlooking important similarities and differences.Similarities between complex design problems may not be easy to identify due to the fact that the problems involve systems with different kinds of elements (e.g.engineering a robot and engineering a policy).This can result in missed opportunities for sharing solutions.At the same time, important differences between complex design problems are not always recognised, simply because the problems involve systems with the same kinds of elements (e.g.engineering a robot to execute a well-defined task and engineering a robot that will robustly cooperate with other robots to accomplish some task).This can result in the misapplication of solutions where they do not apply, despite superficial similarities between cases.To address these problems, this paper develops a framework for describing complex design, capturing the essential aspects of designers' activities.The framework is based on interview studies with experts in two different fields of complex design: Synthetic Biology and Swarm Robotics.By grounding the framework in practices in these two fields, we develop a framework that is not tied to any single field.This allows us to observe similarities and differences within and between fields, providing a way to better identify opportunities for the appropriate sharing of complex design practices.

Complex design
Complex design problems are problems where the success of the design is entangled with the characterisation of the design problem itself.This might be because the requirements are highly sensitive to unpredictable contextual factors (e.g.designing new products utilising emerging technologies), or it might be because the relationship between the designed elements and the system properties is not well characterised (e.g.genetically engineering cells to produce some substrate).The practices and principles used to tackle such design problems may diverge from those used to address more well-established design problems, where a ''rational'' perspective is often assumed.This means that system elements (whether acting in isolation or in conjunction with each other) are well understood with respect to the roles they play in realising the system's functions (e.g.Yoshikawa 1985;Gero 1990;Pahl and Beitz 1996; also note that within the ''rational'' tradition, there still exist many different categories of design processes and paradigms, see Braha and Maimon 1997).While design principles across engineering domains might help to systematise thinking when approaching complex systems, traditional rational design approaches often fail to address the ''messiness'' of these systems.In particular, rational design approaches do not always produce solutions that are functionally viable when both the internal and external states of the system are changing, uncertain or poorly understood (Sheard and Mostashari 2008).For this reason, alternative design practices and models have been proposed, such as systemic design (Cross 1984), participatory design (Gaertner 1998), problem-solution co-evolution (Maher and Poon 1996;Dorst and Cross 2003).These design approaches have been fleshed out into useful methodologies for guiding designers' practice in various design contexts (e.g.Gaertner 1998).However, designers still require guidance as to when a particular methodology can appropriately be applied to a particular design problem, which in turn is dependent on appropriate characterisation of that problem (Dasgupta 1989;Visser 2004).
As well as the efforts in developing and refining complex design practices, there have also been attempts to identify, formalise and quantify the features of design problems that make them complex, e.g.''emergence'' (Braha and Maimon 1997;Johnson 2005;Braha et al. 2006;Maier and Fadel 2006;Bloebaum and McGowan 2010).This allows us to give more precise characterisations of how complex design problems differ from more traditional rational design problems or, in the case of quantitative characterisations, to treat terms such as ''complex'', ''simple'' and ''rational'' as a matter of degree.For practitioners working on complex design problems however, a more pragmatic characterisation of complex design is required that not only captures the extent of a problem or design scenario's complexity, but makes explicit the perspective taken with respect to it, which in turn drives practice.The field of Complexity Engineering aims to address this by establishing a set of principles for exploiting complexity in the design, construction or modification of systems to achieve particular behaviours (e.g.pattern recognition systems, optimisation systems) or change response behaviours with certain characteristics such as robustness or adaptability (Abbott 2006;Buchli and Santini 2005;Frei and Serugendo 2011a, b).The field faces two challenges: utility and generality.Although formal representations of complexity are domain neutral, their abstract nature means that they are not easily applied to real problems.For example, for a designer to be able to adopt the methods and techniques associated with pattern recognition, the designer first has to recognise that their problem is one that can be characterised as a pattern recognition problem, yet this is not always obvious.Efforts have been made to address this by relating Complexity Engineering principles to concrete applications (e.g.Buchli and Santini 2005), but it is not always clear how these solutions generalise to other design problems (Hirsch et al. 2001;Kuziemsky et al. 2009), in particular those involving very different types of elements (e.g.processes, material components) or belonging to very different design contexts (e.g. policy engineering, product design).Cross-domain generalisation is difficult to achieve because these concrete examples are described in domain-specific terms, overlooking opportunities to share practices.
To provide a useful basis for sharing design principles, methods and techniques within and across fields, we conducted qualitative interviews in two complex design fields.
In Study 1, we interviewed specialists working in Synthetic Biology and identified three aspects of complex design problems and the design responses that are associated with these.In Study 2, we interviewed specialists working in Swarm Robotics and developed a framework based on these three aspects to encompass both design fields.These two fields were chosen because they are very different from each other, representing something of the possible diversity of complex design practices.While Synthetic Biology was originally founded on rational design principles (despite the apparent complexity of biological systems), Swarm Robotics was founded on principles related to complex systems (despite the apparent simplicity of individual robot behaviours).For those readers unfamiliar with these fields, our report on each study is preceded by a statement on the background of the design field being considered, along with references that provide further information.

Complex design practice in Synthetic Biology (Study 1)
To better understand the problem framings and practices of complex design, we conducted interviews with practitioners in the complex design field of Synthetic Biology.

Background to the field
Synthetic Biology is a field that designs and constructs new biological parts, devices and systems, or that redesigns existing natural biological systems for useful human-defined purposes, in particular those concerning energy, health and the environment (Benner and Sismour 2005).Thus, Synthetic Biology is an applied research field that is inherently about design.Compared to other biological fields, Synthetic Biology is still very much in its infancy, but has quickly risen to prominence, attracting much excitement about its potential influence.For example, in a report by the UK's Royal Academy of Engineering in 2009, it was claimed that Synthetic Biology has the potential to transform industries and economies, generating great wealth and many jobs (RAEng 2009).Those wishing to learn more about the field and its more recent developments should refer to introductions already published (Andrianantoandro et al. 2006;Purnick and Weiss 2009), and the recent Nature issue focusing on the field (Nature 2014).Here, we focus on the design principles on which the field was founded.While many definitions of Synthetic Biology exist (Nature Biotechnology 2009), they have in common the core tenet of applying engineering techniques to biologically based parts, devices and systems.Synthetic Biology was founded on engineering design principles and was driven forward by individuals with engineering backgrounds moving into the biological domain.This design perspective is evident in much of the field's literature, with, for example, Endy (2005), Knight (2005) and Cameron et al. (2014) all proposing that the field adopts explicit engineering design principles to better realise its goals.Surveying the principles discussed in the literature reveals that they can be classified under three overarching themes: modularity, compositional hierarchy and standardisation (the latter two are aspects of the first but can also be considered independently).
• Principles relating to modularity have as their central tenet the idea that the system is assembled from a set of standardised, well-characterised parts.Modularity assumes both compositional hierarchy and standardisation but is often discussed without explicit reference to these principles (compositional hierarchy and standardisation can also be discussed without explicit reference to modularity).• Principles relating to compositional hierarchy are those that require parts to be systematically assembled into a whole to perform some function.In Synthetic Biology, these principles are based on the assumption that combinations of molecular parts map to predictable behavioural mechanisms such as toggle switches and autoregulatory negative feedback circuits.To support development of these mechanisms, engineering methods such as quantitative design, experimental measurement, and hypothesis-driven debugging are applied (e.g.Fu 2006).Compositional hierarchy also forms the basis of the assumption that even though cellular networks might be extremely intricate and complicated, they are organised as a hierarchy of functional modules, as in engineered systems.
• Principles relating to standardisation are those that require uniformity among entities of the same type.This standardisation might be applied to parts, assembly procedures or other practices (e.g.measurements, storage of data).For example, the standardisation of genetic parts, e.g. using the BioBrick format, permits more systematic and efficient assembly through welldefined interfaces, while the Registry of Standard Biological Parts (RSBP) permits an efficient way to retrieve such parts through standardising the data associated with them.(For more details on the BioBrick format, see http://biobricks.org, and to access the RSBP, see http://igem.org/Registry).
The literature on Synthetic Biology clearly points to the central roles of both compositional hierarchy and standardisation (or considered together, modularity) in allowing biological systems to be designed and constructed systematically, thus recognising the significant contribution of Engineering Design.However, the limitations of compositional hierarchy have been acknowledged with respect to biological complexity (e.g.Andrianantoandro et al. 2006;Kwok 2010;Agapakis 2014), challenging some of the fundamental assumptions of the field.As such, Synthetic Biology is positioned as a field with engineering origins, motivations and methods, but also as a field that is tackling complex design problems that are not entirely reducible to a traditional engineering approach.This is not discussed extensively in the published literature, and never with a view to understanding what other design fields might learn from Synthetic Biology.

Method and participants
Between November 2014 and March 2015, ten expert participants were recruited into the study with no restriction placed on their geographical location.Participants were selected for their background so that they collectively represented the interdisciplinary nature of Synthetic Biology design contexts.Video or voice calls were used if site visits were not possible.Before the interviews, participants were given a brief account of the purpose of the study.

Procedure
The interviews were conducted using a semi-structured protocol (Breakwell 2006), with each interview lasting between 30 and 40 min.The interviews focussed on both the design problems that the participants encountered in their own professional work and the design problems associated with the field of Synthetic Biology more generally (often, these overlapped).The interviews took a conversational form so as to accommodate and profit from the different perspectives taken by participants and permit flexible exploration of the topics that were deemed to be important by each of them.However, to ensure that the discussion still centred on design complexity in Synthetic Biology, these conversations were also guided by a common script, addressing four main themes: • How the participant's work fits into the field of Synthetic Biology as a whole (this was to put the participants' other responses in context and help understand the nature of the specific problems they were addressing).• The challenges faced by the participant in their work (this was to capture their characterisation of the design problem(s) they were facing).• The application of engineering and design principles in Synthetic Biology (this was to determine the perceived contribution that Design had made to Synthetic Biology).• The extent to which Synthetic Biology might be able to contribute back to the engineering fields which first inspired it (this was to identify any principles, methods or techniques used in Synthetic Biology that could be generalised to address complex design problems in other fields).
With the participants' consent, interviews were recorded using a digital audio recording device.All audio recordings were then transcribed verbatim (totalling approximately 29,000 words) and augmented with descriptions of any visual materials presented during the interviews (e.g.pictures, books, objects).Transcripts were imported into qualitative data analysis software (ATLAS.ti) to permit the iterative coding process associated with a general inductive approach (see Braun and Clarke 2006;Thomas 2006).They were then coded by two researchers, one of whom was not directly involved in the interviewing process.The first coder had a background in computer science and complexity science; the second coder had a background in mechanical engineering and design research. 1Both coders used the same iterative coding process to arrive at their own set of themes; examining the differences between the researchers' coded transcripts permitted the identification of additional themes and alternative interpretations of the data.After several coding cycles, the analysis had stabilised on the main themes and sub-themes that are presented in this paper.Although the analysis was conducted on full verbatim transcripts that reflected pauses, broken sentences and repetitions, the quotations provided here are edited for clarity, removing repetitions, pauses and false starts.

Participants
In our sampling, we covered the different ''input domains'' (domains which have influenced the field) identified through reviewing the literature, namely chemistry, computer science, molecular biology, engineering and physics.All of our participants held doctoral level research degrees (e.g.PhD), with four or more years' experience in the field.The majority of participants worked in research organisations, but two worked in commercial organisations (see Table 1).

Describing complex design in Synthetic Biology
When analysing the participants' descriptions of the challenges they encountered in their work, we identified three distinct aspects of complex design practice: • Characterisations of complexity the ways in which complexity is identified, considered and represented (e.g.unpredictability, emergence, incomplete understanding); • Design objectives the goals that are adopted with respect to complexity (e.g.avoiding it, exploiting it); • Design approaches the methods that are employed to realise the design objectives (e.g.simplifying the problem, experimentation, exhaustive search for solution).
Each of these aspects of complex design practice is detailed in the sections below.

Characterisations of complexity
When describing the complexity of their design problems, participants emphasised different ways in which that complexity was manifest.In total, eleven distinct characterisations could be discriminated, each of which is outlined below.
• Unpredictability is where behaviour of the system elements or the system itself is not completely predictable.For example, the system may not operate as expected, even if those expectations are held by an expert: ''The thing about biology is that you have to get used to things not working on a daily basis, so it [the designed system] doesn't work most of the time'' (SB5).• Noise is where functionally significant behaviours are only being partially realised or failing to be realised due to relatively small disruptions.For example, a few molecules might prevent the system from functioning as expected: ''You've got to actually treat it as a small group of molecules with a large amount of noise in their behaviour'' (SB5).• Emergence is where properties of the system are nontrivially related to the properties of the elements.For example, interactions between biological entities give rise to the system's ability to reproduce or maintain energy balance in a particular environment: ''You have all the different components and then under this equilibrium condition they come together and collectively exhibit these collective properties and then a system has a certain number of properties, say, the ability to divide into offspring, into daughter cells, it can maintain energy balance, and we call it a living system'' (SB7).• Stochasticity is where behaviour of the system's elements or the system itself is probabilistic.For example, disruptions to the system can occur randomly: ''The stochastic noise of the system is much higher so it becomes more of a statistical science'' (SB10).• Non-linearity is where the magnitudes of various behaviours in the system are related to each other in disproportionate ways.For example, a given size of input can result in a disproportionately large output: ''If you are deterministic and linear, when you double the input to your system, you double the output; when you triple the input, you triple the output, that's it.With non-linear, it's nothing like that!'' (SB1).• Cross-talk is where there are many interactions between elements and they may interfere with each other.For example, multiple interactions can result in non-straightforward mappings between input and outputs: ''… there doesn't have to be a neat mapping from the input to the output.It can be tangled up and hidden in all the weighted interactions between the nodes, and I'm afraid that an awful lot of biology is like that'' (SB5).• Open systems characterisations are those with system boundaries that are in flux with the ''environment'', and elements can appear to be (at the same time) part of the system and part of that system's environment.For example, feedback loops can be partially open to the environment: ''… most metabolic pathways in cells are genetically regulated in a feedback structure that involves some open structures…'' (SB1).• Overlapping hierarchies are characterisations in which elements can be described at different levels when considered in the context of different systems.For example, molecules can belong to different ''devices'' or systems and hence interact with other molecules that they are supposed to be independent of, resulting in non-encapsulation: ''The idea on which iGEM is based, this Lego building block idea that you can take individual components, abstract them into devices and abstract those into systems and you don't have to worry about how things are being implemented at the level of individual molecules so that you can just design at the system level… this idea that you can form such an abstraction hierarchy is just flawed'' (SB5).2• Incomplete understanding is where the system's properties, behaviour and/or structure is not fully characterised with respect to the required functions.For example, there may not be a complete understanding of the system's elements: ''The biggest problem that we encounter is that a lot of the modules we do use are either not terribly well-characterised or not even terribly well understood.It's like trying to engineer what's inside a black box…'' (SB10).• Multiple characterisations of the system can mean that the relationships between different representations, descriptions or models of the system are not fully understood.For example, the relationships between the different models of a given system may not be well characterised even though they overlap: ''We build models for design, for analysis or for computational simulations which are numerically accurate.Most of the time, these three aspects are individual models, although they may overlap…'' (SB1).
The characterisations of complexity summarised above were sometimes combined by the participants to give a more precise characterisation.In addition, the participants were aware of relationships between these characterisations.For example, unpredictability was attributed to emergence: ''For me, a 'complex system' is a system whose behaviour is difficult to predict, a system where you have emergent properties.You have components but the global behaviour is not the sum of the single behaviours'' (SB2).The identification of such relationships between characterisations suggests that participants were themselves sensitive to the fact that complexity can be viewed from different perspectives.

Design objectives
In describing their design challenges, the participants not only characterised complexity in different ways, they also expressed different attitudes towards that complexity.This resulted in their holding different design objectives.Broadly speaking, three kinds of design objective could be distinguished: • Design to avoid complexity effects.For example, elements can serve to prevent interference between other components: ''The ribozymes are insulators and so we've started using those a lot'' (SB10).• Design to compensate for complexity effects.For example, additional interactions can be built into compensate for the effects of other interactions: ''OK, instead of engineering, perhaps we can predict what this interaction will be by looking at the sequence.Rather than removing the context dependency, you can have a biological model that tells you what the context dependency will be so that you can account for it when you engineer'' (SB3).
• Design to exploit complexity effects • for performance (or efficiency).For example, the fact that a biological entity or process can serve multiple functions at the same time can be leveraged to make the system more compact or efficient: ''[in electrical engineering], when current flows into one wire there is no impact on the other wire… If we didn't have this constraint, we could miniaturise [electrical systems] a lot more'' (SB1).• for robustness (or sustainability).For example, cooperative interactions might be encouraged so that the elements mutually sustain each other (codependency) and hence the system: ''… one of the interesting things going forward is when people come up with better toolkits of parts that are more reproducibly different and people start to learn how to make a group of cells co-dependent and therefore exist together'' (SB5).
The design objectives outlined above are neither exhaustive nor mutually exclusive.Participants sometimes adopted more than one objective, and some participants did not mention design objectives at all (see Table 4 in Sect.4.3).Indeed, for a given design problem, it might well be that one design objective is taken with respect to complexity effects in one part of the system (e.g.trying to avoid unwanted interactions), while another objective is taken with respect to another part of the system (e.g.trying to exploit interactions to give rise to desirable higher level properties).It should also be emphasised that for a different group of participants, different design objectives might be identified.For example, while performance and robustness were the only two system properties explicitly mentioned by participants in this study, they do not exhaust the list of system properties that are sought through exploiting complexity.Others, such as adaptability, resilience, evolvability, and other ''-ilities'' might also serve as goals when exploiting complexity effects (see also Table 4 in Sect.4.3).

Design approaches
The different design objectives that the participants held were realised in different ways.Different approaches were adopted, involving the application of different methods.These approaches can be broadly classified as ''rational'' or ''black box'', but further distinctions can be made within these broad categories.
• Rational design approaches include: • Applying simplifying principles that might allow complexity to be rationalised for certain aspects of the system or subsystems.For example, key factors determining system behaviour may be identified while others are ignored: ''The trick, what makes or breaks a study, is deciding which details to keep and which to get rid of… experience has shown that there are some details that you can ignore if you want to study certain properties'' (SB7).• Learning through designing and making experimentation integral to the process of designing or constructing the system.For example, biological devices might be tested in different contexts to get a better understanding of the interactions between system elements: ''… that's something that you would describe as systems biology, where you're trying to take a system and understand it, but it's relevant to Synthetic Biology because in any biological system we have incomplete knowledge of the host system'' (SB5).• Integrating multiple characterisations so that information about the system and its elements from different sources (possibly also from different domains) about the system are integrated and can be searched when designing.For example, computational tools can be used to exhaustively search digitally stored information about a system and identify a set of designs that fulfil certain constraints: ''They've developed a computer program that takes as inputs the circuit you want to build and the input and output ranges for the sensors serve as inputs to the system, and the computer program will then search through the library of transcription factors that we've characterised and assign them based on the logic and behaviour of the sensors and the other transcription factors.It'll basically rationally engineer the system for you'' (SB10).
• Black box design approaches include: • Adaptive design with well-defined requirements, often expressed as quantitative constraints or parameter ranges.For example, machine learning techniques might be used to find designs that achieve optimal levels of certain chemicals: ''Now if you pose the problem in reinforcement learning terms, where there are certain things you can measure in the blood which are your output, and your input is the drugs you put into the system, you can ask the reinforcement learning algorithm to optimise a certain parameter that is linked to the desired health status'' (SB1).• Adaptive design with poorly defined requirements, often expressed as high level qualitative design requirements which might themselves be highly context dependent or subject to change.For example, directed evolution can be used to find designs that work well in a particular environment: ''… we can try to start doing directed evolution, where we make random mutants in the system and hope that the performance of the system improves.And if that's the case, then we just go with that'' (SB10).
The distinction between ''well-defined'' requirements and ''poorly-defined'' is really a matter of degree rather than of kind.In the case of well-defined requirements, it is clear what the goals of design are (e.g.maximise speed).In the case of poorly defined requirements, they are dependent on multiple properties of the system (e.g. increase robustness), subject to change depending on the environment (e.g.satisfy customer), or expressed more vaguely (e.g.improve quality).
As with the different design objectives, some participants adopted more than one of these approaches and even combined both rational design and black box approaches (see Table 6; SB5, SB8 and SB10 adopted both rational and black box approaches).Finally, although the approaches outlined above are described in designer-centric terms, they can also be considered in terms of how the design space is explored.

Describing complex design
In the study reported above, complex design was represented not as a single unified approach but as a set of related perspectives and activities.Three aspects of complex design were identified: constructing a certain characterisation of complexity, adopting a certain objective with respect to that complexity and exercising a certain design approach with respect to that objective.Further distinctions were then identified within each of these aspects.We identified eleven (overlapping) characterisations of complexity (unpredictability, context dependency, noise, emergence, stochasticity, non-linearity, cross-talk, open systems, overlapping hierarchies, incomplete understanding, multiple characterisations); three high level design objectives (design to avoid complexity, design to compensate for complexity, design to exploit complexity); and two broad approaches (rational and black box).The different aspects and distinctions described above are not exclusively framed with respect to Synthetic Biology or any other field, but are instead presented in a domain-neutral way.This allows practices in other complex design fields to be considered in these terms, without becoming distracted by the kind of system involved (e.g.physical or biological) or the domain knowledge that is being applied (e.g.physics or biology).

Complex design practice in Swarm Robotics (Study 2)
To test the domain neutrality of the aspects identified in Study 1, and to further explore the possible distinctions that relate to each aspect, a second study was conducted on a different complex design field, Swarm Robotics.

Background to the field
Swarm Robotics is the study of how robots with limited capabilities with respect to a task or with simple individual behaviours can be designed so that they accomplish a task together as a collective through coordinating their behaviour, or exhibit a particular behaviour as a collective (Iocchi et al. 2001;Dorigo and Sahin 2004;Winfield et. al. 2004;Sahin 2005;Bayindir and Sahin 2007;Brambilla et al. 2013).As is the case with Synthetic Biology, different definitions of Swarm Robotics exist, but there are two main requisites.
Firstly, the individuals need to be autonomous physical robots situated in an environment and able to modify it in some way.Secondly, the capabilities of the individuals should be limited with respect to the task they need to accomplish as a collective, e.g.sensing and communication restricted to a limited ''local'' range, actions restricted to nearby objects.The second of these requirements also implies that control is distributed rather than centralised, and that cooperation and coordination may be necessary to accomplish a task.Usually, the solution sought should be scalable and work for any number of robots so that coordination does not break down when the number of robots is very large (Sahin 2005).The two requirements imply various principles associated with Complexity Engineering, which can be classified under two main themes: emergence and distributed control (these are themselves inextricably linked but can also be considered independently).
• Principles relating to emergence centre around the idea of element-level behaviour giving rise to system-level behaviour in non-straightforward ways.For example, unreliable local behaviours can give rise to robust system-level behaviours, or simple local behaviours can give rise to highly flexible system-level behaviours.• Principles relating to distributed control centre around the idea of systems having non-hierarchical control structures, i.e. structures where there is no ''overall'' control or ''leader''.This means that the behaviours and decisions that are exhibited at the system level come about through the collective actions of the system's elements.
Swarm engineering, the application of Complexity Engineering to Swarm Robotics, takes a more rationalised design approach to Swarm Robotics.This involves systematically applying ''scientific and technical knowledge to design, realise, verify, validate, operate, and maintain a swarm intelligence system'' (Brambilla et al. 2013) so that the swarm will predictably and reliably behave in the way the designer intended (Winfield et al. 2004).This engineering approach is often (but not always) the one taken in Swarm Robotics, perhaps because many practitioners come from backgrounds in engineering-related fields (in particular, Computer Science) or fields in the physical sciences.As in the case of Synthetic Biology, the difficulties encountered when designers apply established practices, methodologies and methods are rarely discussed in the literature.

Method and participants
The recruitment process and interview methods for Study 2 were identical to those for Study 1. Interviews took place between May 2015 and August 2015, and the themes of discussion were the same as those of Study 1.The interview duration for each participant ranged from 30 to 40 min, resulting in approximately 26,000 words of transcripts, which were again subject to analysis by the same coders.However, in this study, that analysis was conducted in terms of the three aspects of complex design practice that were evident in Study 1. Study 2 was thus partially comparative in nature, rather than employing an entirely inductive approach.
The participants were all expert practitioners in Swarm Robotics.The majority had educational backgrounds related to computer science or electrical engineering, reflecting the nature of the field, although one (SR10) had a predominantly biology-based background.All of the participants held doctoral level research degrees (e.g.Ph.D.), with four or more years' experience in the field.The majority worked in research organisations (see Table 2).

Comparing complex design in Swarm Robotics and Synthetic Biology
As in Study 1, the participants gave descriptions of their complex design problems and practices in terms of characterisations of complexity, design objectives with respect to this complexity, and the design approaches adopted or attempted.Also, as in Study 1, they made distinctions within each of these three aspects of complex design.Many of these distinctions overlapped with those identified in Study 1, but some did not, revealing differences between the two fields.These differences are reported below.

Characterisations of complexity
While many of the characterisations of complexity overlapped with those of Study 1, there were also discrepancies.
In particular, the Swarm Robotics participants did not mention open systems, overlapping hierarchies or multiple characterisations.On the other hand, the following additional characterisations were evident in the transcripts (see Table 3).
• Hidden heterogeneity among components is when components are assumed to be equivalent but they still exhibit differences that affect system behaviour.For example, small differences between robots can lead to unexpected behaviour and nonlinear effects (see nonlinearity above): ''Even though they are apparently identical robots [in the swarm], they will be different because the wheels are not lined up quite perfectly, the gearboxes are not identical, the sensors are slightly different… Those small heterogeneities act like nonsystematic noise… Bearing in mind that the emergent behaviour arises from the sum total of all the micro- interactions between the individuals with each other and with their environment, you can think of it as a chaotic system where a very small difference might get amplified'' (SR1).• Distributed control is where there is no global control or ''leader'', but the system still manages to exhibit behaviour that is coordinated in some way despite components being largely independent and only interacting locally.For example, individual robots might have quite modest capabilities and access to information but can coordinate to accomplish a task: ''… each robot is quite dumb, so not very intelligent and not able to do very much by itself.But then if you put hundreds or thousands of them together, they can perform tasks, like moving objects, identifying the source of pollution, and so on'' (SR7).• Sophisticated components can mean that there is greater indeterminacy at the component level and in component interactions.This can then result in a greater range of possible behaviours at the system level and make the system difficult to analyse and predict.For example, adding extra capabilities to robots can mean that more responses are possible or that more information is involved in interactions between robots, making the system more difficult to analyse: ''… if you add extra sensors or extra capabilities, it tends to make the whole thing very hard to analyse…'' (SR3).• Uncertainty in the environment means that the system needs to adapt to change.For example, biological organisms often reside in highly dynamic environments: ''At the system level, I think we are very far from the performance of biology, especially when you consider the environment that needs to be adapted to'' (SR7).

Design objectives
As in Study 1, participants referred both to design efforts to compensate for complexity and to efforts to exploit complexity.In the case of designing to exploit complexity however, participants in Study 2 did not mention exploiting complexity to attain greater robustness.On the other hand, several participants sought to use complexity principles to produce systems with rich, sophisticated behaviours.For example, individuals with access to only local information can work together to build large complicated structures: ''It's an incredible proof of principle that you can have these large numbers of agents all acting independently only on their own information, working together to build these large-scale complicated things'' (SR11).In contrast to the participants in Study 1, none of the participants mentioned designing to avoid complexity (see Table 4).

Design approaches
As in Study 1, the Swarm Robotics reported using both rational design approaches and black box approaches.An additional approach was introduced within the rational design category, which involved distributed design by crowd-sourcing the generation of solutions, leading to a more exhaustive search of the solution space than could be achieved by a single expert designer or design team.Individuals outside of the field were recruited and given a Non-linearity ??
Open systems ?
Uncertainty in the environment ??
The number of ''?'' symbols indicates a count of the number of participants who included the characterisation of complexity in their description of complex design practice brief introduction to the design problem and the properties of the components so that the solutions they generated were informed by some knowledge of the field (see Table 5).

Comparing complex design practices
In study 1, through interviews with specialists in Synthetic Biology, we identified three aspects of complex design, within which we identified further distinctions.In Study 2, through interviews with specialists in Swarm Robotics, we confirmed the cross-domain applicability of the aspects and again identified further distinctions within these aspects.By combining the distinctions identified in the two studies, we are able to develop a framework for complex design practice which spans the two fields (see Table 6, left-hand column).Applying the framework to our participant data from both studies illustrates the similarities and differences in complex design practices (see Table 6, grid).For example: • When characterising complexity, practitioners in Swarm Robotics placed more emphasis on distributed control than did practitioners in Synthetic Biology, reflecting how robots are more directly controlled.In contrast, practitioners in Synthetic Biology placed more emphasis on context dependency than did practitioners in Swarm Robotics, reflecting the sensitivity of biological entities to environmental factors.
• In terms of design objectives, practitioners in Swarm Robotics tended to place more emphasis on exploiting complexity effects, seeking to master complexity so as to achieve richer behaviours that allowed the system to accomplish sophisticated tasks in different contexts.In contrast, practitioners in Synthetic Biology tended to be more conservative with respect to complexity, wishing to avoid or compensate for complexity effects.• With respect to design approaches, practitioners in both fields saw learning as an inherent part of the process of designing and achieved a better understanding of the systems they were working on through designing them.
Practitioners in both fields also used black box design approaches as a means of addressing complexity by tractably searching the vast solution space.
It is also worth noting that not all of the participants made reference to all three aspects of complex design problems.For example, participant SB9 and participant SR6 did not explicitly discuss the complexity of their design problems and hence did not give any characterisations of complexity.Such gaps can be used to stimulate further questioning when using the framework to identify potential points of overlap and difference between different design contexts: Is the non-mention of these aspects a deliberate omission that indicates an openness to the different possibilities (e.g. the solution might require both avoiding and exploiting complexity) or is it that one of the elements is assumed and not explicitly stated (e.g. it is Compensate for ???
For robustness ?
The number of ''?'' symbols indicates the number of participants who included the design objective in their description of complex design practice Learning through designing ????????
Distributed design ?

Black box
With well-defined requirements ????
The number of ''?'' symbols indicates the number of participants who included the design approach in their description of complex design practice assumed that the solution requires the avoidance of complexity, but the participant does not explicitly say this)?Moving beyond the two fields studied in this paper, the framework provides a basis for describing other complex design practices without the need to refer to the detailed nature of the system's entities (e.g.whether they are biological or robotic).Having such domain-neutral descriptions allows one complex design problem and its associated practices to be compared with those from another field, even when this other field deals with systems consisting of very different kinds of entity.This permits those working on the same complex design problem to recognise that they are characterising the problem in different ways, preventing the development of incoherent or poorly coordinated solutions.For example, one designer might be working to optimise an outcome based on the assumption that it is a well-defined requirement, while another designer might be seeking a solution where this outcome is only one of several possibilities which serve as alternatives to deliver some other less well-defined or higher level requirement.Without recognising this discrepancy, the two designers might develop solutions that are inconsistent with each other.At the same time, by allowing design practices to be described in a way that is independent of issues that are tied to a specific domain or context allows points of overlap to be more easily identified and knowledge to be shared.For example, a designer wishing to apply simplifying principles to a particular complex design problem might be able to find techniques for doing this which have been developed by another designer working on a problem in some other design context.Identifying such opportunities for sharing knowledge and highlighting mismatches in practices prevents efforts being duplicated or misaligned when addressing complex design problems.

Discussion and conclusions
This article reports on two interview studies to develop a practice-grounded cross-domain framework for complex design.Unlike existing work on characterising complex design, the framework is not intended to provide a formal or objective characterisation of design complexity.Rather, it emphasises the different subjective perspectives that can be adopted when practicing complex design.This provides a basis for identifying the essential elements of complex design practices in different contexts.Our framework could not possibly represent all the possible ways in which complex design can be described, but it does provide a structured yet adaptable way of highlighting the important aspects of these descriptions.Indeed, while the three aspects of complex design are domain neutral, which distinctions are included under each aspect of the framework might depend on the design contexts under consideration.This was demonstrated by using the framework to identify commonalities and differences in the descriptions of complex design practice in the two fields studied.For example, we found that practitioners from the field of Swarm Robotics made frequent references to distributed control in their characterisation of complexity while distributed control was not mentioned by any of the practitioners from Synthetic Biology; on the other hand, practitioners from both fields saw learning as part of the process of designing and derived a better understanding of their systems through designing them.Commonalities and differences were also identified between different individuals within the same field.The framework thus allows the underlying relationships between complex design practices to be identified.
The work reported here has focussed on establishing the basic components from which descriptions of complex design practice can be constructed.A longer term endeavour would be to determine which complex design profiles are most common, i.e. which elements of the framework tend to occur together and whether there are trends in the ways complex design problems and practices are described in different contexts.It might then also be possible to relate such trends to specific features of the design context, such as the nature of the system entities (whether they are material components, people, processes organisations, or some combination of these) or the domains drawn from when addressing them (e.g.biology, physics, sociology, psychology).Identifying such associations would provide the basis for matching complex design practices with the types of design problems they are best suited for, even when these design practices come from domains or contexts that are not obviously related to the problem at hand.In doing so, different complex design fields could be improved by learning from each other with respect to those practices that can be meaningfully shared between fields despite superficial differences.
• Context dependency is where elements behave differently depending on which other elements they are interacting with.For example, a biological device working in one type of environment but not in a different type of environment: ''What might work in one cell type or with one pathway or one environment or context won't work in another'' (SB7).

Table 4
Different design objectives sought by participants in the two studies