A Meta-Design Model for Creative Distributed Collaborative Design

Introduction

The most recent applications of Web technologies are geared to support user generated content activities as well as distributed collaborative design. There is a growing design culture shift in that stakeholders are not only passive software consumers but also can play the role of software designers and producers (Barbosa et al., 2001). The culture of participation (Fischer et al., 2004) allows all the stakeholders in the design process to be active producers and system co-designers, and supports them to express themselves creatively. This paper particularly addresses the distributed collaborative design which emerged as a response to the co-evolution of systems and stakeholders (Bourguin et al., 2001; Costabile et al., 2006). Co-evolution implies that, on one hand, the stakeholders’ interaction strategies change by using systems because they become more and more experienced and their work practice changes over time. On the other hand, as an answer to that, systems need to change in order to adapt to the evolving stakeholders. Therefore, systems should present a set of characteristics shapeable by stakeholders according to their profile (in terms of culture, role and platform), in order to support situated practices and requirements. We address distributed collaborative design of software artifacts which involves groups of people who belong to different Communities of Practice (CoP), i.e. people who share a concern, a set of problems, or a passion about a topic and deepen their knowledge and expertise in this area by interacting on an ongoing basis (Wenger, 2002). In the design of complex systems, experts from different CoPs get together in order to collaborate in the design process; that is, they form a Community of Interest (CoI) (Fischer, 2001). In our approach, the notion of the CoP is refined, observing that stakeholders share not only the domain practice but also the technical languages and notations. Collaborative and distributed design activities therefore imply the use of different technical systems of signs, which in turn lead to the existence of communication gaps among the CoPs involved in the process.

This paper is an extended work from Zhu et al. (2010), which presents the Hive-Mind Space (HMS) model, providing different work environments localized to the various CoPs involved in the collaborative design process. The aim of this model is to support the communication and common understanding of stakeholders belonging to different communities by providing them with opportunities to construct their own work environment and have control in the description of problems. Therefore, we have been developing tools and platforms to support these design communities, among whom there are non-professional software developers who are domain experts (e.g. physicians, archeologists, industrial designers, and so on). This will allow them to actively participate in the interaction design process, namely creating, modifying or extending software artifacts (Costabile et al., 2006). Our aim is to design a meeting space with new affordances (Torenvliet, 2003) to support stakeholders from different cultural and social domains, either as individuals or as members of specific CoPs and CoIs, empowering them to become active creative designers as well as creative knowledge produsers (Bruns, 2008). Moreover, we focus on the exchange of virtual boundary objects in a meeting space, the boundary zone, exploring its potential as a means for effectively tackling the collaboration difficulties. Software engineers, HCI experts, domain experts and users come together – each representing a CoP – and participate in the design of a software artifact. We provide annotation tools within the HMS model that can be used by stakeholders to express change requests. Therefore, professional software developers can evolve the system based on the stakeholder feedback.

The following section introduces an overview of works related to our research and that influence our approach. The HMS model is then presented. We describe its structure and present boundary zone and boundary object concepts. To make the HMS model implementation concrete, two real-world cases are described. Further reflections and future works are discussed in the final section.