The checklist became the central point in the design process. Despite all the technological visions we had introduced to the users in the beginning of the project. The most important reason for that was that the Sound and light group already had a very strong vision about a relational database. One member of the Sound and Light group had earlier experiences with computer support for festival pre-production. This support was implemented in a rela-tional database management system, and looked very much like a Òsmart checklistÓ. The Sound and Light group had discussed this concept and
drafted a sketch of a relational database screen layout as they would like it.
This database sketch was basically a slightly expanded transformation of the checklist.
According to the original plan, design together with the users should take place as a series of workshops; only one of these was realised. This workshop took place in the Festival buildings and was scheduled to 5 hours. The
planned participants were members of four Festival operation groups:
Sound and Light (3 persons), Yellow stage (one person), Catering (one per-son), and Transit (one person); the three seniors researchers and two ap-prentice participatory design researchers.
The plan for the workshop was to enact or simulate a series of work situa-tions, both routine and problematic, from the planning (pre-production) and production of the festival. The participants were encouraged to bring real or made up situations that they found interesting, Òfocusing on the exchange of informationÓ and how IT could be used, to the workshop. The idea was fur-thermore that we would introduce various kinds of technologies into the game to elicit how, e.g. computerised telefax, central and local databases, e-mail, or hypermedia would change work at the festival.
The workshop took place around a table, on the walls were mounted large pieces of paper. One piece of paper was laid out with columns for various kinds of technologies; local databases, centralised databases, hypermedia,
computer integrated telefax, etc. Cardboard lids were available to be used as database mock-ups, and yarn for simulating hyper-links between docu-ments. Other pieces of wall paper were used to record situations and prob-lems during the workshop. Material from the previous yearÕs Festival was photocopied in advance together with some made-up ideal typical material produced by the Sound and Light group.
The first problem which we encountered at the workshop was that the par-ticipant from the Yellow stage never came, after an hour of waiting and sev-eral phone calls his seat was filled with one of the Sound and Light guys, who had previously worked in the Orange stage group. This resulted in a strong Sound and Light, and planning bias of the workshop; thus, and it be-came much harder to generate situations where the stage claimed not to have the information they needed. These situations would probably have arisen if the activist from Yellow stage had participated, because that group emphasised the lack of information during the preceding interviews.
The simulation games ended up focusing on how things were done the previ-ous year; the workshop basically became a discussion repeating the infor-mation the researcher already got from the interviews. The cardboard lids and the yarn were never used, and the technology wall paper did not make its way into the situation. The design or construction related part of the workshop was limited to the last half hour, when the original database sketch, produced by the Sound and Light group, was examined with respect to suppliers and users of the information. This part of the workshop was important for building a prototype, but it did not break the meetingness of the workshop.
The design of the prototype took place right after the workshop. The first step was to make an object-oriented description of pre-production and pro-duction. The main functions of this description became to generate discus-sions between us about data formats, and to serve as a vehicle for the estab-lishment of a shared understanding of the Festival among us in the Devise group. In this process the understanding of the Festival we got from the in-terviews was an important resource.
The transformation of the object-oriented description was done by mapping objects to tables in a straightforward manner. The issue of data-ownership distribution of the database over several non-networked PCÕs was already dealt with in the object-oriented model by reflecting the ownership of data in the division of objects. The construction of the user interface of the prototype started out on paper but we soon agreed that it was easier to program the interface right away without making a specification first. The task was un-complicated because most of the prototype was specified in the Sound and Light database sketch, and on the pre-printed checklist made by Sound and Light the previous year.
Findings and further research
In relation to my thesis, the Festival project served as the main background in forming the notion of design as the transformation of artefacts (Bertelsen 1996b, 1997a). Furthermore, the project has been used as a testbed for EngestršmÕs notion of contradiction as an analytical tool (Bertelsen 1996a), and the checklist transformation story has been used to illustrate the idea that organisational learning is crystallised into artefacts (Bertelsen 1996c).
The festival project gives rise to several topics for further research. A lin-guistic investigation into the object-oriented analysis and the database sign could contribute to both understanding our work in the project and de-sign work in general. The lacking ability of our methods to deal with use praxises going through long cycles of separated phases, calls for the devel-opment of new methods. Finally the issue of democracy in organisations with many volunteers, and how to understand such organisations, can yield insight into non-economical perspectives on the workplace.