David Jennings

Overview

This paper describes my experiences of running participative design sessions with staff in a medium sized user organisation to develop specifications for two database applications. The approach used for these sessions was based on low-tech screen mockups and user scenarios. The approach was more successful for one application than for the other, and the paper considers the reasons for this in terms of the nature of the applications and organisational issues.

Background

The organisation is a Training and Enterprise Council (TEC) with around 70 staff. The part of its business that is relevant to this paper is the running of government-funded training courses for young and unemployed people through a network of training providers who contract with the TEC. The organisation's computer system -- which was provided by the government in 1990 -- centres on a set of applications using a 4GL Relational Database Management System. Currently this is supported by two staff with some technical expertise, while the Information Systems Manager post is vacant. I have been working with the organisation as a consultant on-and-off for eighteen months: further details of this are given in Jennings (1993).

Trainee Follow-up System

The arrangements for funding of training have recently changed to put more emphasis on whether trainees have achieved a "positive outcome" (e.g. a job or further education) after completing their training. This means that the organisation needs to be especially rigorous in following up trainees, and it was felt that the new demands were too much for their existing manual procedures. Those involved in this area had done some preliminary work to map the sequence of events, but in a meeting to discuss progress on information and systems issues we decided that further work was necessary to develop this into a system specification as quickly as possible.

The first session was attended by the manager of the training programme, the manager of the admin and audit team, the administrator who will be chiefly responsible for maintaining the system, and the system administrator who is starting the development of the application. These represented all the main stakeholders in the application. Based on the mapping work, I developed some draft designs for input and follow-up action screens in advance of the session, and I then facilitated this and further sessions.

The approach we took was inspired by the PICTIVE technique (Muller, 1992), though without the video element, and the scenario-based approach to design specification (e.g. Carroll et al. , 1991). Thus the main agenda was:

• (Why) do we need a computer system to support follow-up? What key tasks will it help us with? Generation of scenarios
• Brief overview of technical options and constraints (of RDBMS and screen design)
• Screen design (including field validation)
• Scenario-based walkthrough of screen designs for quality review.

The screen design was done using A3 acetate sheets (as used for overhead projectors) and non-permanent pens of various colours. Putting these sheets in the centre of the table afforded easy redesign of the screens by any participant. The acetates allow scrollable data to be shown "behind" the screen fields. The final designs were photocopied and circulated afterwards with the scenarios that described how they would be used.

The first session (two and a half hours) produced outline scenarios for the whole application, including reports and enquiries, plus one completed screen design and an expanded scenario specifying exactly how and when a user would operate this screen. Further sessions have involved going through further screens, considering how these would be used in each of the scenarios identified, and simultaneously refining the scenarios to make them more comprehensive.

Scenarios had to be refined through the sessions because we had only a high-level specification to begin with, and so further requirements analysis was needed. Exploring the scenarios threw up a number of instances of exception-handling which were important but made the design requirements more complex. The interdependencies between screens and between status transitions meant that we had to revisit some of these a number of times. We were hovering on the point where "evolutionary" additions to an initial design begin to threaten its basic integrity. At times the branches between scenarios were so complex that some more formal notation might have been helpful as a support. This highlights the need for case-by-case tradeoffs to decide what specification and design work will be done using participative semiformal techniques, and what will be done using other complementary techniques.

Participants in the sessions found them hard work, particularly in thinking through all the possible occurrences and implications, but they felt they understood the systems issues much better than they had before. The system administrator was also satisfied that he had a good basis for developing the application.

Management Information System

For some time the organisation has been aiming to improve its collection and use of management information, particularly statistical information on trainees and training programmes. In the last year a wider set of information has been collected and input to the database than previously, but for a complex set of reasons -- more organisational than technical (see below and Jennings, 1993) -- there has been some frustration because middle and senior managers have not been able to get this information in a usable format.

Following the initial success of the Follow-up sessions, we tried a similar approach to reviewing how screens could be designed to present the statistical information. We assembled two programme managers, the admin and audit team manager, and the system administrator (one of the admin team was also going to attend, but could not).

In this case the original approach broke down. We found that the unpredictable and non-programmatic nature of the application domain meant that it was not possible to generate such tightly defined scenarios. Managers could not specify clearly the "triggers" that might lead them to want a particular set of data: for example, the need for one set and view of data could be occasioned by the result of another view. Instead we took a step back and found it more productive to consider simply the set of data that was collected, and the rationale for its collection, and then to decide the most basic and useful way of presenting this in tables on screen (with the proviso that this could be supplemented with more complex ad-hoc Structured Query Language enquiries where needed).

Organisational Issues

Organisations like this TEC, which work in an information intensive area but are not large enough to warrant sizeable information systems (IS) departments, face difficult issues in managing systems development and implementation. They need a wide range of skills and expertise concentrated in few systems support staff. These staff must deal with technical details and disciplines, but do not have the "comfort factor" of working in a culture which fully understands these. It is tricky to divide functions fluidly and effectively between in-house staff and contractors/consultants. The sorts of tensions which arise in this context are reflected in the number of times I have been brought in, and in the fact that one IS Manager has come and gone in the last year.

To explain and to help address previous concerns about the lack of readily accessible information, I introduced the concept of a "learning cycle" to represent the to-and-fro exchange of systems specifications, implementation and review between the IS team and the various user teams (see Jennings, 1993, for more details). This encompasses the exchange of understanding of system capabilities from one side and of business processes from the other. We have found that participative design sessions can potentially enhance this learning process. However, our experiences suggest that there is no one method that can be universally applied: rather a range of participative design techniques need to be tailored to specific organisational settings and application domains.

References

Carroll, J M, Kellogg, W A and Rosson, M B (1991) The Task-Artifact Cycle. In J M Carroll (ed.) Designing Interaction: Psychology at the Human-Computer Interface. Cambridge: Cambridge University Press.

Jennings D (1993) A Nomad Roams the Organisational and Technical Landscape: A Case Study. Paper prepared for INTERCHI '93 workshop on Working with Users Throughout the Product Lifecycle: Nomadic Practice in User Centred Design .

Muller, M J (1992) Retrospective on a Year of Participatory Design Using the PICTIVE Technique. In Proceedings of CHI '92 (Monterey, California). New York: ACM. 455-462.

Copyright © David Jennings