![[Home]](http://meatballwiki.org/meatball.gif)
ParticipatoryDesign
MeatballWiki | RecentChanges | Random Page | Indices | CategoriesParticipatory design is a methodology of software development that grew mostly out of highly unionized Scandanavian countries in the 1970s as a reaction against the manager-centric models of software development as part of the industrial democracy movement. In a manager-centred world, information systems are often used to:
- Cut costs--mostly by eliminating staff that can be automated away.
- Increase control of staff--by providing greater information awareness of their activities (a la the Panopticon).
- Disempower staff--by transferring operations away from staff up to the managerial level.
- Impose change--by embedded decisions in code without involving the impacted stakeholders.
- Increase "productive" hours worked--by taking away staff's discretion about how they use their time.
In short, information systems that are driven from solely one stakeholder group--particularly the managerial level--reinforce PowerOverRelationship?s (cf. PowerOverCycle), and exacerbate the power divide.
Moreover, traditional software developers and designers also have a power over relationship since they often make decisions on behalf of everyone else. As Lessig argues so eloquently in CodeAndOtherLawsOfCyberspace, code is law. Software developers have to make decisions about how the end user will interact with the information system with every line of code. As such, the developer has almost all the power about how the system will shape the organization. Left to themselves, they can seriously cripple an organization if they screw up.
To redress these concerns, participatory design takes a wholly different attitude towards development. It takes away the system-oriented view of development. In the system-oriented view, the information system is at the centre, and typically it is of the form where the system hosts the information in a database, where it has a series of functional operations that are respresented with atomic transactions, and these transactions are called through an interface to an end user. Rather than putting the primary focus on the information system, participatory design looks at the people as participants, in two very important ways.
First, the people are participants in the outcome of the business process. The information dynamic in a business is complex and not necessarily rooted in a single information system, and certainly not necessarily in a computer-centric one. The full information ecosystem includes everything from a central database, to personal e-mail, to a whiteboard, to sticky notes, to CommunityLore, to the seating arrangement of people in the office. The people are participants because they are the workers responsible for making progress with this organization, and this organization has a purpose in a wider social context (i.e. to society), which consists of people. Everything begins and ends with the people. Thus the term "end" user is out of place, as that presupposes that the person is only at the fringes of the system rather than at its very centre. Rather the reverse: the people are the critical aspects, and the technology is the means by which those people carry out their work. As a result, the best solution may be non-technical: it may involve organizational development or even basic ConflictResolution.
Second, it naturally then takes the view that the people are competent practioners. Quite frequently in traditional system-oriented, management-centric software development, there is a view that the "end" users are irrelevant, since after all they are at the fringes of the system, the final part. However, most workers are not data entry clerks, but fully trained and cogniscent individuals who can contribute meaningfully to the well-being of the organization. In short, they are competent, and thus not frivilous. Conversely, software developers are highly specialized workers. It is well understood that developers do not possess domain knowledge, and that in system-oriented development requirements engineering is the process by which they capture domain knowledge. However, this is bunk. It is much better to have a domain expert work with, along side a software developer (a technical expert) to develop a solution together. By having the stakeholders work on the design of the system with the software developers, an exchange of understanding is made which greatly improves the probability the final solution matches the reality of the stakeholders' process. Moreover, it is a FairProcess.
Naturally, non-developers do not have as much technical expertise as professional developers and they are not expected to learn how to code. Rather, developers and participants talk with a bridging language that they mutually construct for the benefit of the other camp. As a bonus, this neutral, in-between language is often best constructed with cardboard and crayons and construction paper and scissors and glue. Who said we ever had to grow up?
Resources
- [Annotated Bibliography] from the Computer Professionals for Social Responsibility
- [Ethnography in Design] from Louise Ferguson
- [Description] by one of the key researchers.
- [History] from the Computer Professionals for Social Responsibility (host of PDC).
- [Description] from a final project for a Standard CS201 class.
References
Greenbaum, J., & Kyng, M. (Eds.). (1991). Design at Work: Cooperative Design of Computer Systems. Hillsdale, NJ: Lawrence Erlbaum Associates.