When I approach problems as a UX designer, my first impulse is to hypothesize potential solutions. I hold those hypotheses loosely as I learn more about the problem to be solved and adjust accordingly, but they inform my initial thinking. Normally, I find this approach helpful because I am able to brainstorm potential constraints and use those as a baseline to begin testing my assumptions. However, this past year during my work with New York City’s Mayor’s Office of Operations, I was confronted with a landscape so complex that I had no choice but to proceed with a completely blank slate.

As part of the 11-month Code for America fellowship, my team was tasked with deploying tech-related solutions for New York City social workers. To identify existing problems and create solutions for those problems, we needed an understanding of the day-to-day processes of our potential users. Most of our work was done remotely, with monthly visits to New York City to conduct research and meet with stakeholders.

The government agencies we were working with were in separate silos and difficult to penetrate. As the research leader, my main goal during the research and discovery phase was to gain a baseline understanding of the agency’s goals, the social workers’ pain points, and the experiences of New Yorkers interacting with the agencies and social workers. We knew that without a good understanding of the policies, processes, and politics of the agencies we were working with, any potential solutions my team developed would be a shot in the dark. In addition, we needed this knowledge to demonstrate to our stakeholders that the decisions we were making were rooted in an understanding of our users. To this end, one tool that proved immensely useful was journey mapping.

Understand and Define the Context of Users

Our discovery phase in New York consisted of interviewing and shadowing more than 50 social workers, administrators, and support staff (see Figure 1). I created an interview framework that involved asking open-ended questions to gain an understanding of participants’ goals, frustrations, and process failures. I also established a process for creating journey maps from the information collected during the interviews (see Figure 2).

Figure 1. User interviews helped create the journey maps. (Credit: Molly McLeod)

For the first round of the interviews, I drew a rough flow of the processes the participant was describing on an 11″ x 17″ sheet of paper. As I drew, I would repeat out loud what I understood the process to be. Once I outlined a basic structure, I gave the map to the participant with a pen and highlighter, and I invited them to make corrections. I also asked questions about areas where I noticed process breakdowns or wanted more clarification.

Once the rough sketches of journey maps stabilized, I converted the sketches to a more polished document to share with participants at the beginning of the second round of interviews. When I walked into interviews with the journey map as I understood it up to that point, I gained the trust of my participants immediately. They saw that I understood what their day-to-day looked like in detail, and we were able to move quickly from high-level explanations to more nuanced conversations. My team and I could find specific, measurable, tightly-scoped problems to fix. In addition, I was able to use the map as a visual aid to ask questions about specific parts of the process. In short, the journey maps established a shared language for myself and the interview participants.

Figure 2. A flowchart of the process I used to gather information for journey maps. See the text in the image.

Create Shared Understanding with Stakeholders and Foster Empathy

Parallel to the participant interviews where the journey maps were being refined, my team and I used the maps as valuable data in meetings with people who were responsible for running existing technology systems, shaping policy, and making overarching decisions for the agencies we were working with. Because they were not social workers dealing with clients on a day-to-day basis, they didn’t have a clear understanding of the minutiae of service delivery to clients. The journey maps were critical for helping establish a better understanding.

When presented with journey maps of the ways in which social workers navigate social service agencies to help clients, the people we were working with were given a clear, digestible understanding of what a social worker’s job looked like. More importantly in our case, the engineers we were working with could see how and where the tool they had been maintaining was used and the problems it helped solve. It fostered a sense of empathy for the user, pride in the technology, and a common understanding of the challenges social workers faced in their work.

The process shortcomings uncovered by the journey mapping exercise were a helpful starting point as my team was learning the general histories of the agencies we were working with. There was so much context my team and I were simply missing, and the journey maps helped guide our questions and fill in the blanks. Many of the issues my team wanted to address were infeasible due to political and policy-related constraints, and understanding that as soon as possible was crucial to finding an effective solution that could be implemented efficiently. We used the journey maps as a starting point in our stakeholder meetings to narrow our problem scope and to prioritize features.

Feel Empowered to Act

By the end of our discovery period, we had a solid understanding of the landscape we were working in and the constraints we faced. I’d also stopped complaining about those processes being so complex. Through our research, we learned why processes were muddled and why teams were siloed. We also got to know the people behind the people making our government work day-to-day and developed a sense of empathy for the challenges they face.

Our newfound knowledge didn’t necessarily make the project any less challenging, but it did increase our confidence and helped attain buy-in from users and stakeholders alike to make changes to an existing and well-liked tool. Overall, journey maps shaped the course of our fellowship year by giving us a strong base of understanding before we jumped into defining solutions. They helped us understand the landscape we were working within.

We went on to redesign a tool that social workers in New York City use to conduct research and help clients; the journey maps gave us context on the environment and processes the tool is used within. It also convinced us that we chose a valuable problem to work on. We learned that the point in the journey where this tool was used was a research-dense time for social workers. We realized that if we could improve the speed and accuracy of the research social workers do to help their clients, they would be able to help more clients, and it would ease their cognitive load.

Lessons Learned

I imagine myself using journey maps again in the future, but I would shy away from creating a polished document to depict my findings. I found that many people were swayed by the visual appeal of the flows into initially thinking that processes moved smoothly. In our meetings, it was only after a walkthrough of our findings that the process failures and systemic issues were made clear.

In my later interviews, I also found that participants were less likely to mark up the document. Though many agreed with the process being described, I feel I missed out on learning about smaller details by presenting folks with a polished diagram as opposed to a rough drawing perceived as more disposable.

Journey mapping is not a panacea, but it makes the process of learning a new, complex environment faster and more procedural. It also allowed me to provide value to my stakeholders as a researcher while still spending time learning the landscape. The stakeholders we were working with had uniformly positive reactions to the documents we created because they found the information valuable for both their general understanding and day-to-day work.

Topics: User Research, Government, Service Design
Published in: April, 2017 in Politics and Design