Mutual Learning in Participatory Design

I came across participatory design when I was wondering how software like Mediawiki, Firefox or LibreOffice could be produced: The software is understood as being created by by different groups of people: employees, hired by the software’s supporting organizations, volunteer programmers, and user communities with various degrees of involvement from “mere” use to actively voicing how the software should be changed in the future. To simplify, I call the non-employees “volunteers” in the rest of the text 1.

To work well and efficient together, division of work is important: What do the volunteers and users do, what do the employees do? Particularly: How are new features and changes in the interface decided with and for such heterogeneous stakeholders?

An easy way to think about this, is that employees are much like volunteers members with more time. This is a model that might work in small homogeneous structures, but otherwise easily leads to a tyranny of structurelessness 2.

A different approach is seeing different roles (like employee/user/volunteer contributor) as bringing different skills and perspectives which complement each other. This implies that there is a lot to gain because there are differences.

Since different groups want to work together, communication needs to happen. Since the groups are different, this communication is not easy: If a group is homogeneous, they share different vocabulary and concerns and they can easier communicate without an explicit structure for this 7. If we are to benefit from different supplementing skills, it is likely that different groups have different vocabularies and concerns. What might be a violation of social norms for one group is a normal way to speak for another; What might be a useful function in the software for one group is an annoyance for another. In brief: It will be not easy to communicate precisely because the desirable different skills and concerns different people have.

To communicate and and understand each other, the groups need to enter a process of mutual learning 3. This is a symmetrical process, in which both volunteers and employees learn from each other. They become “peripheral legitimate participants” in each other’s communities 6. In participatory design, particularly the tacit knowledge of people who work with the software is important 10 5: Since it is tacit, it is hard to communicate but is an essential part of what enables people to work efficiently.

The mutual learning in participatory design is facilitated by “boundary objects” 6. These can be stand-ins for the to-be-created product (prototypes) or objects which allow communicating about assumed or current usage like representations of users ( personas ) or usage scenarios. For example, an employee could write a usage scenario based on their current understanding and a participant could improve it (as done in this example ). The participant might add an aspect of use that a current technology can not support well, and the employee can respond in suggesting a way that works with the available technologies.

Since it is focused on mutual learning by designing, “misunderstandings” are normal. Having them is actually needed to identify learning- and design opportunities, since they surface diverging assumptions that then can be further discussed and developed.

Mutual learning in participatory design is a concept that allows the heterogeneous groups of system designers and participants to use their discipline’s competencies for designing together. It does not assume homogeneity of practices and knowledge or the absence of misunderstandings or conflict. Rather, it provides a framing to productively utilize gaps of knowledge and celebrate learning.

Creative Commons License
Mutual Learning in Participatory Design by Jan Dittrich is licensed under a Creative Commons Attribution 4.0 International License.

  1. In Free/Open Source Software, “volunteers” can also go as “community”. However, “community” as “community of practice” 8, according to Wikipedia a “group of people who share a craft or a profession” is also relevant in participatory design, thus I save the word for the “community of practice”-use.  

  2. The Tryanny of Structurelessnes 7 is an essay by Jo Freeman, discussing “hierarchy free” or “structureless” groups in social movements, pointing out that having structure is inevitable and the “structurelessness” is thus easily a smokescreen to hide informal power structures.  

  3. I found mutual learning in the literature of participatory design again and again. I was also happy to find the term in the ideas of Roger Schwarz 9, a business consultant, who draws a lot of his theories from Argyris’ and Schön’s “Organizational Learning” 4. What Schwarz calls mindsets of unilateral control and mutual learning, Argyris and Schön non-descriptively call Model 1 and Model 2. While I think that the Schwarz/Argyris/Schön use of the mutual learning idea is rather similar to what it means in Participatory Design, I did not find explicit connections between the fields.  

  4. Argyris, Chris, and Donald A. Schön. 1995. Organizational Learning II: Theory, Method, and Practice. F First Edition edition. Reading, Mass: Addison-Wesley. 

  5. Bjögvinsson, Erling, Pelle Ehn, and Per-Anders Hillgren. 2012. “Design Things and Design Thinking: Contemporary Participatory Design Challenges.” Design Issues 28 (3): 101–16. 

  6. Ehn, Pelle. 2008. “Participation in Design Things.” In Proceedings of the Tenth Anniversary Conference on Participatory Design 2008, 92–101. Indiana University. 

  7. Freeman, Jo. 2013. “The Tyranny of Structurelessness.” Women’s Studies Quarterly 41 (3/4): 231–46. Web version: 

  8. Lave, Jean. 1991. Situated Learning: Legitimate Peripheral Participation. Cambridge England ; New York: Cambridge University Press. 

  9. Schwarz, Roger M. 2013. Smart Leaders, Smarter Teams: How You and Your Team Get Unstuck to Get Results. 1 edition. San Francisco: Jossey-Bass. 

  10. Spinuzzi, Clay. 2005. “The Methodology of Participatory Design.” Technical Communication 52 (2): 163–74.