«Abstract. The paper explores what exactly it is that users participate in when being involved in participatory design (PD), relating this discussion to ...»
The Nursing system was implemented and used by the nurses and other health care groups in the ward for almost a year after the project ended (until the machine broke down). The designers were happy about being able to implement a robust system that behaved like an object-oriented system, while the nurses were happy for the support that the system and its reports gave them. Moreover, the nurses were able to ‘see’ their voice in the prototype as an implementation of their sketch. The few nursing assistants that refused to use the system, made drawings of the printed reports by hand, hence used the system’s logic in their work. Also the medical doctors appreciated the overview given by the system, acknowledging the nurses’ logic and structuring of the work in the ward, which possibly increased the nurses’ influence in the ward. The Nursing system was later used as a requirement specification when the hospital invested in a new IT system for nurses.
The design result of the Sisom project was (and continues to be) participatory in a variety of ways. It presents a child’s logic of talking about experienced symptoms. It gives children a voice they would not have without the tool in consultations with a doctor, using a language that is close to their own. This increases their influence on what is taken into consideration when the doctor makes choices about further treatment while supporting the doctor’s need for evidence-based medicine. Moreover, the children have their opinion recorded and documented in the hospital system along with other documents. A child could not have imagined a tool such as the Sisom system. Adults were needed to conceptualize the tool and take care of all its features. Still, its participatory features would not have been possible without the children’s participation: it was their vocabulary that was used for navigation and symptom registration, and it was their suggestions for metaphors and images for symptoms and categories. The game-like design included many different elements that first appeared in the children’s drawings.
The 3D Wunderkammer is a mirror of the architects' choices and ways of working. They can ‘see’ their voice in all of its features and in the user interface to the design of which they have directly contributed. As a collaboratively used visual archive the 3D Wunderkammer supports the architects’ practices of collecting, archiving and searching for inspirational material and using it for communicating the design concept. However, requiring a lot of maintenance work, it remained marginal to their work, its value being mainly aesthetic: a 3D space with beautifully designed ‘worlds’ to explore.
IPCity had two user groups: the urban planners in the design team and the participants in the different workshops that were organized in the context of real urban projects. The urban planners’ voice was crucial for the design result, as they taught the designer team how to represent an urban site and how to define the key urban issues at stake, translating them into features of the prototype. They also were to some extent open to breaking with the representational tradition of architecture. The final prototype clearly reflects the urban planners’ perspective on how to represent an urban project. They recognized it as a tool that they would like to use in the future. From the perspective of the workshop participants the main design result was the experience of being able to contribute to an urban project on equal footing with the experts, with arguments and choices that changed the view of the participating urban planners (Wagner et al. 2009). A key participatory feature was ‘immediacy’ – the possibility of doing and seeing the results of your actions. Participants did not have to wait for an expert to provide a drawing and an interpretation. The tool supported an inclusive mode of debating and co-constructing, which does not favor the expert. It left space for everybody.
Our analysis of decision-making in the four PD projects illustrates different ways of organizing participation. Table 2 provides an overview, summarizing the most important observations. We will refer back to this overview when discussing how to possibly assess the depth of participation in a project.
5 The Sharing of power in PD While the first part of our analysis has been largely descriptive, the second step aims to be more explanatory asking: what shapes the possibilities for participation in a PD project? Our interest in understanding power issues in design has led us beyond questions of the institutional context in which the four projects were embedded to ways of talking about the power and influence exercised by different stakeholders. Here we also look more closely into the ‘decision linkages’ in the projects, which influence the dynamics of decision-making, with some choices having more weight than others.
5.1 The influence of context ‘Each power relationship is shaped by a whole series of “structural” constraints that condition the rules of the game, and it therefore expresses, at a secondary level, the logic of the institutions or structures’ (Crozier 1973, p. 214). Also the participatory context of a project may be bounded by structural elements that limit the possibilities for joint decision-making by, for example, restricting access to resources or commending particular ways of working.
A PD project is embedded in a context that offers both, constraints and opportunities for what and how to design. It may have to operate in a highly structured environment that imposes particular ‘rules’ and surely it has to define its own ways of operating. A project usually starts with a project proposal. Vines et al. (2013) observe: ‘Those who write research proposals (such as faculty members) or stakeholders and funding organizations that write the call for proposals and policy documents to which they respond heavily influence this process’ (p. 433). Project deadlines, budget restrictions but also the need to develop a product that fits an existing IT infrastructure may limit the possibilities to widen the design space and maintain it open. Established power relations may make it difficult to design for change, as Bødker and Zander (2015) argue reflecting on a project to support stronger citizen involvement in the design and provision of municipal services. PD projects may be confronted with larger political and organizational issues that are difficult to influence, such as for example in health care where the drive towards ‘new public management’, often requiring a strong focus on standardization and cost containment, may have a profound impact on the design space (see e.g. Reidl et al. 2004). On the other hand, researchers may have a variety of possibilities to increase the design space even in environments that are not open to participation and change (Dittrich et al.
Let us look into the context, in which the four projects were embedded. All four projects started out as ‘technology projects’. The decision that computers are part of the solution had already been taken when writing the proposal; it was never open to debate. The Sisom project aimed at developing a system to be used in a hospital: it had to prove its value not only to its immediate users, nurses and children, but to medical staff and the hospital administration. The choice of an evidence-based approach to categorizing symptoms ensured the support of medical staff. Moreover, the Sisom system built on a successful previous system for adults, with the aim of making it attractive and easy to use for ill children.
This strongly framed the possible contributions by the participating children.
Features of the design that could not be incorporated in the product idea were not considered useful, hence discarded. Although the Florence project’s ambition was to support nurses in their everyday work, it was also a research project. Bjerknes and Bratteteig (1988a) describe how the expectations concerning the computer system to be developed were higher in the research community than in the
Our experience is that, in the scientific community, technical challenges mean making computer systems that may be characterised as 'epaulets': they have technical, fancy features, but are not particularly useful. Making small, simple, but useful computer systems, more like 'utensils', does not give as much credit even if the development process may be just as challenging’ (p. 258).
We can see here how the fact that participatory designers are evaluated by their own research communities may influence how a project is set up (see also Pedersen 2007). Desarte and IPCity were defined as creative-explorative research projects; hence the designers and the participating users had much more freedom in creating and selecting choices. However, there were other kinds of dependencies to take into consideration: the work of several geographically distributed partners had to be coordinated and their different research interests accounted for; the allocation of resources to particular design tasks had to be negotiated within the project consortium and defended in negotiations with the funding agency. For example, in Desarte conflicting perspectives on what to develop resulted in a split of the project team along geographical lines that may have been avoided if the project partners had had the possibility for more continuous collaboration. Both projects had to justify their design moves to external reviewers. IPCity not only started with a strong vision but with a conceptual framework that had been imposed by the call for proposals. Moreover, the vision to develop a participatory tool for urban planning included some ideas about which technological paths to take. That means that the highly specialized research interests of the participating computer scientists framed parts of the context.
The skill composition of the designer team, which had been in the power of the project leader to determine, had a large influence on how the design space was framed. For example in IPCity, hiring a product designer, a visual artist and a musician in addition to two computer scientists meant that their skills and visions were valued and this strengthened the artistic and the design aspects of the project.
The project leader of the Sisom project looked for designer skills that were not present in her organization’s IT group, among them a flash developer and a graphic designer. The psychologist she selected corresponded with what she thought the project was about: understanding children’s vocabulary. The full time anthropologist in the Florence project strengthened the focus on nursing practices as a basis for design.
‘Power as practice’ is shaped and constrained by institutionalized aspects of power, some of which are not so easily amenable to negotiation. They reflect the world of funding agencies and hosting organizations (see also Martin et al. 2009).
In previous work we have distinguished between different arenas of participation not all of which are open to negotiation and change (Gärtner and Wagner 1996;
Bjerknes and Bratteteig 1995; Balka et al. 2008). Other aspects of the context in which a PD project is embedded are under the control of powerful actors, such as a project leader. Choice of funding scheme, use context, project partners, the knowledge composition of the design team, and the stakeholders to be included are part of a setting up a PD project, in which the project leader often has a large say.
5.2 How much sharing of power?
Dealing with conflict was on the agenda of PD since the early days. Björgvinsson et al. (2012) argue that today, with PD moving from the workplace to the public sphere controversial matters are endemic to any participatory project. They refer to forms of debate and confrontation between stakeholders that allow for ‘constructive controversies between ‘adversaries’ […] These activities are full of passion, imagination and engagement’ (p. 109). When controversy is supposed to result in a common design result, there is the need to share power in PD. Hannah Arendt (1970) has expressed this in the notion of ‘power with’, which she ‘defined to mean only the power of the people united, moving to achieve common ends’ (Mansbridge 1994, p. 57). How much was power shared in the four PD projects? Whose power?
User-designer relations are key to PD. In complex settings, such as for example an urban project or a health care organization, stakeholders with different interests and professional backgrounds will have to align their perspectives. Martin et al.
(2009) describe user-designer relations as involving ‘a more complex crisscrossing of relationships where tensions flare within and across groups’ (p. 146).
They provide several examples of how project participants needed to engage in ‘”emotional labour”, while minimising the risk of disputes and ensuring that problems get dealt with according to the correct procedure’ (ibid).
The sharing of power between different stakeholders was not a particular issue in the four projects we discuss in this paper. Florence and Desarte collaborated with a rather homogeneous group of users – nurses resp. architects. In Sisom the project vision included the medical perspective and cultivated the interest of physicians and nurses to have the children’s’ voice heard. Only in IPCity conflicts came to the fore, in particular when the prototype travelled to real urban projects.
In several cases the local authorities insisted on controlling the selection of participants in a workshop, trying to exclude potentially critical voices.
A PD project needs designers that are respectful of the knowledge of users.
This was the case in the Florence project were the designers agreed to develop what nurses thought to be most useful for their daily work, implementing their sketch of a user interface. The architects’ and urban experts’ power/knowledge dominated in the design result of Desarte and IPCity. Both prototypes built on their ideas. Their ‘power to’ was strengthened by their ability to ‘speak’ in different languages: in stories, in visual material, in technical terms, in contributing to the making of a prototype.
In IPCity, some of the choices that were part of the vision created conflict.
While the urban team had on principle subscribed to the idea of participatory urban planning, their interpretation of the scope and depth of such participation was in conflict with the project vision, until the value of citizen participation was successfully demonstrated. Another example of a conflict between the perspectives of the design team and the urban team is the choice of tangible user interface and color tracking. Although allowing for new forms of citizen participation, this solution did not meet the user-experts’ need for precision. In this case the intended end-users, represented by a mix of stakeholders in an urban project, backed up this key design decision.
The situation in Sisom was particularly complicated, as the intended users were children. The project leader had decided to protect the most vulnerable stakeholders: the severely ill children. This also excluded their views and experiences from the design solution. She had based her approach on the work of Alison Druin (2002) with children as informants and also partners in the design.
However, she limited the children’s influence by assuming that children cannot possibly have sufficient insight and may focus on aspects that are fun but peripheral from a professional perspective. Hence, their design moves were carefully constrained by a set of predefined criteria that were to ensure the goals
of the project, and this was made explicit:
Good design for ill children requires knowledge, and pedagogical, psychological and clinical insights children don’t have. In our work we had to make sure to meet the goals of SISOM and a set of pre-defined criteria. Especially, we had to ensure to design software that could help children to report their symptoms and problem experiences, without being too time-consuming and challenging. Not all of the children’s ideas were therefore, feasible’. (Ruland et al. 2008, p.