Iteration 3: Second working prototype

The purpose of this iteration 3 was similar to iteration 2 . It was still necessary to test the accuracy of the basic building blocks for the data that had established though the development team were reassured that this was broadly correct from the previous iteration. However, many new fields had been added following iteration 2 which increased complexity. This brought the application nearer to fulfilling its purpose and while also revealing the biggest design problems.

Figure 25: Dashboard at Iteration 2

Meanwhile, behind the user interface, a custom workflow, which was going to be essential for organising and tracking referrals, had been added which needed scrutiny (Figure 28). However the greatest change was probably the front-end development which been undertaken by Kate Lomax. See Figure 26 which shows a similar piece of data to figure 24, but with the new front- end design. The dashboard had also been further refined.

Though the application has changed incrementally, from the organisational point of view, there was a major change. This iteration was the first in which the new staff (Operations Manager and Project Co-ordinator), who were going to be responsible for delivering the consortium's work, were in post and therefore could participate in the project.

At each of these meetings myself, project manager Paula Graham, front-end developer Kate Lomax and either 4 or 5 members of staff from Real attended. The staff members included the new project co-ordinator plus one member of the management team, and either 2 or 3 frontline workers. Because frontline workers are often part-time, attendance was very much subject to their availability so the same people did not attend at each meeting. This had some advantages as we got to work at least once with most members of the team, but also meant that there was a lack of continuity. This lack of continuity was highlighted later as a difficulty.

Iteration 3 was presented to staff over two meetings, one week apart. This time, instead of the very open scenarios from the previous iteration, I, as the designer/developer of the prototype, provided more structured 'scripts' .

Figure 26: Enquiry in iteration 3

These scripts (see example in textbox 9) were intended to guide participants through tasks that tested the main functionality of the system. For this iteration, scripts were used to provide more structure and direction. They were intended to help participants get a stronger sense of the direction of the project, but as will be discussed later in this section, they were not used in a prescriptive way as the development team were still were aware of the need and value to provide a platform for participants to communicate and discuss what they thought was

important. The meeting once again split into groups, with frontline workers sitting at their own desks, working through the scripts accompanied by at least one development team members taking notes. This approach, making use of observing workers in their own situation, not using sophisticated usability testing technologies such as cameras and eyetrackers, reflects the 'discount usability' approach of Neilsen (1997) . Avoiding lab-based situations is also consistent with the aims and values of PD with its emphasis on collaboration and mutual learning.

These two meetings were long and covered a great deal of detail. In a surprise to us, the discussions combined what might be termed 'service design' with the information technology design. However, the tendency for these two tasks to be entwined, either implicitly or explicitly has been pointed out by a number of writers including Beyer and Holzblatt ( 1997) .

Working with this prototype showed that while, from the point of view of the technology, the general structure was seemingly fit for purpose and the workflow within and between

organisations technically robust, there were still a lot of questions about how the system would meet the challenge of consortium working, or indeed how exactly consortium working would take place. This gap was due to the fact that the consortium itself was as yet unformed. For a

Example script:

Create a new client, and then a new enquiry for that client

• From the dashboard, find 'add new client'

• Fill in the form, including the 'groups audience' drop down.

• Then find the 'client activity' tab

• Click 'create a new enquiry for this client'

• Click the 'client' tab and check the client has been filled in correctly

• Fill in the rest of the enquiry information and save • After the node has been saved, you will see the

enquiry you have just created listed for this client • Click back to the dashboard to find your new content

Textbox 9: example 'script' for iteration 3

variety of reasons that are discussed later in this case study, input from consortium partners was not present at this stage and assumptions had to be made about how other partners work. Nevertheless, by the end of these two sessions there had been a lot of progress. The basic data entry and been solidly established and the dashboard was not only gaining traction as an idea but sparking off new creative ideas. For example, front line workers who participated

contributed idea and idea for how the dashboard could flag up reminders of important dates that would help them to prioritise their workload (Figure 27). Once again, the level of fun,

experimentation and creativity reflects the experiences of PD practitioners over a long period, For instance: Floyd et al (1989b) and Bratteteig ( 2003). It also illustrates the point made by Liam Bannon - that users should never be treated as uninterested in the systems they interact with day to day (Bannon 1991).

However, there were still big challenges still to be overcome. I needed to enter a new and deeper level of detail to work out the structure for information sharing and information visibility within and between organisations and teams, and its interaction with the workflow. Although the formal iterations were over, there was still much co-design to be done, especially around these topics of major concern.