Our role as researchers has been to provide the element of “translation” between the user’s domain and the developer’s, since:
“PD [Participatory Design] requires effective communication between individuals with different kinds of training, different goals, different languages, and different workplace cultures… the discourse must include models that both parties can understand”. 11. Williams and Begg. (1993) ‘Translation between Software Designers and Users’, Communications of the ACM, vol.4, no. 36.
The importance of the involvement of some form of “translator” in bridging this gap has been investigated for similar development projects, particularly those using a Participatory Design approach, and has been shown to be a key element for the success and sustainability of a final product.
A paper by DePaula (2004) 22. DePaula, R (2004) ‘Lost in Translation: A Critical Analysis of Actors, Artifacts, Agendas, and Arenas in Participatory Design’, PDC 04 Proceedings of the eighth conference on Participatory design: Artful integration: interweaving media, materials and practices, Vol. 1, pp.162-172.argues that it is essential for researchers to gain a deeper understanding of translation problems, in order to build a more effective partnership between developers and users, by reaching beyond a design focus. As he suggests, we endeavoured to collect as much preliminary information on the “work practices, environments and technologies, as well as preferences, values and norms” of our prospective users (Phase One), and took this forward into the Design Group phase to inform the design process. Guiding scholars to consider the conceptual thought processes behind their research practices and methodologies was undoubtedly instrumental in constructing an approach to design working from actual research practice and, in turn, helping us explain design decisions to developers using this framework. The ways in which we fulfilled this “translation” role and opened the channels of communication between the users’ domain and the developers’ are outlined next.
Following each Design Group it was the task of the research team to review the vast amount of audio-visual data collected and draw out the key themes to present to the development team. First of all, we transcribed and annotated the individual critique narrations and group discussions. From these we created a key points document, setting out the main observations, critique and suggestions extracted from all the recorded data. The screen capture files were amalgamated with the video camera footage so that the two would play side by side in sync and clips of this, several minutes each in length, were identified to support each of the key suggestions. This method of presentation was used to show the findings to the development team. All of the recorded data and transcripts of individual narration and group discussion were also made available to them.
During the first review meeting, we systematically addressed each of the key suggestions to enable the team as a whole to respond to the needs the users had expressed and also reflect on our own preconceived ideas and biases. This was an important step as we could act as “translators”, intermediaries between the users and developers, and explain and/or interpret the ideas and requests made by the participants by looking at the conceptual framework behind their practices and actions. The developers worked with these key suggestions and all of the recorded data to produce a specification for search functionality. During the second review meeting, the developers presented their interpretation of a specification to the research team and this was discussed, refined and agreed upon. Using this specification, the developers created a prototype featuring the basic functionality requested, which could then be critiqued and honed by the Design Group.
This process was reiterated for the subsequent Design Groups and made transparent for the participants. We shared with them our interpretations of what they had said and showed them the specifications we had arrived at, from which the iterations of the prototype had been developed. The aim of this was to reassure the group that their observations and suggestions had been central to the development process and that they were building on something they had conceived from the very beginning. This did seem to motivate the participants and give them some feeling of ownership over the developing resource.
This analysis and consultation process was fairly labour intensive and time-consuming but produced good results. However, in terms of thinking about scalability for similar digital resource development projects it may have to be incorporated differently into project team workflows. The LAIRAH report 33. Warwick, C., Terras, M., Huntington, P., Pappa, N. and Galina, I. (2007) ‘The Master Builders: LAIRAH Research on Good Practice in the Construction of Digital Humanities Projects’, Literary and linguistic computing, vol. 23, no.3, pp.1-3., mentioned in section 1.1.5, recommends that projects consider recruiting staff whose expertise covers both subject knowledge and competence in digital humanities techniques. This is perhaps a more scalable model to work to, rather than creating a separate “translation” role, in terms of making sure that there is a high level of understanding between users and developers and maintaining a consistent dialogue between the two.
Consultations with the development team revealed that they found it incredibly useful to study the screen capture recordings of the participants using a variety of digital resources, including the project prototype. They seemed to be able to obtain a great deal of useful information from watching the videos alongside their spoken narrative. As such, some exploratory ethnomethodological analysis was conducted to support their interest and the high level of detail achieved through the step-by-step recording of actions with time stamps has fed into development work, adding to the overall intuitiveness of the resource. This analysis can be found in the next section.