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 ¹.

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 ².

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 ⁷. 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 ³. 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 ⁶. 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” ⁶. 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.

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