Having a say

In Phase 2, as in phase 1, PD methods were chosen because they facilitated a rich exchange of information. Like our use of paper prototyping described in the previous section, the use of scenarios and working prototypes in this project were chosen because they were consistent both with PD values and would facilitate collaborative working and recognition of expertise at all levels of the organisation. We found that they did indeed succeeded in providing an effective, as well as a streamlined and pragmatic, route to having a say. (Textbox 10). We also found that the scenario-based methods were useful in our specific context because they could provide specifications for the project without relying on prior experience of managing technology projects on the community partners' side, and could accommodate different levels of confidence with using computers.

The role playing exercise in iteration 2 making use of the working prototypes facilitated the fleshing out of fine details such as the exact the fields required for information and the workflow, as well for Kate the front end developer to start to develop the user interface.

In terms of the tools that you

used… Those exercises where you came in and you did stuff, when you said click this, do that, do the other, I found they were a really rich learning experience - ah I see what you’ve done now, no you can't do that and they were really good… I think that was a very rich exercise in terms of how quickly we could to see what needed to be different and how much you could learn from us at the same time.

Mike Smith 9 April 2014

Textbox 10: Reflection on iterations 2 and 3

The workshop activities in both iteration 2 and iteration 3 quickly revealed the large volume of granular information that needed to be gathered from clients. Consequently, at this point, the challenge for the user interface design emerged clearly (Textbox 11). In considering possible design solutions, we found that the role-playing exercises gave us useful guidance. For example, a possible solution for long, complicated forms under consideration was a guided, multi-step form. However, from the role-playing scenarios we discovered that gathering information from clients in advice work is a non-linear process where information may be given at any point. Therefore, we realised that it was important to also be able to enter information at any point and we quickly concluded that a multistep form would not work in this context (Textbox 12).

Reflecting on these workshop and testing sessions from a PD perspective, it emerged that the chosen methods facilitated having a say and mutual learning very effectively. The development team learned more about the work at Real and how it needed to be recorded in our system, and in the meantime staff at Real gradually built familiarity with the basic constructs of the system, and the kind of things we needed to know to address requirements and problems. Added to that, the whole group gained insights into the issues around consortium working, even though we were missing participation from other consortium members at this point. This illustrates the effectiveness of PD methods in facilitating the mutual learning process that has gone on to be so crucial in the long term sustainability of the project. Going beyond this, our activities reflected Muller and Druin's concept of a '3rd space' in which experiences are shared and creative solutions emerge (2003). Very significantly, though hard to quantify, the group reflections also showed that these shared tasks helped to build trust and understanding between the development team and the community partners. As also observed by Parra et. al., trust is an essential if under-recognised enabler for a long term participatory process (2015) and therefore key to

Some people were reluctant to role play but some had a lot of fun with this aspect. One staff member from Real immediately launched in to acting out a loquacious client with a complicated set of benefits, health problems and complaints. It was a playful and empathetic moment which showed us immediately that information comes in to a worker in a non-linear, disorganised form and, like advice work itself, our application would need to deal with multiple entry points to a problem.

Textbox 12: Self-reflection from scenarios 1

Its dealing with an issue that a lot of websites aren’t which is that its collecting a lot of information and needs to present that in a way that’s easy and that people access. So many different fields was something we really battled with. and we tried a lot of different approaches because that’s a really complex system. Kate Lomax 9

April 2014

Textbox 11: Reflection on dealing with complex data entry

sustainability.

After the group workshops based on the iterations, the PD principle of “having a say” remained a guiding principle but was more difficult to fulfil through PD methods. Before this point PD methods were invaluable in enabling feedback and conversation that bridged roles in the development process. However they were less useful for facilitating the next stage of discussion, which demanded systematic thinking, tackled thorny issues, and had a need for precision. The challenges around communicating this thinking sometimes led to tension (Textbox 13). Though we did not apply any defined methods at this point, ad-hoc collaborative and creative strategies played a part in problem solving attempts both among the development team and Real. For example, one of the most complex features of Hublink is its control of visibility of data between organisations and teams. Data can be shared between teams on the basis of client consent, and even then, certain fields need to remain hidden until a caseworker is allocated. While I tried to puzzle through the detail of the problem and possible

implementations through schematic, visual representations, the team at Real, working

independently from from the development team, evolved their own method, using scenarios to think through variations of the problem and coming up with a visual expression of these (Figure 29).

As things worked out, all the different needs could be catered to via the configurability of the Organic Groups module and some custom code that automatically added content to the correct group following some quite straightforward rules. Moreover, after launch some adjustments needed to be made because of different corporate policies of the partners. Though complex, the groups and permissions part of the system has remained robust through the life of the project,

That whole process was really really difficult; partly because you see things visually, I see things in lists, and Mike sees things in longer lists! Doesn’t he! (all laugh). He's all about words, and we were the three of us coming from quite different places. It took a long time to actually get past that, but i think we've done it and I think it actually does work. Cathie Duncan 13

March 2014.

Textbox 13: Reflection on working out group visibility Figure 31: Horizontal tabs: can be clicked to reveal more information or form fields

perhaps because of the level of focus from all participants at this early stage, and certainly because of the ongoing configurability of the system while in use. This robustness illustrates the value of the FLOSS software dynamic in which tailorability is developed in response to the shared needs of the community who use the software.

The lack of a completely stable group of participants throughout the process was not an ideal situation. At the time, this did not seem to be a major barrier to progress (Textbox 14), but in retrospect a view emerged that it disadvantaged the project (Textbox 15). Literature from CI provides insight on the constraints faced by community organisations, where workers prioritise frontline work (Burt & Taylor 2001) . Added to this, in disability organisations workers may be more likely to be part-time as flexible work is an important way that the organisations'

workforce can better represent the communities that they also serve (Disability Rights UK 2015). The problem of working under tight constraints is expressed in the reflective interviews, for instance Textbox 17.