Participatory Design
Click on the link below for summaries and questions or if you like scrolling, the full text is below.
Ehn, "Scandanavian Design: On Participation and Skill"
Gronbaek, "Achieving Cooperative System Design"
Bodker & Gronbaek, "Cooperative prototyping: Users and designers in mutual activity"
Ehn, Pelle. "Scandanavian Design: On Participation and Skill."
Ehn defines participatory design as design which engages both the designer and the skilled user with the purpose of producing a high-quality product and promoting Democratic participation and skill enhancement. The design approach is guided by the “democratic ideal” that “[e]very human should have the right to participate equally in decisions concerning his or her life” (42). These decisions address: 1) how resources will be controlled and by whom; 2) the organization of the production and design process; 3) who decides how work is organized; 4) autonomy at work.
Ehn discusses projects developed in Scandanavian settings known for workplace democratization using laws which required certain actions by employers especially as those laws directly affected/regulated the company business and favored workers. Nevertheless, as Ehn makes clear, these laws did not guarantee that worker situations would change; the employer still had the "exclusive right to make decisions" and laws were interpreted in ways to benefit the employer (45).
The trade unions helped to advance the interests of the workers even though different workers have different interests and power levels. The idea of the "workers' collective" implies that PD studies will be done within a specific context in which the "'we-feeling' [is] created by" workers having "physical proximity...which makes interaction possible" (46). Unions demanded specific objectives and negotiation cycles and quantifiable demands determined by workers’ experience which were in stark contrast to the production systems which were difficult to define and quantify.
Ehn deliberately sided with the workers and their organizations to support the development of their resources for change towards democracy and rejected the assumption that design was a “rational decision making process based on common goals” (47). Ehn cites several studies in which “job satisfaction” and increased productivity were determined to be common goals but were difficult to implement and when conflicts arose the control of management was strengthened.
The NJMF project reflected the failure of the traditional design process which involved researchers and other individuals making project decisions. A new strategy, the collective resource approach, developed in which local unions chose the topics for study and external consultants assisted in the study. Defining the problem to analyze and solve via the participant led to “the search for new knowledge and the start of an educational process” (50).
The DEMOS Project demonstrated that the significant issues for the workers and for management may differ from management’s view which led to “local agreements for codetermination and rationalization” (54) in which workers demanded flexibility to determine how they would participate in the entire work cycle to achieve their tasks.
The UTOPIA Project added the idea of design to produce quality product to the main idea of the other projects, “support for democratization of the design process” (57). The researchers developed the “tool perspective” which call for the design of tools “as an extension of the traditional practical understanding of tools and materials used within a given craft or profession” (57). The designer would have the technical capability but would need to learn the practical understanding from the user. The understanding was achieved by the use of “design-by-doing approach” which included mock-ups and prototypes.
Ehn turns to theory to advocate a move away from product-oriented design to “process-oriented” design which focuses on people communicating about how to use and design software so that design becomes “an interaction between understanding and creation” or “language as action” (62).
Ehn argues that systems need to be rethought as “learning from each other” to cooperatively produce and envision tools and their use. This knowledge-making can be accomplished through planning and creativity (i.e. participatory design) and the use of language to interact, cooperate and (re)construct the world; to determine, not how the system should be used, but how we use the system and how that use should/could alter the design. Ehn argues that the strength of nonlinguistic design artifacts such as mockups and prototypes lies in the ability to 1) mirror the participants everyday work activity so the design can “make sense” (67) and 2) take advantage of both practice understanding and propositional knowledge. Revolutionary designs will only be possible if other users can be involved and other skills leveraged without excluding the participation of traditionally skilled users.
Participatory design should be understood as a process in which users and designers learn from each other, but ultimately PD projects should meet several conditions: 1) make a difference, 2) be realistic, 3) be fun.
1. To what extent does legislation legitimize (or not) the rise/creation of participatory design or any research methodology or methodology requirements?
2. Does the idea of the "worker's collective" translate to the United States? In what ways does technology, strengthen or weaken the "worker's collective"?
3. Do online communites also create a "collective" and can those members of online communities participate in a PD study? What design accommodations could be made?
4. Would business be interested in PD studies as Ehn advocates (open, creative, collaborative, worker problem-based) or is that philosophy more appealing to academics?
5. Towards the end of the article, the author argues that the designer's new role is to design "language-games" (73). Is the designer the researcher? if so, then what do we call the designer?
6. Is the research (PD) considered a "language-game"?
Gronbaek, Kaj et al. “Achieving Cooperative System Design: Shifting From a Product to a Process Focus.”
Gronbaek et al. also advocate shifting to a process focus which includes the user and designer. The key element of the process involves carefully determining the conditions of user participation. The authors present two case studies to show the importance of the 1) who will be involved and when will they be included, 2) the details of the contracts or agreements, 3) process focus to determine more insights.
The first project involved design by software engineers and the exclusion of users in the design phase. The authors consider this exclusion a product of the designers’ lack of knowledge of available methodology choices. The development team worked with changes which were determined in advance. The task of producing the user’s manual was given to participants who had no control over the design and eventually disengaged from the project. Different group members exercised control over different aspects of the project and resisted change or failed to include group members in certain activities. The project was abandoned because of perceived lack of market for the product.
The second project was guided by a formal contract which involved significant user involvement in design and requirement specifications and production of mock-ups and prototyping. A phase of the project involved changing specifications which required renegotiation of the contract and the use of a process-contract.
These cases demonstrate that future users need to be carefully defined as ones who understand the actual work processes and both developers and users need to be identified early in the design process. The selection of users involves determining power dynamics among participants and between participants and researchers.
Gronbaek et al. argue that contracts need to emphasize the process rather than the product so that they do not impede the iterative design process. Having a fixed contract assumes that all information about the project and the user needs will be known. Enough flexibility needs to be built into the contract to allow for changes and modifications especially in the contract itself. The authors recommend that the contract “outline a set of work tasks” and guidelines.
Management and users have different ideas of what the product goals should be and many times those are contradictory. If a project is commercial, then the contract for the project can hinder the progress of a PD project. I think the whole point of PD is the expectation that the process will be "iterative" and design issues which have not been anticipated will have to be dealt with. The whole concept of the contract presupposes a very specific plan of action and set of deliverables.
How would a commercial "team" maintain flexibility for the iterative process of PD?
What would make organizations be open to process contracts?
Since these projects are lengthy, I wonder what type of organizations fund these type of projects. I doubt that many projects which emphasize the process would get funded or would receive support from the organization. The motivation for the projects usually comes from the desire to "improve the usefulness and usability of [the] product" (92). It seems to me that most organizations would be interested in a final product and the proposal which they approve would have to focus on that product.
It would be important for the researcher to keep the process central in his mind especially if they want the project to succeed but ultimately the product is the final deliverable (?), not only so that the individuals working in the company at that time can be successful and productive with the product, but also so that future users can find the product useful.
How dangerous/risky is a PD research project for a dissertation in which time and deadlines are critical?
Bodker, Susanne and Kaj Gronbaek. “Cooperative Prototyping: Users and Designers in Mutual Activity.”
Bodker and Gronbaek advocate the participation of users not only as sources of information but also as active participants who can help to solve problems.
Cooperative prototyping is a design process in which both users and designers, employing their different qualifications, “actively and creatively” participate in the creation and modification of paper and wood mock-ups. The activities may serve to
- Generate ideas
- Engage prototypes in a work-like activities to evaluate their usefulness.
The authors detail their project to design computer support. They began by working with the caseworkers to define their practice and determine where technology could be included in their work environment. They used interviews to gain understanding of the work tasks, future workshop to determine problem areas, and prototyping to meet the needs to the group.
Bodker and Gronbaek describe the process of evaluating the prototype with each participant. They discuss the problems and successes they experienced with each participant and how they could improve the prototyping session.
They discuss activity theory which they used to focus on the different activities which occurred during the prototyping sessions. They determined that their prototyping sessions could be categorized into breakdown and focus shifts. They argue the focus shifts should be used as a learning opportunity and the researcher should not force the participant to follow a rigid session schedule.
- Some sessions focused on evaluating the prototype by simulating future work action using a frame task. At times, the prototype only worked fluently for a short period of time and then the participants could not do what he wanted to do. This lead to specific ideas of what needed to be added or changed in the prototype.
- Some sessions became idea generating sessions in which the participants determined specific capabilities they would have like included in the system. The session then turned into how those ideas could be implemented.
- Some sessions focused on the work practice which helped designers become more familiar with the frame task. This understanding was needed to avoid contradictions in how the frame task was seen by designers and users.
- Some sessions focused on the prototyping session itself and the inability of the designer to make the modifications which the user needed. These breakdowns lead to better prototyping session in which the designers were more prepared.
The authors explain the process they used to prepare for prototyping session. They determined the purpose of the session, how stable the prototype should be, planned to in-session modifications, chose a setting, and determined how the outcome would be evaluated.
They also detail several lessons they learned about being prepared:
- They needed more extensive sample data to make their prototypes more effective;
- Be prepared for ideas to push the limits of the prototype capabilities;
- Learn more about specific work practice;
- Plan method to keep the session focused when participant or designer is focusing on detail which is not productive;
- Determine participants and their roles.
It seems to me that the project discussed in this article is an academic project and the participants did have an opportunity to say "No" and they would not be "losing" anything if they were not benefitting from the project. The authors mention that the organization did not have any money to contract the services. The researchers then would have to be more careful to include the participants since it would be easy for them to determine that they wanted to stop participating.
I wonder how the dynamics of a project shift when the project is being conducted "on the clock" and if participants feel more obligated to continue participating even they do not agree with the decisions, focus, or direction of the project?
How would the dynamics change if the researchers were contracted? It would be disengenuous to approach the users with "what's the problem" if they have been contracted by management to "fix" something, or would it?