7.5: Participatory Design

Participatory Design

Rather than a particular method, participatory design is an overall approach to the idea of document design and composition. Instead of creating something and then bringing users in to test what you’ve created, participatory design as an approach asks that you bring users into the very act of creation. This is a highly complex approach and one that has supported decades of research from any number of technical writing and usability experts. As such, don’t take this section in our text to be definitive by any means, but rather as a very basic introduction to some ways you might want to begin to think about bringing folks in to participate in the design of projects that impact them.

Rather than a particular method, participatory design is an overall approach to the idea of document design and composition. Instead of creating something and then bringing users in to test what you’ve created, participatory design as an approach asks that you bring users into the very act of creation. This is a highly complex approach and one that has supported decades of research from any number of technical writing and usability experts. As such, don’t take this section in our text to be definitive by any means, but rather as a very basic introduction to some ways you might want to begin to think about bringing folks in to participate in the design of projects that impact them.

Structure

With participatory design, your goal is to bring someone into the design process so that they can influence it. The idea here is that the folks who actually do the work, who actually are working in a situation you’re designing documents around, that these folks know the process and the variables better than anyone else might. They know what blind spots exist and what existing documents fail to do well or simply get wrong. As such, you want to bring them in at an early phase, allowing them to shape the fundamental conception of what the text does and why.

One strategy can be to start with the existing document and simply ask folks to tell you what it does well, what it doesn’t do well, and what it simply gets wrong or omits. This can be a useful space for incremental change because you’re starting with an existing deliverable that can be altered as needed to fit the needs of the folks actually working with it on a daily basis. This can also be a useful task to bring to folks that use a document that has been created elsewhere, such as folks creating financial reports from documents not created by their team. Documents can cause issues for the folks creating them or the folks using them.

Another strategy that can be helpful is to simply start from scratch and ask the folks you’re working with what they do and how documentation can assist them in the work they do. What do they need to record? What do they need to pass on to others? This can at times be useful to discuss when you have multiple levels of folks in the same room, allowing them to see how different folks in the same organization need different things from documentation and from the workflow of others in the same company or group. Things that seem arbitrary at one level can be crucial at the next, and learning about the importance of data to folks at other levels of an organization can be helpful to those who generate text that seems meaningless to them.

At the end of the day, there are innumerable approaches to creating participatory structures for document design and service design. The above are two simple approaches that you can start with in your own work, but they are simply suggestions. There is a massive body of research out there that I would encourage you to pursue if you find yourself drawn to this research paradigm.

Interpretation

When interpreting participatory design, please be aware that different users have different values that they give to documents and information. Depending on where someone is in an organization they may undervalue or overvalue information, or simply ignore it or not know it exists. Expertise within an organization can be hidden by existing documentation and ways of doing work. As a technical writer, you need to be aware of these issues and tread carefully. In some cases there can be valuable work that is getting done that documentation doesn’t capture—you can help make that visible. In other cases, there can be work done for no reason and you can bring that to folks’ attention.

Be aware that when you work participatory projects that everyone has a political agenda to push and that you need to keep the overall power structure of the organization and your role in mind when you interpret data. Don’t do stuff that will get folks in trouble, and keep in mind that entire organizations are built around document workflows and that emphasizing one group at the expense of another can create tiffs and rifts.

Technology and Recording

Be extremely sensitive when using technology and recording tools with participatory design. Realize that all of the conversations you have are part of larger power structures that can get those who participate into trouble if the information they volunteer isn’t well received or is taken out of context by those above (or below) them in the power structure.