But is it collaboration?

Thomas Kvan
Department of Architecture
University of Hong Kong
Hong Kong


Collaborative activities are an important application of computer technology now that telecommunications infrastructure has been established to support it. There are many students in schools of architecture who are undertaking collaborative projects using the Internet and many practices who work together exchanging files and interacting on shared digital models. Software vendors are developing tools to support such collaboration. But what are we doing? What is the nature of collaboration and what are the implications for tools that support this work?


The section under which this paper is presented is entitled ‘Collaborative Teamwork’. It has become accepted practice to use the term "collaborative systems" to describe the computer systems which support distal communication between designers. I believe the term has come to be used in large part because of the extensive work already done in the field of computer-supported collaborative work (CSCW).

In discussions about these computer systems for design, their behaviours, specifications and implementation, the most fundamental arguments appear to be encountered on the issues of interaction. What is the interaction to be provided, both interaction with the systems and interactions between participants? Not only do the participants need to share data but, how are they going to communicate with one another? To illustrate the issues and confusions, look at the discussions about the role of video – how important is it, how does it contribute to the interaction between participants and how wide does bandwidth have to be to support it. These issues are raised when considering other aspects of collaborative systems – data exchange; participant interactions with digital models; audio links; among others.

I suspect part of the difficulty of this discussion lies in a misunderstanding or, if not misunderstanding, then lack of shared perception. The problem, I believe, stems from the word "collaboration", as in "collaborative teamwork".

What’s in a word?

What do we mean by ‘collaboration’? Let us consider a variety of situations to explore the realm of activities that fall within our understanding of collaboration.

The realisation that a pair of active beings can achieve more than the sum of their individual results is undoubtedly a significant intellectual step. So do we band together to engage in design, engaging in a collaboration to take advantage of what Steiner (1972) calls process gain.

As we look around us, we see many manifestations of such process gain. We find in the biological and zoological worlds many fascinating examples of mutually supportive behaviours. As Hölldobler and Wilson (1994) have so eloquently shown us, ants exhibit interactions in which they work for a common goal. Examples can be found in other organisms, animals and plants.

Of course, we humans are somewhat different to less complex organisms (although sometimes we wonder). Working together comes more slowly to us. Babies do not collaborate naturally, instead we teach them that is it useful to share. The concept that sharing can be mutually beneficial is not innate and is a difficult one to get across to children. When we succeed, we observe two beings handing objects to one another and not engaging in strife, working toward a common goal.

Are there limits to collaboration, either in time, place or size? Can we collaborate if we have too many of too few participants? Steiner’s work suggests strongly that the maximum number of participants in an effective working group is four. Yet if there were several thousand participants in a design project, would you say they are collaborators? As noted by Abarbanel (1997), the large numbers of Boeing engineers who worked on the 777 consider themselves collaborators.

We are all familiar with experience of collaboration. What specifically makes these acts of collaboration or not? How are the acts of collaboration we are discussing here different from those of ants? How is design collaboration? Might it be something else?

Collaboration and Co-operation

Part of the problem is that the activities that are undertaken vary in intent and participation. Is a crew of a ship guiding it into port collaborating with the pilot who has come on board as it enters the harbour? Is their working together not one of co-operation? The pilot points out the hazards, the captain issues commands to the crew. Are two children sitting together, using the same toys, collaborating or are they co-operating? What is the distinction?

The roots of the words are, of course, frustratingly similar but they do carry distinctions worth pursuing – co – operari to work together; col labore to labour together. Indeed, the dictionary defines collaborate as "to co-operate, especially in literary, artistic or scientific work." Yet when I ask you to think of the two words, you will sense a difference, even if the distinction is a subtle one, but a distinction that I believe sheds some interesting light on what we are trying to do in establishing collaborative design systems.

Collaboration can be thought of as joint problem solving. It means working with others to find solutions that are satisfying to all concerned. This consists of accepting all parties agreeing on the problem definition (or sufficiently so that a common effort can be made), sharing concerns as valid and digging into issues to find innovative possibilities. It means being open and exploratory. It implies a deep level of trust and acceptance.

Co-operation, as the Oxford English Dictionary tells us, is "to work together, act in conjunction… to co-operate for … mutual benefit". There is less of a need to develop a deep level of trust to carry out the work. The dictionary also tells us that co-operation is an older concept (the first instance dates from 1616) while collaboration appears in the English language only in 1860, perhaps suggesting that the concept is a simpler concept than collaboration. It is certainly easier to co-operate than to collaborate.

The important distinction between the two words is in the creative aspect of working together. In this way, collaboration in design is a substantially different activity than the collaboration shown by ants. Design collaboration requires a higher sense of working together in order to achieve a holistic creative result. It is a far more demanding activity, more difficult to establish and sustain, than simply completing a project as a team. I suspect that we collaborate far less often than we pretend to.


The act of designing is, to many, an act that involves others. Many practitioners cannot imagine completing an architectural design and saying "That is mine, and mine alone." For most, the process of designing includes other members of their profession and members of other professions.

To some, this is an ideological position – for example, those who hold the belief that the only good design is participatory design. Work such as Christopher Alexander’s has attempted to formalise this approach into a design methodology. On the other ideological side, the Howard Roark image persists. The brazen hero, working in defiance of society or preconceived notions of design delivers to a client a design that should be accepted must be accepted if the client is to be saved from branded an ignominious ignoramus.

Discounting the extremes of these two positions as being positions that seldom occur and, if they do, are beyond the realm of normal collaborative process, let us ask "Is design collaborative or co-operative?" What criteria could we use to distinguish between the two?

Typically, we think of design as a continuous close-coupled process in which the participants work closely to realise a design. Here, the participants work intensely with one another, observing and understanding each other’s moves, the reasoning behind them and the intentions. At any stage of the design, the observer cannot identify a discrete contribution to the design product from one participant or the other.

Figure 1: Close-coupled design process

Experience tells us that much design is in fact loose-coupled, with each participant contributing what they can in different domains of expertise at moments when they have the knowledge appropriate to the situation. The participants have been engaged to work together because each has a particular expertise that can be contributed to the solution process. In this situation, we see two or more experts operating in their own domains on a shared problem. The design moves in discrete steps, perhaps not a linearly as set out in the very simplified diagram below, but still in ways that we can see a step and identify what has happened during that step.

Figure 2: Loosely coupled design process

Some attributes of design activities

During the design process itself, what is happening? Loose-coupled or close-coupled, how are the participants working together.

Design is often thought of as a process that occupies a continuous space of time. If you ask a design team what they were doing, the participants typically will not think of a time when they are not designing. They will describe a complex series of decisions, threads which were picked up and dropped, tasks and events which occurred. Typically, they will describe intense and extended periods of time when they worked intensively together to solve the design problem. Challenged to identify discrete tasks, they may tell you about tasks that took hours, days, or weeks.

Gero and McNeill (1997) have shown that design is in fact a process that consists of a series of distinct events that occupy discrete and measurable periods of time. Most significantly, they have shown that the temporal span of these design events is remarkably short. In one design analysis, they recorded the majority of events taking less than 30 seconds; another in which the participants were more expert in their field, most event lengths were less than 15 seconds (see Figure 1). As the authors note:

  • "These differences may reflect differences in expertise with the experts moving quickly through the design task or they may reflect differences… between the designers."

  • Figure 3: Event lengths during design
    (from Gero and McNeill, 1997)

    This analysis is in sympathy with a model of collaborative design (Figure 2) postulated in Kvan, West, Vera (1997) which suggest that collaborative design consists of parallel expert actions, each of short duration, bracketed by joint activity of negotiation and evaluation. Thus the design activity itself is discrete, individual and parallel, not intimately linked. The participants act as individual experts addressing design issues from their perspectives. Their expertise may change during a design session as their understanding is supplemented and they learn from their involvement.  

    Figure 4: A model of design collaboration 
    (from Kvan, West, Vera 1997)

    We suggest that the cycle time in this model is very small – probably in the realm of seconds, perhaps not even the 15 seconds that Gero and McNeill have found, although we are still exploring this data. In this model, we can see that the work is in fact co-operative in nature, and that collaboration occurs as negotiation and evaluation.

    This view of the design process is supported further in the categorisation of design collaboration identified by Maher, Cicognani and Simoff (1997) in their review of collaborative design projects, namely:

    Indeed, Maher et al note that the ‘exclusive collaboration’ model is the most effective and the one in which they observed most productive results. Mutual collaboration led to no result at the end of a very busy exchange between the participants, whereas dictator collaboration came to a conclusion as soon as the leader made up her mind.

    Let me introduce one more confusion here. We focus on collaboration and I have tried to distinguish that act from co-operation. But if we look further at collaboration, we see one more issue – compromise. Compromising suggests an expedient settlement that only partially satisfies those involved. It doesn't dig into underlying problems but rather goes for a superficial arrangement. In the model in Figure 4 above, the compromising occurs in the negotiation and evaluation steps, steps in which the problem at hand is redefined and the problem adjusted as work continues. This indeed is borne out by Dorst (1996 p25) with his observation that designers practice "satisficing" very often. This is not a pejorative to be dismissed, for the basis for the satisficed solution goes beyond superficiality and is often a truly innovative solution.


    To be provocative, I suggest that most of the time when people think they are working collaboratively they are actually co-operating and, even more important, compromising. And most of the time that is exactly what they should do. Collaboration is time consuming and requires relationship building and is suited to very particular problems that require such close coupling of the design process and its participants. It would be inappropriate to collaborate to accomplish most design tasks, in the strictest meaning of the word. In short, working together, even effectively, is not necessarily collaboration. Nor should it be. To me collaboration is a deeper, more personal synergistic process and the term should be used selectively.

    Perhaps we should refer to our field as "co-operative design", recognising that the design process itself is one of negotiation, agreement, compromise, satisficing in order to achieve success. We might even talk about "compromised design" at the risk it might imply the wrong thing.

    Whether we are co-operating or collaborating, we can be designing, but I think our expectations for the design environment changes if we think we are doing one or the other. A loose-coupled design process requires a very much different set of tools and conditions to be successful than a close-coupled one. Collaboration requires more than machinery and systems to occur. To what extent the systems are necessary for collaboration has yet to be addressed – I believe many working in this field have their vision clouded by the issues of collaboration itself, failing to recognise the broader and far more important issues of systems for co-operative work.



    Abarbanel, R. M., E. Brechner and W. McNeely: 1997, Flythru the Boeing 777, in Preprints Formal Aspects of Collaborative CAD, M. L. Maher, J. S. Gero and F. Sudweeks, eds. Key Centre of Design Computing, University of Sydney, Sydney, pp3-9

    Gero, J. S., T. McNeill: 1997 An Approach to the Analysis of Design Protocols, in Design Studies, forthcoming, also available on http://www.arch.usyd.sedu.au/~john/publications/ger-mcn-design/Gero-McNeill.html

    Hölldobler, B and E. O. Wilson: 1994, Journey to the ants, Cambridge MA, Belknap Press of Harvard University Press

    Kvan, T., R. West and A. Vera: 1997, Tools for a Virtual Design Community, in Preprints Formal Aspects of Collaborative CAD, M. L. Maher, J. S. Gero and F. Sudweeks, eds. Key Centre of Design Computing, University of Sydney, Sydney, pp 109-123

    Maher, M. L., A. Cicognani and S. J. Simoff: 1997, An Experimental Study of Computer Mediated Collaborative Design, in International Journal of Design Computing, Key Centre of Design Computing, University of Sydney, Sydney http://www.arch.usyd.edu.au/kcdc/cmcd/paper/

    Maher, M. L., S. J. Simoff and A. Cicognani: 1997, Observations from an Experimental Study of Computer-Mediated Collaborative Design, in Preprints Formal Aspects of Collaborative CAD, M. L. Maher, J. S. Gero and F. Sudweeks, eds. Key Centre of Design Computing, University of Sydney, Sydney, pp165-185

    Steiner, I. D.: 1972, Group process and productivity, New York, Academic Press