Lessons Learned from the Art of Roleplay
Pretending to be a public servant who knows nothing about service design yielded some unexpected lessons on how to sell service design.
Pretending to be someone else isn’t easy. Even as an experienced researcher, I sometimes find it difficult to imagine what it might be like for an internal stakeholder who has to justify the value of service design to their superiors. At the SDGC15 I attended a workshop, “Communicating the Value of Service Design to Government,” that grappled with this very issue. Participants pretended to be senior officials working within the public service. Each of us took on a different role. The aim was to communicate the benefits of service design to those who were less familiar with the practice. In truth, the exercise was as frustrating as it was useful. It was clear early on that those in attendance were more interested in advancing their agenda as a service designer, than they were listening to and addressing the perceived needs of government officials. Here are two lessons role-playing taught me.
Listen first
Great designers listen first and act second. In the workshop, those that identified as being designers tended to launch into lengthy expositions about the value of their work, without listening first. Meanwhile, those who role-played government employees felt that their needs and questions weren’t being heard, and that the designers were speaking an unfamiliar language. This disconnect wasn’t always apparent during the roleplay, but during follow-on reflections our group noticed that this pattern repeated itself several times.
Focus on outcomes, not process
The design process is less important to non-practitioners. They are more focused on outcomes and results. At our table, we had a lengthy discussion about not “burying the lede,” in other words, government stakeholders wanted to know what problems service design could solve and what outcomes they could expect. The roleplay was a compelling reminder of how easy it is to get swept up in excitement around process, and lose track of what is meaningful outside of the service design community.
Photo provided by the Service Design Network
