Keywords

1 Introduction

Collaborative design is a creative and complex domain that faces multiple challenges today. Designers regularly define and/or frame the problem, they adopt holistic thinking, and they sketch, draw, and model possible ideas throughout the design process [1]. Specifically, collaborative design is an activity that requires participation of individuals for sharing information and organizing design tasks and resources [2] and it is a process of managing multiple perspectives [3]. Most architectural projects involve large numbers of participants that design and produce together a complex object that is one of a kind. Often, participants do not work together regularly, as teams are organized on a project basis [4]. As Kvan [5] points out, design collaboration requires a higher sense of working together in order to achieve a creative result. It is a far more demanding activity than simply completing a project as a team. Especially when dealing with a multidisciplinary team, the lack of shared understanding reduces the quality of the final product [6]. What is more, it is critical for geographically distributed designers, through remote collaboration, to accurately perceive other team members’ activities with a high level of awareness as if they were working in the same room [7]. In addition, designers must work fast, as competition in the marketplace drives short design cycles and are expected to constantly challenge the limits of known solutions and venture into unknown territories [1]. In this context, a collaborative architectural design process is generally difficult to generate and maintain, especially in an environment consisting of large teams, short deadlines and long distance. Thus, it seems interesting to understand how collaborative design methodologies can help designers form a collective intelligence that would be able to face ever-shifting challenges. This paper is based on an empirical analysis of a single case study involving a multidisciplinary team that competed in an international architectural idea competition with over 1700 entries and that received an award. The main objective of the current research is to make the first step towards identifying a systemic methodology that allows fostering collective intelligence. The question of the research is: how does a large multidisciplinary team harness collective intelligence in order to design an architectural project in a constraining spatiotemporal situation? The challenge gave rise to a Collective Intelligence Support Protocol (CISP) for architectural design, based on a systemic approach. This tentative starts from the assumption that collective architectural design is a highly complex system that consists of a multitude of elements linked together by interdependencies. A systemic approach is methodical, repeatable and learnable through a step by step procedure [8], clarifying the interdependencies of the members in a collaborative project [5]. Through the formal description of the CISP the present research seeks to understand the structure and the macro behavior of a system through its internal sub-models.

2 Collaborative Architectural Design System

The definition of a system can have several hues. For the aim of this research, it is useful to remember that a system can be defined as a set of two or more elements where: (i) the behavior of each element has an effect on the behavior of the whole; (ii) the behavior of the elements and their effects on the whole are interdependent; (iii) and while sub-groups of the elements all have an effect on the behavior of the whole, none has an independent effect on it [9]. Additionally, groups or organizations are dynamic systems, adapting and evolving with their multiple parts that interact with one another and with the environment [10–12]. Indeed, as collaborative design process complexity continuously increases, design has to integrate a great number of expertise [13] and using systems concepts offers a way of rationalizing aspects of existing practice and of suggesting directions for improvement [14–16]. In fact, systems theory can be summarized as a knowledge framework that focuses on structures, relationships, and interdependence between elements [17]. Furthermore, design context is project-based, defined considering time product, process aspects, and also the human, social and organizational aspects [18]. Within collaborative design, agents gather around a common objective related to an architectural project, in order to exchange information and share knowledge, with high-level coordination activities. In system theory, these elements of purpose, interdependencies, structure, techniques and information must be coordinated and integrated by the managerial system, in order to maximize value for the organization [11, 19, 20]. The previous observations suggest that the collaborative design process can be seen as a dynamic system in which involved agents form an organization with a common objective, exchanging information and sharing knowledge with high levels of coordination, by focusing on structures, relationships and interdependencies. Besides, organizations can be understood in terms of their decision process [21] and supporting it facilitates more effective group interaction, leading to greater decision-making effectiveness [22, 23]. Historically, the concept of decision support system emerged in the 1970s when it was proposed for models providing assistance in dealing with semi-structured and unstructured problems [24–26]. In this regard, collaborative design is a term that denotes more than just cooperation or coordination. In cooperation participants do not have a common goal but rather work together to achieve mutual benefits [4] through informal relationships [5, 27]. Coordination consists of more formal relationships as well as a structure of compatible missions. It requires division of roles, some planning and the establishment of communication channels [27]. However, collaboration occurs when several agents are working together in a planned way in the same production process or in different but connected production processes [28]. In collaboration, the common mission is the bounding element to which participants are committed [5]. Therefore, agents may share fully or partially overlapping goals and coordination is needed in order for them to work together harmoniously [29, 30]. Hence, within the general structure of collaborative design process there are interdependencies between collaborative and cooperative moments, which are organized in an alternating chain from the first sketch to final render.

Continuity between these moments, as well as teamwork efficiency, require an element that can be identified as “collective intelligence”. The term defines the capacity of groups of individuals to act collectively in ways that seem intelligent in regards to certain objectives [31]. Furthermore, in order to organize the design process, the collective intelligence could be associated with the ability of the agents group to work with each other, with subsystems as well as with the main system. The research seeks to develop a methodology that supports collective intelligence in the architectural design process.

3 Collective Intelligence Support Protocol (CISP)

The general idea of the CISP sparked from several initial hypothesis regarding collaborative design in architecture [32]. The aim is to support collective intelligence in order to generate a shared architectural design and to provide managerial structure in response to spatiotemporal constraints. Specifically, the CISP seeks to: (i) create an organizational structure within the team, assign specific roles to members by defining the set of relationships between sub-systems, (ii) plan phases and deadlines for the design process timeline, (iii) configure a shared workspace for exchanging ideas (both online and offline) and for supporting collective decision making, (iv) develop a common ground between team members, (v) maintain the necessary adaptability throughout the collective design process. The CISP sees collaborative architectural design as a system of interconnected sub-systems (e.g. team members, layers), interacting with each other and with the system in which they operate, in order to create and produce a common architectural project. The methodology operates on three layers of the teamwork: organization, planning and shared work space. By working with each layer individually and by connecting them between each other, the CISP can respond simultaneously to management and creativity issues in architectural design.

The CISP methodology has been progressively developed in parallel to the case study and has resulted into the formalization of the three layers, based on continuous empirical feedback from team activity.

3.1 Organization Layer

The organization layer assigns specific roles and types to team members, generates a set of relationships and creates sub-teams. The structure is created through collective decision and can be continuously adapted throughout the design process. It is used to implement the planning of the design process and to construct the shared workspace. Using a systemic approach, when the architectural project is identified, a number of functionally specific and modular system components can be developed. This decomposition allows each agent (or sub-team) to use its best knowledge for solving a particular problem. In the organization layer, agents need to coordinate and collaborate with one another to ensure that interdependencies are properly managed.

Within the case study, team members were initially selected to cover all the particular aspects of the design theme. Each agent’s background was scanned to define their member type and role in order to manage interdependencies within the team. Team types and roles created a shared awareness of the potential interactions between members as well as of individual production capacities in order to avoid the polarization of viewpoints and the incapacity of a group to create a joint basis for communication and action. Firstly, the following member types have been defined: (i) the Designer is the agent involved in the development of the project idea, proposing new design alternatives; (ii) the Researcher explores and provides knowledge to support the team’s design process; (iii) the Consultant is the agent who delivers expert advice and specialized information in a particular topic; (iv) the Producer is the agent member of the team that produces parts of the project render, based on the collaborative decision. Secondly, the role distinction between coordinator and member creates a hierarchy decomposition that distributes responsibilities, decisions and tasks. In particular: (i) the (Overview) Coordinator is responsible for promoting the project and managing all the activities relating to his/her agency, in order to achieve the previously set objectives; (ii) the Member agent is part of a specific team and produces information relative to its targets. To support the design process, the organizational layer of the protocol implemented a dual layout: vertical and horizontal. The horizontal organization layout encouraged creative interaction (Fig. 1) (i.e. designing, project decision-making). Each member had the same decisional legitimacy and collaboration methods and tools were used to channel team activity towards a common architectural project. On the other side, the role of the vertical organization layout was to maintain design process efficiency (Fig. 1). Members’ distribution into sub-teams created task dispersion and simplified objectives for each team as well as for its members. Every team had a dominant role in a corresponding phase of the planning layer. The type attribute that has been assigned to each member referred to their background but also to their possible contribution in the team (Table 1). Moreover, team members were distributed into four teams and each team received a leading role in decision-making throughout the timeline of the design process. Three of the four teams cover the main tasks of a design process: research, exploration and production (Table 2).

Fig. 1.
figure 1

Horizontal layout (left) and vertical layout (right) of the team in the case study

Full size image
Table 1. Team members’ background, type and role
Full size table
Table 2. The four teams of the competition
Full size table

3.2 Planning Layer

The planning layer distributes team activity throughout the time frame of the design process. As an evolution from first sketch to final render, planning is used to create temporal sequences that prioritize tasks. Temporal particularities may also have an impact on the organization and shared workspace layers. At a detail level, the planning layer distributes team activity into a chain of alternating collaborative and cooperative moments. They use horizontal and vertical organizational layouts and ensure a continuity of articulation from one phase to the other. Collaborative moments are associated to synchronous distance or in-presence meetings while cooperative moments are linked with asynchronous meetings or individual work.

Within the case study, the planning layer consisted of three phases corresponding to the three teams: research, exploration and production. The goal of each phase was the same as the goal of the corresponding sub-team (Table 2). During a particular phase, all team members worked for the same tasks while the leading team carried the responsibility for delivering the necessary output. As a consequence, interdependencies between members changed over time, as leading teams rotated from one phase to the other. Furthermore, design theme specificities established the time attribution per phase. However, research and exploration phases overlapped almost completely while exploration and production overlapped much less in the process timeline. Hence, design process has been focused significantly more on idea development (research and exploration phases) than project production.

3.3 Shared Workspace Layer

The shared workspace layer provides team members with the necessary framework where the interactions take place in order to produce the project. It seeks to support common knowledge between members, build a common set of work and communication tools as well as identify a physical and virtual space for collaborative work. The workspace is made of two elements: a set of tools and a set of methods.

Within the case study, the set of tools consisted of already developed and market available design and collaboration software and hardware that allowed team members to work together or individually in project production and idea development. Several tool types have been identified based on type of work: (i) Virtual workspace gathers digital tools for lightweight textual, verbal and graphical information exchange for cooperative and collaborative moments; (ii) Physical workspace uses physical tools (idea boards, post-it’s and prints) to support information exchange and to produce physical format output (sketches); (iii) Individual design tools consist in precision digital architectural design software that are used to produce the final render documents in the architectural project. The set of methods is designed to support the evolving nature of the collaborative design process: changing interdependencies from one phase to the other, adapting to specific requirements of collaborative and cooperative moments, ensuring decisional continuity from vertical to horizontal layout and vice versa. Several method types have been defined, based on nature of collaborative work: (i) ShareLab Footnote 1 is a methodology that allows to manage the collaborative design process in presence or distance synchronous meetings; (ii) Collaborative decision-making methods encourage the participation of agents in the decisional process and try to formalize a common understanding, which supports information exchange and cooperation; (iii) Coordination methods are a set of guidelines that ensure the continuity between collaborative and cooperative moments through the generation of team activity awareness using meeting reports, workspace instructions and tool use charter.

4 Conclusions

Describing collaborative architectural design as a system made of agents, sub-systems and relationships opens a path to support the design process from first sketch to final render. In the case of the international architectural idea competition, the CISP provided the necessary methodology for an integrated design system connecting organizational, planning and shared workspace elements. Fostering collective intelligence enabled an adaptable process that took into account the teamwork complexities and allowed to deliver a shared project idea within the available spatiotemporal constraints. Some notable case study observations and limitations on the CISP are presented hereafter. At first, the protocol was procedural, imposing a large number of formalized interactions between team members, but gradually naturalized into the design process, evolving and adapting along with it. Within the organization layer, sub-team coordinators of the vertical layout changed their role, becoming simple sub-team members. Therefore, while sub-team distribution was maintained, the vertical layout relied mainly on the overall coordinator for ensuring continuity of the design process. From the planning layer point of view, the design process split into two main parts: idea development (including the research and exploration phases) and project render (including the production phase). As a consequence, the two parts used distinct CISP configurations: (i) during idea development the horizontal organization layout, virtual and physical workspace tools, ShareLab and collective decision making methods were dominant; (ii) during project render the vertical organization layout, individual tools and coordination methods were dominant. Within the shared workspace layer, the design process required extensive knowledge sharing between agents as well as intensive coordination between collaborative and cooperative moments. For this reason, virtual and physical workspace tools as well as ShareLab and coordination methods have been adapted to include the above-mentioned interactions. The present research is simply a first iteration that is aimed at formalizing a protocol capable of supporting collective intelligence within collaborative architectural design and at obtaining preliminary feedback this in regard. Further developments seek to: (i) improve methodology through research development within future case studies, (ii) develop the methodology towards other stages of the architectural project that include non-expert agents (i.e. clients, stakeholders); (iii) integrate innovative collaborative design technologies (i.e. BIM, building information modelling) and an agent-based modelling approach (multi-agent systems).