Iteration 2: First working prototype

Iteration 2 was the result of a thorough review of the feedback from the paper prototyping stage and consisted of two working prototypes. The objective of the first working prototype was to evaluate and expand the basic three content types (clients, enquiry and project) that had been identified during the paper prototyping stage, and to provide a research opportunity for the front-end, user interface design.

For this stage, the main building blocks of the application had to be put in place. These were the 'content types' for clients, enquiries, referrals and projects. In any Drupal project, content types are the fundamental building blocks of an application, comprising of extensible, customisable containers for data. These content types are intended to be extensible with unlimited numbers of 'fields' that are designed specifically to capture the data required in any particular situation (Drupal.org 2015). Therefore Drupal is very well suited to working with prototyping as once a basic framework for content types is in place, fields can be easily added or amended. Figure 23 shows the schematic plan for content types at this stage in development. It should be noted that an additional content type – 'referral' had been proposed at paper

prototyping stage, but discussions indicated this would be unnecessary.

This first prototype was presented to staff at the Real offices on 19 June. The meeting had a good range of people from both management (2 staff members) and frontline work (2 staff members) . The frontline staff members were not the same individuals as those that had attended the initial workshop. An agenda was circulated to all participants a day in advance (Textbox 7). Myself and Paula Graham from the development team attended and we were joined

Aim of the meeting

Test the work done so far and make sure we are along the right lines

Create some 'real', representative content Ensure that the systems workflow suits the way information is gathered and shared in practice Work out priorities for the next stage especially in usability

Establish a concrete todo list for REAL re: categories etc

Get a feel for the training requirement further down the line

Anything else important

Textbox 7: Agenda for iteration 2 evaluation meeting

for the first time by Kate Lomax, a front-end development specialist who was being supported via the TLI grant to develop the user interface. The prototype had been installed on a web- server so it could be accessed over the internet, from people's own workstations in exactly in the way that the finished application would be. The meeting was planned around a simple role- playing exercise in which staff would be asked to act out scenarios that I had defined in advance (Textbox 8), but which I knew from research to represent common tasks. It was planned for these exercises to take place in small groups with one of the development team taking notes in each group.

The rationale for using scenarios and role play was twofold. Firstly the designers and developers wanted to devise ways to find out more about how frontline workers actually do their jobs given that it was not realistic within the resource constraints on both the part of the development team and the community partner organisation to do a full set of ethnographic observations. Secondly we wanted to give people a chance to tell us about their day to day work in ways that enabled them to express what they find significant or notable. So although it might not be a fully accurate way of knowing about client work, it would be a creative channel through which frontline workers could tell us what they wanted us to know. Several PD researchers have referred to the use of improvisational acting to in PD including Brandt et. al. (2012) and Ehn & Kyng (1991).

To open the meeting, the design team briefly explained the main thinking behind the work in the prototypes. However, we did not demonstrate or explain how to do particular tasks. We left this to the hands-on part of the meeting.

• Scenario 1: Capture an enquiry from a person who has not yet has contact with the

consortium. From this enquiry, create two referrals to two different organisations who will be copied in to eachother.

• Scenario 2: As a manager, allocate projects to caseworkers

• Scenario 3: As a caseworker, track your existing work by creating a new casenote for one of your clients.

Textbox 8: Scenarios for iteration 2

For the main part of the meeting, the entire meeting split into two for the role play. The two groups comprised a mix of development team members, frontline workers and management. Development team members guided people towards the correct buttons to press and fields to fill out only when necessary as it was a good opportunity to see how intuitive the design and terminology might be to those with domain knowledge so development team members gave an outline explanation and detailed instructions only when requested. In this respect, the

methodology draws from the 'discount usability' methods of Nielsen that emphasises the importance of the texts used in interfaces and the basic principle of usability that interfaces should 'speak the users' language' (Neilsen 1997). Members of the development team took careful notes of users' comments and the difficulties encountered. Figure 24 shows the result of scenario 1 in which an enquiry is logged and a referral is made. In the example shown, there is already an existing referral.

In addition to testing data entry for clients, projects and enquiries, the team also showed the first prototype of the 'dashboard'. The development team had envisaged the dashboard as a control centre for workers and managers to help them organise their work. It would show the

personalised workload for each person and would have different components for different roles. Figure 25 shows the dashboard for a consortium manager at iteration 2. In this case, the

dashboard of organisation managers show incoming referrals to an organisation (My referrals). Then the case load of the logged in workers is shown. The final block is an overview of all referrals in the consortium (All referrals). This design is a direct result of the discussion at the initial workshop about the need for managers to triage new referrals and allocate them to the most relevant case worker. In contrast, the caseworkers dashboard would show only that individual's case load, it would not need to show incoming referrals. The meeting and acting out scenarios was quite a lot of fun, and gave us large amounts of new information to allow us to move to the third prototype.

Figure 24: Data entered from scenario 1