As part two of a series reflecting on the Principles of Digital Development, this post focuses on “an example of one or more challenges or barriers” to integrating the Principles into our work. (Read part one here.)
_______
Recently, I found myself at a development conference in conversation with a woman who worked for a multilateral aid agency. We were discussing an introductory user-centered design workshop she had just attended, where the organizers had passed on a library of design tools for participants to take back to their organizations. This donor was particularly excited to apply a mighty design tool, the user persona, to the work she does, and I was particularly excited to hear her singing praises of a design-driven approach.
As a service designer with a practice grounded in user-centered design (UCD), I am glad UCD continues to pervade the development sector. It is a powerful method that can help build more impactful solutions; that’s why Reboot is proud to endorse the Principles of Digital Development and uses design-driven methodologies in our work. But, more often than I would like, what surfaces in discussions like these is the development sector’s over-reliance on the products used to operationalize UCD—the guiding principles, tools, and templates—and an underappreciation for the process.
This affinity for productization makes sense. It democratizes user-centered design and makes it accessible to any organization. But extracting tools from the process may yield the UCD method meaningless—and it makes us wary of potential backlash.
Our organization often works shoulder-to-shoulder with implementing agencies, service providers, and policymakers to design new approaches to development, and demystifying the design process is vitally important to us. As outside collaborators, we work hard to ensure our partners don’t just get excited about the products of user-centered design, but also understand how to use them in practice.
This past October I traveled to Elgeyo Marakwet, a small county in Kenya, about an hour-long plane ride northwest of Nairobi. Elgeyo Marakwet is one of five pioneers in the Open Government Partnership’s Subnational Pilot Program that Reboot has supported to bring citizen voices into the creation of a transparent, participatory, and accountable government reform agenda.
As we began our collaboration with the county government, we took time to understand current open government priorities and looked for ways to build on to existing initiatives. Through exploratory interviews with government staff, Reboot quickly discovered an opportunity for the communications department to increase citizen participation by formalizing an existing, but informal, channel of communication between citizens and the county executive.
Our partners explained that staff at every level—from the Governor to department directors to frontline service providers—had been giving their WhatsApp numbers to citizens, and receiving all kinds of feedback in return. Citizens sent WhatsApp messages to alert government staff about health clinics that needed restocking, unsafe bridges that needed repair, and government contractors that were behind on civic projects—all incredibly valuable information that would have been expensive for the government to obtain through other means.
Effectively, a citizen feedback and monitoring network had developed organically, at zero cost to the government. The downside of this informal channel, however, was the government response. Staff struggled to keep up with the cascade of new information, and many requests were left unanswered because citizens did not always provide adequate or actionable information.
In all of this complexity there was a clear opportunity to use this feedback to improve service delivery and promote government accountability by designing a set of internal protocols and organizational processes around WhatsApp. Rather than building a public services feedback and issue tracking system from scratch, we would help the government find a way to more constructively collect, filter, direct, and respond to the feedback that was already flowing in.
Commonly in UCD approaches, a team of external design experts takes the lead on solutions like these. Guided by sound principles like “Design with the User”, the team gathers inputs from key users and synthesizes this data—using design tools like user personas—to “develop contextually appropriate solutions informed by user needs.” But here’s the hitch: the designers usually end up retaining control of the actual design process, missing a key step to ensure solutions are owned by the users they are designed for.
Getting a solution to really stick often requires continuous adaptation and iteration, most of which happens after outside design teams, like ours, go home. This is why, whenever possible, we make sure our partners are part of the team from start to finish. No matter how hard a team has worked to design solutions that learn from and enhance existing workflows, when we design in this vacuum, we fail to provide implementing agencies the right skills to test and adjust this solution over time. In my work, I have found that this knowledge is not learned by handing over templates or prescribing a set of principles to follow, but by teaching implementing agencies to use these tools and principles in relation to a design process.
In Elgeyo Marakwet we decided to do just that. The Communications Department and I worked through a three-week user-centered design training as a model for how a design-driven approach could apply to their work. Rather than teaching user-centered design with a fictional problem—which can come off as trite or non-transferable—we focused on helping the team apply the design process (complete with tools, principles, and templates) to this feedback problem they were already struggling with. Our shoulder-to-shoulder collaboration was intended to create both a more contextually appropriate solution and to embed a philosophy of testing and iteration within their day-to-day workflow. I brought my experience and design expertise; but they solved the WhatsApp feedback challenge.
Though the results proved stronger in the end, leading this group of passionate government innovators through the design process also added an additional layer of challenges for both parties to sift through.
I needed to achieve a delicate balance between designer and teacher. I had to rapidly synthesize data about current WhatsApp norms to get up to speed with our partners, while also letting go of some of my initial design hunches to ensure the team was guiding the direction of the solution. For our partners, they had to learn how to tinker with a system that they themselves were embedded in. They needed to see past their own perspectives and understand from a bird’s eye view how the system operated.
For example, I began a lesson on the “Discover” phase of the design process with a discussion on how different people might use technology in a variety of ways—which would affect anything we designed. Through this discussion, staff quickly saw that they carried strong assumptions about how citizens and civil society groups use WhatsApp. Their assumptions were influenced by their past experiences and narrowed to their own perspectives—instead of a true understanding of how these other actors behaved.
As designers, we constantly discipline ourselves to check our biases to develop a holistic understanding of context; but what about addressing similar misunderstandings within the agencies that are implementing solutions? Working through the design process allowed our government counterparts to develop the skills to see past their perspectives and biases.
Developing these skills takes practice. Through the three weeks, government staff got a chance to conduct ethnographic interviews with government service providers. They got to hear from from citizens and civil society groups who also use WhatsApp to gather and organize citizen feedback. They got to ask detailed questions, analyze what they heard, prototype solutions, and revise those solutions based on additional rounds of interviews with their colleagues and citizens. Each step of the process allowed them to gain experience in these skills while also widening their understanding of what was possible.
The final product—a revised process and internal protocols that ensured departments were empowered to respond to citizen feedback and integrate it into future service delivery—was more versatile and better suited to the context than anything an outside team alone could produce, no matter how much time they took to understand the problem, the users, and their constraints.
