Issue
Article
Vol.29 No.1, January 1997
Article
Issue
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |
"We need a new system which will provide functions from the old system and additionally some new functions". This request, from the owner/director of a small despatch company, provided the authors with an opportunity to investigate two related research themes; the first was concerned with the adoption of different approaches to data collection, and the second focused on the process of generating requirements throughout the design process. The opportunity was in many ways ideal in that underlying the superficially uncomplicated request was an interesting challenge for any designer of interactive systems. The reality was as follows:
The problem then in the course of improving on the existing system, was to overcome the reluctance of the workforce, increase or at least not decrease job satisfaction and support the workforce in conducting their tasks by allowing positive transfer of existing knowledge wherever possible.
In the past we have argued (Johnson, Johnson & Wilson,1995a) that an approach to design which included user involvement could be beneficial in that it avoided designers relying on their intuition about users and their work tasks. In the same paper we argued that we are not specifically engaging in participatory design (PD) because our approach to analysing and modelling tasks does not share the underlying philosophy of industrial democracy. Therefore, any increase in user satisfaction is a welcome by-product rather than a primary objective of designing systems that support people in their execution of everyday work tasks. In this case we were neither adopting the underlying philosophy nor specific participatory design methodologies designed to allow users to participate in design. However, users were heavily involved in the design process, (Johnson, Johnson & Wilson, 1995b).
The circumstances of the present case heightened the need for a decision as to what advantages and disadvantages there might be in adopting the underlying philosophy of workers having control over their own destiny as in the PD tradition. According to Opperman, (1984, p157) participatory design, "considers the interests of users and other affected groups ... [and] influence over the development process by the users. By their own efforts these groups will define their specific interests and incorporate these into the goals of system design". For Mumford (1983, p140), "participatory design enables employees to mould their own futures to a degree and create an environment that they find efficient and stimulating. By taking part in a process that is creative yet directed at a specific task-based goal, they acquire the confidence in their ability to contribute to the management of their own change". Mumford further argues that job satisfaction is the achievement of a good fit between what the staff seek from their work and what they are required to do in their jobs.
Daniel and Yeates (1984) indicate that the decision to introduce a new computer system should involve users in both planning and design. This involvement is assumed to provide a mechanism for resolving conflicts of objectives, gives users control over planning and design processes and results in high confidence and understanding because of the user role in design. The expected outcome is that the user group copes better with uncertainty and problems can be worked through and resolved. It may be the case that individual users may still experience uncertainty but it should be easier for them to communicate their problems and resolve them. Moreover, there is a high commitment to the system when it is introduced.
We choose to adopt the principle of PD in order to reduce staff reluctance to the new system, indeed to get the commitment of staff to the new system by involving them continually throughout the design process. One possible disadvantage of using a PD approach is that it may not suit the structure of British organisations, since it requires user (staff) participation in major decisions about the design of a new system. For instance, the approach is not appropriate for UK firms which have very rigid, bureaucratic, hierarchical structures where the managers do not consult staff members and where staff very rarely have the responsibility to make decisions for themselves. Therefore, there is often a conflict of interest between what clients want and what users require. However, the courier company was a very small, friendly firm where the company is owned by a number of partners each having a role within the company. The nature of this company made it possible to adopt the philosophy of industrial democracy because the user interests were mirrored by the clients, as a result of the client's participation and thus equal knowledge of, the user roles.
The approach would only be judged a success if three criteria were met; i) there was a strong user commitment to participation, ii) there was a degree of consensus within the company, so that conflicts could be easily resolved, and iii) the company would allow staff time to participate. The first and third criteria were met due to the close involvement of the first author with the company resulting from employment there during the summer. Meeting the second criteria would only be known to some extent during and at the end of the participation exercise.
Figure 1: A schematic diagram showing the process of data collection, requirements elicitation, and the evolving nature of the requirements
Participatory design could be characterised as having at least three facets; the underlying philosophy, specific methodologies and techniques for ensuring participation and the specific aspects of users and their work to which the methodologies and techniques might be applied, for instance, job satisfaction. In addition, a cursory glance at the different approaches to PD indicates that there are differing roles in, degrees and types of, participation by users with different outcomes. In this courier despatch example we adopted the underlying philosophy by involving users in all decision making throughout the design process, but used data collection methods with which we were familiar from task analysis. The task analytic data collection techniques with which we were familiar were adopted for the following reasons; i) some of the PD techniques have not been used by other than their developers, ii) other techniques such as contextual inquiry were just variants on data collection methods (concurrent protocols -- CP) used in task analysis approaches to gathering knowledge about users' tasks. Moreover, contextual inquiry suffers from the well-known problems of CP and provides little in the way of corroborating evidence for the data collected. iii) Our familiarity with the techniques previously used in task analysis exercises meant that we knew the advantages and drawbacks of each and were able to overcome these by using complementary methods by which to collect the data with the least disruption to the company. Figure 1 shows the process of data collection, requirements elicitation and the evolving nature of the requirements as the users participated in the very early stages of the design process.
Six methods of collecting initial data about the domain, tasks within the domain and how these were related and accomplished were employed, (see figure 1). The data were analysed and modelled using Task Knowledge Structures (TKSs). The task models were then validated with the users for the various tasks within roles and along with the good and bad aspects of the current system were the basis for the first set of requirements. Along with a frequently acknowledged problem of how to get from evaluations and task models to requirements, was the problem of the different ways in which the task were undertaken by different employees. The fact that different staff undertook the jobs in different ways was not viewed by us as a problem but as another example of where it is important for designers to be aware that even experienced users may not always adopt either similar or optimal methods or even recognise that their methods were suboptimal. The problem could be solved in a number of different ways each with their costs and benefits, either by providing alternative ways to carry out the tasks on the system to suit different users, or pool all the alternative means of achieving a task goal, ask all users to undertake the task by each method and then reach agreement on the most efficient or preferred methods. The results of the task analysis indicated that the controller role in particular was organised differently by different users in how jobs were allocated to drivers. The negotiation that followed amply illustrated the process of compromise when conflicts arise due to users participation in design and also illustrates the evolving nature of the requirements. The changes to the initial first set of requirements were as a result of this negotiation phase and the result was a refined set of requirements. At this stage another phase of participation arose when the requirements had to be prioritized and agreed by company employees on their ability to meet socio-technical objectives thus emphasizing user job satisfaction.
Initial system design and prototyping (both paper and runnable) then began with the users involved in the evaluation of the prototype and requirements review. Agreed changes to the designs were made at this stage to accommodate changes to the requirements once the users discovered what was or was not possible or what was or was not designed in the way intended as identified by the evaluations. Iteration between prototype, requirements review and evaluation continued until the users indicated that they were satisfied with the resulting design. The system was also walked through by an HCI expert.
The process of generating the requirements for the courier despatch management system was a success in that the users did appreciate being involved in the majority of the decision making that occurred throughout the design process and as a result had greater commitment to the newly designed system. The output of the design exercise, the new system, was on balance judged to be better than the old system, although there were acknowledged to be both good and bad aspects to both systems. Only the long term commitment to and use of the system in the future will indicate whether it is better designed than the old system and in what respects the participation of users in the design process contributed to this.
Daniel, A & D.Yeates (1984) Practical systems design.
Johnson, H., Johnson, P & S.Wilson (1995a) Task analysis and participatory design. In Proceedings of CHI95 Basic Research Symposium.
Johnson, P., Johnson, H & S.Wilson (1995b) Rapid Prototyping of User Interfaces Driven by Task Models. In J.M.Carroll (ed) Scenario-based design for human computer interaction. Wiley & Sons, Inc.
Mumford, E. (1983) Participatory design: Successes and problems in systems, objectives, solutions.
Opperman, R. (1984) User participation: Some experience and recommendations in systems, objectives, solutions.
email: hilaryj@dcs.qmw.ac.uk
tel: +44-171-975-5238
Issue |
Article |
Vol.29 No.1, January 1997 |
Article |
Issue |