According to Kling there is a significant body of organisational informatics research about the importance of user involvement in the design process. By involving users in the whole design process the hope is that the ICT will be more attuned to the needs of the people that are actually going to use it. System development based in the technological deterministic school was seen as a defined and controllable process with clearly defined phases. Kling argues that user feedback should be sought continuously.
Most professional and educational literature still defines user involvement as assessing user requirements for a system on at the beginning of the design process. However, in these early assessments, many users emphasize the major functions and routines of their work, overlooking important variations or exceptions. If user feedback is not continuously sought throughout the design process, then a new system is likely to not effectively handle overlooked exceptions, complexities, and nuances.
(Kling et al. 2000, p.35)
Scandinavian research projects have traditionally put a strong emphasis on user involvement. In the Scandinavian research tradition user involvement has been discussed and practices in the last 30 years. This approach to design has been given the label Participatory Design (PD).
Bjerknes and Bratteteig (1995) list the three reasons normally given for user participation in design:
The two first reasons are based on practical considerations, common to several system development approaches. The third reason is based on a belief in democracy and that it is a valuable goal to increase workplace democracy. To achieve this PD should involve future users in decisions taken during system development (Bjerknes and Bratteteig 1995). The third reason give PD a strong political touch and potentially makes it deeply controversial from a management perspective.
PD have it’s background in the Scandinavian trade union projects in the early 70’s. Within the Scandinavian IS research tradition the main theoretical contribution have come after projects, as researchers have reflected on the projects. The projects conducted after the trade union projects can be organised into two different trends; the design for the skilled worker, and use of computers in an organisational context.
The first trade union projects had some characteristics in common. This projects were mainly concerned with the organised work force and production. They claimed that there is a antagonistic relationship between labor (the workers) and capital (the management), and wanted to strengthen the labor side in order to make the struggle more even. They claimed that researchers have a duty to support those with less power, and were striving for a democratic research and development approach. One of this project was initiated by the Norwegian Iron and Metal Workers’ Union (NJMF) with the objective of applying a workers’ perspective on development and introduction of new technology (Bjerknes and Bratteteig 1995).
Two projects represents the next generation of projects; UTOPIA which represents the design for the skilled worked trend, and Florence which represents the use of computers in an organisational context trend. Both trends saw it as necessary to create alternative technologies, to fight vendors’ monopoly. The trade union projects did improve workers’ influence on technology, but to increase this influence the focus was shifted to the form and content of the work process.
The UTOPIA project was conducted between 1981 and 1984 as a joint research project involving several Scandinavian research institutions and the Nordic Graphical Union. The project focused on work processes concerned with page layout and image processing in the newspaper industry. This project was laboratory based, where trad union representatives would participate as skilled workers. In the laboratory, mock-ups and simulations of computer based working environment was used. This approach called design by doing, allowed the graphical workers to express their craft skill by demonstrating their work. At the end of the project the tool perspective was developed:
The computer should be a tool for the skilled worker, and the worker should be in control of the tool.
(Bjerknes and Bratteteig 1995, p.78)
The Florence project focused on the nursing profession and was conducted from 1984 to 1987. Essential to the project was mutual learning. This is a process were the users and the designers learn from each other, which is important to PD. The Florence project started out focusing on a single profession, but a strict bias towards the nursing profession was difficult to maintain. Physicians and nursing assistance was also involved. The project discussed the IS relating to the organisation as a whole.
The totality of an organisation can be addressed in two ways, through a management perspective or by emphasising that there are several differing perspectives depending on various stakeholders’ organisational positions and roles.
(Bjerknes and Bratteteig 1995, p.81)
It is important to note that an important aspect of user participation is the users’ sense of ownership over the system.
. . . the users’ sense of ownership is significant for the sustainability of the system. Lorenzi and Riley suggest that technically competent [ICT-based] systems may be woefully inadequate if their implementation is resisted by people who have low psychological ownership of that system. On the other hand, people with high ownership can make a technically mediocre system function fairly well.
(Nhampossa 2006, p.68)
In the European tradition of PD there are two methods; the socio-technical approach and the collective resource approach. The socio-technical approach considers the organisation as a whole and stresses that employers and employees have a common interest in developing useful ISs and therefor seeks consensus among the different stakeholders of the system. The collective resource approach emphases the conflict of interest between employers and employees. This approach highlights questions about power, control and democracy at the workplace and regards it as the researchers’ responsibility to support the weaker party. (Bjerknes and Bratteteig 1995, p.83) and (Nhampossa 2006, p.69-71).
The US tradition of PD have downplayed democratic empowerment, that is to give workers decision making power, and focus more on functional empowerment, that is to empower workers to have more freedom in how to effectively meet the goals set by management. In the US, focus shifted towards approaches like contextual design which, while maintaining the importance of user involvement, gave the prerogative to the expert designer and emphasised management goals like efficiency, productivity and flexibility (Spinuzzi 2002). In the US, traditions like user-centered design and customer-centered design have emerged. This tradition do not focus on democracy and empowerment, but on making useful products for the customer or end users. Xerox Palo Alto Research Center (PARC) was an early supporter of PD in the US (Asaro 2000).
A very important method used to facilitate effective communication between users and developers is the use of prototypes. Both the UTOPIA and the Florence project used prototyping as part of their strategy to facilitate user participation. In the Florence project prototyping reduced misunderstandings in the communication between the workers and the researchers and it helped in clarifying the needs of the nurses. The UTOPIA project used mock-ups as prototypes of a future system in order to make a requirement specification. In this section I will describe the two primary types of prototypes that are commonly identified; The throwaway prototype and the evolutionary prototype. Last I will present the different ways prototypes have been used in PD.
Throwaway prototyping is also called rapid prototyping. This class of prototypes is not meant to be a part of the finished system. It is only meant to give a visual illustration of the system, or parts of the system. This is done in order to facilitate communication between users and designers. The UTOPIAn mock-ups are an example of this class of prototypes.
Rapid Prototyping involves creating a working model of various parts of the system at a very early stage, after a relatively short investigation. The method used in building it is usually quite informal, the most important factor being the speed with which the model is provided. The model then becomes the starting point from which users can re-examine their expectations and clarify their requirements. When this has been achieved, the prototype model is ’thrown away’, and the system is formally developed based on the identified requirements.
(Crinnion 1991, p.17)
Throwaway prototypes can be further classified according to their fidelity, that is how close the prototype resembles the actual planned design. Examples of low fidelity prototypes are paper based prototypes. Using paper, scissors, pens, tape etc the user interface can be pasted together in collaboration with end-users. High fidelity prototypes are interactive and simulates parts of the planned design. A high fidelity prototype can be implemented using a tool for building a Graphical User Interface (GUI) which looks like the target system, but have now functionality, this is called horizontal prototype. The prototype can focus on only part of the functionality, which is called a vertical prototype (Rudd et al. 1996).
Evolutionary prototyping is a different way of thinking about prototypes. Here the prototype is meant to be a part of the target system. The prototype is coded with a quality level high enough for inclusion in the target system. Evolutionary prototyping is iterative and in each iteration only well understood requirements are implemented. After the well understood requirements are implemented chances are that you will understand the other requirements better. The iteration goes on indefinitely. The system is put into use as soon as a minimum number of requirement are met, and is constantly refined based on experience from using the system (Davis 1992).
For a system to be useful, it must evolve through use in its intended operational environment. A product is never ’done’, it is always maturing as the usage environment changes . . . we often try to define a system using our most familiar frame of reference – where we are now. We make assumptions about the way business will be conducted and the technology base on which the business will be implemented. A plan is enacted to develop the capability, and, sooner or later, something resembling the envisioned system is delivered.
(Software Productivity Consortium 1997, p.6)
In the PD tradition the importance of prototypes to facilitate user - developer
communication has long been understood. In Scandinavia
Bødker and Grønbæk (1991) proposed cooperative prototyping. The prototyping
process is seen as a cooperative activity involving users and designers, where the
users and designer should be equally active drawing on their different skills.
Cooperative prototyping focus on high fidelity throwaway prototypes, and is
very design focused.
In the US two notable prototyping techniques were developed; Plastic Interface for Collaborative Technology Initiatives through Video Exploration (PICTIVE) and Collaborative Analysis of Requirements and Design (CARD). PICTIVE and card are both focused on building low fidelity throwaway prototypes and resembles game playing. (Spinuzzi 2002)
The value of participation have broad recognition in the IS literature, so much that Heeks (1999) gives it the status of orthodoxy. Like other methods that have received wide recognition PD has been in the danger zone of becoming a “silver bullet” method, a method that is always relevant and beneficial. In practice participation is often beset with problems. In this section I will present some of the problems articulated in the IS literature.
Inherent within PD are conceptions of democracy and empowerment. All stakeholders in an IS should be given influence on the design. This implies that a team should include all stakeholders and that they must participate on equal terms. In contexts where there is a gap between this conceptions and the realities of the organisation, the ideal-reality gap can make participation unattainable or severely hampered.
Heeks, Mundy, and Salazar (1999) gives some examples of situations where user-participation techniques are unlikely to work well:
In his paper Heeks (1999) suggest three question that should be asked when participation are considered:
By asking this questions factors limiting the value of participation can be revealed. Heeks (1999) explains situations that limits the value of participation and problems with participation; on who is chosen to participate, and the difference between participants in their ability to make a difference. I will not go through them here, but this points are important to be aware of when participation is considered.