«Abstract. The paper explores what exactly it is that users participate in when being involved in participatory design (PD), relating this discussion to ...»
This conflict in and split of the project team illustrates the problems geographical distance may pose in a design project, in which some of the decisive design moves are made without all participants having the possibility to be present.
IPCity was driven by a strong vision, which shaped the selection of choices.
The team had lots of space in how to implement the vision, making it concrete.
However, the cornerstone of the vision – to provide ‘normal’ citizens with a tool and language for participating in urban projects - was not open to negotiation.
Several key decisions in this project were taken as a result of the first participatory
workshop with a rather simple first prototype:
to work with multiple representations of the site, including photographic panoramas for being projected on the wall; to allow for rotating and zooming the table as well as the wall panorama;
to include dynamic, changeable content; and to dedicate effort on how to design the 'tangibles’.
In retrospect we can say that the following eight participatory workshops mainly served to implement these decisions and to improve the design (but new functionalities were conceived, evaluated and redesigned). But the overall concept of the MR-Tent was maintained throughout the project. (Bratteteig and Wagner 2012, p. 43) Within this framework, many design choices were largely uncontroversial, like those proposed by the urban specialist-users: they made choices how to represent an urban site and through this defined most of the functionalities of the ColorTable. Other choices required negotiating and convincing: for example, the decision not only to include ‘normal’ citizens in debating and visualizing the future of an urban site (which met some skepticism at the beginning) but also to dedicate time to preparing user-participants in the urban workshop for their task.
Hence, this decision, which was imposed at the beginning, created conflict in the project. Also highly controversial were the choices of visual content for these urban workshops, with different visual cultures clashing. The technical decisions of how to implement the vision were taken by the designer team and the possibilities for non-engineers to participate in these decisions were rather limited.
Some of these decisions, such as using color tracking, were much debated and put into question time and again, when it became clear that the sensitivity to changing light conditions turned out to be a problem that was difficult to master.
The four projects highlight quite different ways of taking decisions about which path to follow in a PD project: from classical negotiation between equal partners, to ‘coaxing’ participants into particular choices, to more implicit forms of decision-making as part of ongoing design moves. We also see that diverging perspectives between participants were handled in different and not necessarily inclusive ways.
4.4 Concretizing choices A particularity of designing IT artifacts is that design moves materialize choices in an evolving set of prototypical realizations of a design concept or idea that can be demonstrated – or even tested – in more or less real situations of use. While users may contribute substantially to opening up choices for design through various techniques of collaboratively imagining potential futures, the (technical) implementation of design ideas may be much more difficult for users to contribute to. While users may not be able to engage in the technical development itself, PD encourages forms of expression and concretization that are easier to master, such as building mock-ups and enacting scenarios of use. The projects illustrate different levels of participation in this process.
After the Nursing prototype had been discussed in the negotiation meeting, the nurses came up with a sketch of how they imagined the screen. This sketch served as a specification of the prototype, and the designer team quickly made a textbased prototype to check with the nurses (Figure 6). Then they went on to program the prototype to make it possible to use with real patient data. The programming turned out to be very difficult. The nurses had based their specification on the Macintosh computers that they had worked with during the mutual learning period. However, the computer available to the project did not have an object-oriented interface (this was in the 1980s): it did not support graphical representation or drag-and-drop interaction. The programming therefore took longer than expected, but turned out successful in the end.
Figure 6. The text-based prototype
The children in the Sisom project engaged in concretizing the design choices that had been taken by the core project team in various ways. One of the workshops was a card sorting session aimed at finding out how the children categorized the symptoms to be used in the system. The cards contained words that had been checked with doctors and parents, assuring that symptoms were expressed in a simple, understandable, non-medical lay language that children could understand. A second round focused on matching symptoms to problems and explaining why for example a hurting stomach can be a symptom connected to rather different situations (e.g., nausea, disgusting medicine, being afraid, problems at school).
Figure 7. Making a list of symptoms and categories for navigation in the system
The children’s ‘translation’ of medical terms into a list of symptoms, which mixed physical and emotional symptoms in ways common to children, was used as a basis for designing the main navigation structure (Figure 7). Hence, the children’s ways of talking about symptoms was directly translated into elements of the prototype. Their drawings were used as inspirational material, with the graphic artist and a flash designer developing them into a professional looking interface. The logic of the users was crucial for successful use of the design result in both the Florence and the Sisom projects, hence making this the basis for the interface design was considered important.
Desarte had architects as user-partners, whose professional background enabled them to contribute directly to the design of the visual interface of the
In a series of joint design sessions with the architect, graphic designer, 3-D designer, and computer graphics specialist, we talked through the design of these worlds, developing ideas about their content, describing atmosphere and details. The architect produced sketches of each world. The 3-D designer took the documentation of this unfolding conversation, together with the associated visual materials, as a script for his design work (Wagner and Lainer 2003, p. 15).
At the core of these design sessions was the joint analysis of a large variety of examples of artwork, with the architect-users and the graphic designer bringing beautiful visualizations and the programmers asking them to simplify and omit detail (most of the designs were too complex to be technically implemented or would have slowed down the performance of the prototype) (Figure 8).
Figure 8. Designing ‘ocean/desert’: the architect’s sketch; the 3D version using selected visual material In IPCity most of the concretizing was in the hands of the designer team: they developed the tangible user interface and tracking mechanism.
A core observation is that when the urban planners made suggestions they addressed problems on the ‘right’ level for the IT experts to respond to. They expressed their expertise verbally but also visually, e.g., producing visual examples of ‘urban concepts’, arguing with the help of maps and other representations of a site. This facilitated integration of their knowledge into the evolving prototype. For example, the photographic panoramas against which the visual scenes could be viewed were developed collaboratively, with the architects providing depth-maps and coediting the panoramas together with the visual artist. Desarte and IPCity both were projects that depended on and made space for the highly specialized visual skills of their users and their deep conceptual understanding of the issues at stake.
Figure 9. Architect-user integrating his mobile phone as a possible design move; the mixed-reality Observations made at the urban workshop that was carried out in Oslo point at additional possibilities of users to contribute.
One of the participants, an architect himself, carried out a design move, suggesting a choice and concretizing it spontaneously. The participants had worked on a mixed reality scenario with the aim to making a metro station more hospitable for people waiting for the next train. They placed a small stage with musicians close to the station and the architect-user started looking for a sound in the available library, not finding any he liked. He immediately searched for sound on his mobile phone and placed it on the table associating it with the scene – a feature that was easy to implement (Figure 9).
Involving users in how choices are technically implemented seems to be the most difficult part in a PD project. We have seen that users can contribute in their own language of sketches and drawings, as well as with their own experience with computational artifacts. But participation can also be limited to having users select surface features in an already decided-on design.
4.5 Seeing/evaluating the results of a choice Typical of the practice of PD is the involvement of users in the ‘seeing part’ of design moves, when choices are tested ‘in use’ and eventually questioned. This ‘seeing’ part may be organized in rather different ways: from brief episodes in a rather tight collaboration to more formal and carefully prepared evaluation workshops or field trials. Some types of ‘seeing’ involve mostly the designers themselves, when they are testing a technical solution or come to understand why the users proposed a particular choice.
The Nursing system that was developed as part of the Florence project was a suggestion made by the nurses. The designers aimed at realizing the nurses’ sketch even though the technical conditions made this difficult. It is hence the designers’ ‘seeing’, which makes this case unique: while the computer vendor’s technical staff suggested to tell the users that 'this is not technically feasible'.
However, the designers, recognizing the nurses’ logic in the sketch, found it technically challenging and gave it a try.
The Sisom system was not really evaluated by its target group: children with cancer, until it was almost finished. However, some of the prototypes were tested by the school children placed in a bed, resulting in a more realistic evaluation of the prototype, e.g., how heavy, big, or ‘serious’ it appeared.
Due to the intense involvement of the architect-users, evaluation of the 3D Wunderkammer was an iterative process, in which the designers and the users collaboratively probed the different versions, discussing what they were ‘seeing’, bringing in choices for redesign. Here the ‘seeing’ part was integrated with the development. Metaphorically speaking, the ‘lab’ in which the prototype was developed was not far from the context of use.
‘Seeing’/evaluating was a major endeavor in IPCity. The evolving prototype was tested in eight participatory workshops, each of which required extensive preparation, with numerous decisions to take: which site to select; which issues to prepare for discussion; how to organize the transport of the prototype (not only the ColorTable but the Mixed-Reality Tent housing it); which workshop participants to select. Urban specialists, representatives of different interest groups (the local administration, business people, etc.) but also ‘normal’ citizens that would be stakeholders in the particular project, tested the prototype in the context of real urban projects – and by doing so actively participated in the ‘seeing’ part after a series of design moves: they tried hard to perform well allowing designers to learn how to improve the interaction design; they selected (and ignored) content to work with; they were active in the handling of some of the shortcomings of the representations of the site; they met the instability of the prototype, in particular the tracking mechanism. Not only this: they also challenged a premise that was close to the heart of the urban specialists: the need for precision in representing objects in an urban environment at the right scale. Most of the workshop participants, in particular the ‘normal’ citizens, did not see the need for precision at the stage of vision building. Their ‘seeing’ clashed with the ‘seeing’ of professional architects. The choice of the non-expert users strengthened the designers’ decision not to prioritize ‘precision’.
Other aspects of ‘seeing’ in IPCity happened before each participatory workshop. An example is the tracking mechanism whose algorithm was improved in each cycle of design-evaluation-redesign. Testing the new algorithm involved three steps: first, the engineers tested the ‘machinery’, probing if its execution had the desired results. They then tested the tracking in the lab space. This required controlling for the lighting conditions, which should be as close as possible to those in the upcoming workshop, and calibrating the colors of the tokens. Finally, tracking was tested in use with workshop participants moving the tokens on the ColorTable when building urban scenes.
A developer from another university, who was responsible for programming the tracking mechanism, was present in all urban workshops, taking notes and assessing the problematic situations together with the designer team. In the end she found out that she only fully understood the requirements when she finally used the tool herself, which was in one of the last workshops. No one had been aware of the fact that she simply had been too shy to ask. ‘Seeing’ may have to involve ‘doing’ in order to be effective.
‘Seeing’/evaluating in a PD project is a rather complex process that involves and eventually aligns different types of ‘seeing’: the designers who arrive at a better understanding of use, hence also the qualities of the technical solution; the users who through ‘doing’ (and eventually commenting) give rise to new design moves. These types of ‘seeing’ may be tightly integrated into the design moves in a project or they may require long and careful preparation.
4.6 Importance of the participatory result Evaluating how participatory a design project is also requires looking at the design result, a point that has been made by several researchers. Balka points to the importance of increasing the focus on the outcomes of PD projects, asking ‘can we have good participatory processes that do not show evidence of more democratic ideals in the resulting artefacts?’ (Balka 2010, p. 79). We think of a participatory design result as one that increases the ‘power to’ of users. When assessing how successful a PD project was the quality of the end result stands out as of particular importance. In PD it is assumed that there is a relationship between the depth of participation and how many of the users’ contributions are visible in the design result: ‘The success of the outcome is fundamentally linked to the different voices who have been able to contribute to its design’ (Robertson and Wagner 2012, p. 65). We will come back to this question later (see section 6).
First, we have a look at what kinds of participatory results the four projects produced and how users contributed to them.