With the growing traction of design in development, a number of commercial firms have recently released “toolkits” aimed at guiding practitioners and donors in applying design tools to public sector projects. Some of these guides are good. But many seem…shallow. Development practitioners looking at these colorful PDFs may wonder whether such prescriptive methods can actually work for the interconnected problems that development addresses.
That’s not to say we don’t rely on design tools in our work at Reboot every day; we do. We know that they are useful when researching, understanding, creating, and implementing solutions that are responsive and appropriate—but only as long as the tools are used thoughtfully. And that’s the problem with many of the toolkits available today. When the process is codified in a static “toolkit,” it’s oversimplified. Design should be, by definition, tailored and customized to each project or activity’s context and needs.
I’ve spent a good amount of time dissecting guides and toolkits as a social scientist, a development practitioner, and as a designer: using them, critiquing them, writing about them. The number one weakness I observe is that they encourage reliance on the tool as the answer, rather than as a framework for thinking through complex information and the principles to know how to understand if your approach is helpful or hurtful.
As Reboot has developed a series of internal training manuals, and been approached with requests to productize our methods, we are thinking deeply about these challenges: How do we articulate and teach the idea of a tailored process that requires customization every time? How do we embed principles and values in replication of design tools?
One way to resist the over-simplification is to see the tool in action, as part of a tailored approach to a specific project. And so, in that spirit, I’d like to share how we’ve used a particularly common design tool—the user persona—in our work, in different phases of the project cycle.
User personas are one of the most iconic tools of human-centered design. A persona is a narrative based on real people; it’s a composite of multiple people with common traits and stories. As a detailed description of a typical person touched by a project, it helps to conceptualize its different “users.” Creating and working with personas allows designers to think about a problem from users’ perspectives and spot the patterns and themes in qualitative findings. The actual content of a persona will vary widely depending on the project; it may describe, for example, a person’s dreams, daily routines, childhood upbringing, or technical capacity.
Many commercial designers rely on user personas to help define their target audience when creating a new product (the tool’s inventor, Alan Cooper, was trying to make computers easier to use). In development projects, the narrative power of personas to build empathy and bridges between designers, donors, and beneficiaries is especially important, and can be deployed for a wide range of goals. Here are just three ways we’ve used personas in our work:
We created a series of user personas as part of an ethnographic research study to support program managers at a bilateral aid agency in using data more effectively. We needed to understand the kinds of data needed (and why), and the reasons current data practices were insufficient. Crucially, we needed to understand these issues from the viewpoint of the program managers themselves.
As a research team, we created “low-fidelity” user personas, rough drafts that can be made quickly (as opposed to polished, high-fidelity materials shared with people outside of the research process). Written on three-by-two-foot paper sheets, the format made it easier for our research team to collaborate as we organized details and sorted evidence across more than 40 interviews.
Here’s an example of what they looked like:
In addition to the large paper format, we tailored the content of these personas to this project. For example, we included sliders to compare different users on a spectrum of binaries, such as “power and influence,” “access to information needed,” and “tolerance for risk.”
This isn’t the only way to create and use a user persona; in fact, it wasn’t even the first we tried for this project. In the first set we created, we focused on users’ professional roles, which created some confusion and distracted from the key issue of users’ data habits. That subtle framing change made a big difference, because it helped us focus on the specific differentiations in habits and motivations in their data use behavior.
We’re currently using these personas to surface new questions to be explored through further research, and to organize evidence to support or disprove a variety of hypotheses about how institutional policy and individual capacity affect data use in development. We’ll continue to modify and return to this framework for categorizing our information across different data-use habits.
User personas are helpful for clients and stakeholders to connect with unfamiliar beneficiaries. “Building empathy” is a commonly cited benefit of a user persona, and persuasive narratives from a user’s perspective can help others understand the necessity of certain design decisions.
For example, for our recent My Voice project, we needed to account for the practices, habits, motivations, and barriers of not only patients, but of local health center staff and policy makers who would also use the feedback platform. We knew that a number of design decisions informed by our research would not necessarily make intuitive sense to our clients, in high-level directing positions back in the States. For example, language comfort and preference drove our decision to phrase questions in ways that seemed awkward to the US English ear, but were common and comprehensible for the primary beneficiaries of the tool.
So we created user personas to vividly illustrate the specific needs and desires of each of our primary users. In contrast to the previous example, these were high-fidelity, professionally-designed, and polished. They told long, in-depth narrative stories and were accompanied by photographs of representative people (who had given permission). They included sliders to indicate how fluent users were in mobile use, how much access they had to internet, their level of education, and the amount of institutional decision-making power they had. Here’s what they looked like:
In this case, personas helped decision-makers connect with the mission behind this project rather than looking only for aggregated numbers on participation rates. What does a young pregnant woman in Wamba, Nigeria need from an SMS feedback tool? Personas can powerfully communicate the human element of design decisions. But it’s important that personas portray audience segments with dignity, and that they are rooted in evidence (instead of exaggerated storylines that beg for pity). They should be a reflection of diligent listening and humble interviewing; it should be their story, not a designer’s imagination of their story.
Going through the hands-on process of building user personas can help people learn about fellow colleagues’ or project beneficiaries’ experiences and needs—and question their own assumptions—in a way that only reading a designer-prepared persona may not.
For example, we recently held a workshop with executive-level government officials—primarily government outsiders, with experience in business or tech sectors. While they were excited by the potential of government innovation, many believed that government processes could be more efficient, and saw their engagements with their colleagues in various government ministries challenging at times: key interaction points that could be more productive.
Using selected interview excerpts, workshop participants built out low-fidelity personas of their ministry colleagues, with names, titles, agencies, how many years they had worked in government, why they chose to work in a particular ministry, their skills, and their frustrations. These short narratives painted a holistic picture of their colleagues’ daily work experience, from their colleagues’ perspectives. Many participants were surprised to face their own assumptions in the final product, an experience which challenged them to see their colleagues as potential partners with shared goals and frustrations.
There are competing opinions about the effectiveness of user personas, but in our experience, they have been especially useful for projects in the public sector, where building empathy and protecting the dignity of beneficiaries is vital, but made difficult by politics, distance, limited resources, and competing priorities.
Good development practice requires a thorough understanding of players across an ecosystem from beneficiaries and communities, to service providers, to institutions and donors and other powerful decision-makers. To design programs that function and can be sustainable within these complex ecosystems, an understanding of interactions between users and the influence of policies across all involved is critical.
Tools alone have no magic power to help us solve all development challenges or generate empathy in every tricky situation. But when rooted in respect for others and a belief that designers are first and foremost facilitators of ideas for the people we serve, design tools like user personas are a first step to understanding these complex ecosystems of interaction and influence, as they challenge our biases, and build empathy and understanding.
__________
Have a question about putting user personas to work for you? Leave it in the comments.
