Reflections on phase

5.1.6.1 Having a Say and Mutual Learning

This case study seeks to explore how a PD design process benefits sustainability beyond the design phase. The first phase of work on Hublink described here represents the beginning of that design phase. As such, the documentation of and reflections on this phase are focussed on the application of PD methods and approaches. It is only later that the influence of these after design can be evaluated.

In this stage, PD methods guide the design of our activities and our overall approach. Deep yet efficient collaboration processes were needed to learn about the work at Real, and in the meantime, the community partners needed to learn about the development team, our needs and our approach. PD methods provided us with a set of tools, and those we used were chosen because they provided spaces for communication and mutual learning that were uncluttered by technology and less susceptible to problems in participation caused by differences in

participants' understanding or experience of using technologies.

In reflecting on this phase, the core perspectives of 'having a say' and 'mutual learning' provide a framework for understanding our activities and their outcomes.

As an outsider, it felt like there was a lot of excitement in the room. People were clearly very committed to the service they provide and making it as good as it can possibly be. The frontline staff were able to define very clearly how they organise the quite hefty administration and record-keeping tasks associated with their jobs; they seemed to very much design their own systems for this that span across electronic means and paper. However people seemed open to the idea of changes and (hopefully) improvements to the systems they work with.

Textbox 5: Self-reflection on initial meeting 1

PD methods, namely affinity diagramming and problem mapping (Simonsen & Friberg 2014), shaped the initial workshop and its facilitation. Through these methods frontline workers were able to take a leading role contribute rich information about how they work and how they currently systematise their own record-keeping. The activity and discussion revealed details of a workflow which was so embedded in the organisations' work that it is rarely discussed, echoing the core observation in contextual design that service design and information systems design most often go hand-in-hand (Beyer & Holtzblatt 1997). In this project, through making this workflow more explicit it quickly became clear where the current pressure points lay and how they might be amplified in the move to consortium working. For instance, team

management activities such as allocating caseworkers to a referral were discussed at length. The frontline workers described a well functioning method for allocating referrals through the use of a special email account that had been created for the sole purpose of functioning as a queue for waiting referrals. While being a really interesting example of technology

appropriation as described by for example Dourish and Dix (2007) and providing a prototype of the task, the workshop discussion revealed that this method was not going to be able to scale up to cope with consortium working, which would need to be able to work within and across several organisations.(Textbox 5).

The participatory methodology for the initial workshop that used a map and sticky notes as its main materials for having a say seemed to work well, but needed to be applied flexibly. For instance, it became evident that for some participants, writing directly on sticky notes was a barrier rather than an enabler of direct participation because of some participants' impairments. This shows that despite the existence of many well established and defined co-design methods to facilitate 'having a say' such methods must always be applied flexibly. An audio recorder was used to document the meeting. This proved essential as only a small amount of the total detail

Figure 20: Sticky notes from initial workshop

discussed had been captured via the sticky notes or any other visual means; in our case, it was the discussion that captured all of the detail.

Nevertheless the meeting was characterised by a great deal of enthusiasm. Reflecting on the session, observations from Bratteteig and Floyd are apposite. Floyd et. al suggest that systems design can be characterised by social aspects such as the collective excitement that comes with working with shared interests and motivations (1989), and Bratteteig suggests they could even be fun (Bratteteig 2003) .

Discussions on the value of prototyping is present in PD literature from its earliest days, for example (Floyd et al. 1989; Suchman et al. 2002), and the use of paper prototypes in this project was inspired by this. In our project, paper prototyping proved to be an extremely effective strategy. Their use built trust by providing evidence of the development team's understanding of the discussions at the exploratory workshop while also providing an opportunity to expand the amount of information exchanged. The staff present from Real expressed appreciation for the accuracy of the knowledge about the organisation that they saw reflected in the prototypes, and they provided a concrete basis through which to further

interrogate and reflect upon the designs. The contribution of prototyping in our project accords with the description by Robertson and Wagner in their discussion of the ethics of PD, wehre they describe prototyping as providing a way to understand, question and intervene in designs that is open to participation (Robertson & Wagner 2012). Overall, in this project the use of paper prototypes provided a platform through which we could learn about each other, the staff could input and though which the whole group could build confidence to move to the next stage(Textbox 6). Additionally, the prototypes were a tool with which a large amount of

Figure 21: Real Local Voices project logo

information into a digestible format could be condensed, so that creative discussion could take place, as well as being a pragmatic tool for communication. Reflections from participants from the group interviews that took place after the design was concluded confirmed our sense that too much abstract paperwork, for instance spreadsheets of specifications or lists of user stories as might be used if using Agile or Scrum methods, was not going to work well in this context where staff are focused on frontline work and management time and resources are always under pressure (Textbox 6).

The development team were disappointed that no frontline workers attended the prototyping meeting especially as the initial workshop had felt very inclusive. In reflecting on this issue, Robertson and Wagner's observation that the strong ethical values of inclusion are often in contradiction with the pragmatic aims of a project and the need to work within organisational cultures of partner organisations (2012) provides insight. This potential contradiction is perhaps heightened in the CI context where the ethics of PD might at times conflict with the importance of ensuring that the community partners have ownership and control of the project as emphasised by writers in CI such as Gurstein and Gurumuthy (2015).

5.1.6.2 Tailorability

Through discussion and design activities the whole team gained a fuller picture of the increased scale and complexity expected with the shift to consortium working, and it became clear that there would be a need for continuous customisation, or at the very least, the incorporation of new functionality at late stages. Tasks such as establishing and maintaining categories that would be needed for subsequent reporting and data analysis internally were clearly not going to be pinned down until much later in the process. It was emerging through our design activities that tailorability was going to be very important indeed and design could be expected to continue well into the use phase.

This made sense to me, when we did this paper exercise. We sat and we scribbled on it, and we took things away and we added things, and it just made sense. If we'd tried to do any of this online I think I would have been lost… [if it had all been presented on a spreadsheet] I would have cried! (laughs). As someone who hasn't used CRMs before, having it on paper like this, where we could easily flip back and forwards, was good, so I wasn't concerning myself with, oh you've got to click that to do that. I was just looking at the information rather than the process of using the tool so that really worked. Karen

Linnane 13 March 2014

Textbox 6: Reflection on paper prototyping

5.2 Phase 2: Design and Development