By Kristen Lohman, UX Researcher and Designer, Flexion
When modernizing a legacy system, it’s easy to recreate what exists and make it just a little better. This can be an especially dangerous trap when users equate what they think they need with what they already have. But what happens when your users don’t understand why they’re doing things a certain way?
One of our large federal clients needed a new case management system. They did things in a certain way and held tightly to the belief that it was the best way to do things, even when they didn’t always understand why.
Think of it like this: You want chicken for dinner but it’s frozen. In your family, you always thaw your chicken by parking it for hours in your microwave. Why? You’ve never asked, until now. Turns out, it was because your grandmother had a cat, so the chicken couldn’t be left on the counter because the cat would eat it. So, Grandma “stored it” in the microwave, without even using the “defrost” setting.
You don’t have a cat. You’ve never had a cat. But you’re still thawing your chicken like Grandma when you should be thawing it inside the refrigerator according to contemporary food handling guidelines. In other words, your chicken thawing procedure is a legacy practice that no longer makes sense.
In moving our client away from legacy practices, we had to not only discover what their legacy practices were, we had to help them recognize and break their habitual behavior based on these practices.
Our goal? To get them to thaw their chicken in the refrigerator.
The Project and Challenges
Our client is responsible for handling specific government interests on behalf of United States citizens living domestically and abroad with a footprint in seventy-three cities across the country. The average tenure of current employees is 11.5 years, meaning that their processes and systems are highly ingrained and a part of this organization’s culture. Employees are dedicated not only to the agency’s mission, but to their well-established practices and procedures.
In 2017, their 30-year-old case management system was reaching end-of-life, and the agency decided to take a leap of faith and explore other vendors and the opportunities of working with open-source software. Enter our team. We were tasked with building a new system that encompassed all the agency’s needs.
This project came with many of the standard challenges common when replacing a legacy system: disparate applications, complex workflows, system ownership from long-time users. In addition to these hurdles, an airtight Non-Disclosure Agreement (NDA) prevented our team from seeing any part of the current UI or any system data. We were completely reliant on our Product Owner and the users themselves to tell us what they needed. But what if the users don’t really know what they need?
How Habits Become Dogma
Agency staff had been using the same system for over 20 years, and system limitations, antiquated paper processes and ingrained institutional silos dictated how they did things. When the legacy system launched, it was based on their current paper processes, many of which already had inefficiencies. These antiquated processes coupled with the technical limitations of the system forced employees to get creative to accomplish their complex work tasks, inspiring agency employees to create troublesome workarounds. These workarounds, while solving immediate problems and allowing work to continue, did not remove the actual obstacles that were the cause of so many problems. Although the agency machine kept running as expected, these underlying issues remained, sometimes invisible to the larger organization. The institutional silos within the agency contributed to a lack of transparency, making it difficult to identify these workarounds as problems worth solving.
Over time, new employees inherited these workarounds without the benefit of knowing the history of these convoluted processes. In other words, they weren’t aware there had ever been a cat in the thawing chicken analogy.
In researching current processes and trying to uncover user needs for the new system, our team was often prohibited from knowing the real problems these users were trying to solve or the specific tasks they needed to accomplish. There were requirements such as, “The system needs to integrate with label makers,” without an accompanying explanation as to why label makers were necessary.
By digging deeper into agency processes and history, we learned that they didn’t need label makers at all. The use of the label maker originated as a workaround, solving a problem that no longer existed. They had started printing labels for two main reasons: 1) the legacy system didn’t print addresses with documents; 2) they didn’t have windowed envelopes. Given these circumstances, using a label maker was easier and more efficient than writing addresses by hand.
But we were building a new system from scratch that could (if we wanted) print the address with the document, eliminating the need for any third-party integration. This understanding wasn’t that easy for agency users to comprehend. It was even difficult for them to simply articulate why they were doing things, other than to say that was the way they had always done it. Like in the chicken parked in the microwave scenario, the cat (in this example, the system limitation) was gone, but they were still operating as if they were under the same constraints. Our job as researchers is to take the cat out of the equation and discover the real problem.
Barriers to Change
Every industry has its own jargon, and it’s a challenge we anticipate when we begin to learn about users. This agency spoke its own language of complicated terms, deceptive common phrases, and personal jargon that was completely foreign to us as outsiders. Simple terms like “calendar” had very specialized meaning, and it took several iterations of interviews for our research team to uncover what they really meant. When we heard “calendar”, we assumed that meant the type of graphical calendar that fit our mental model; what the agency meant when they said “calendar” was an arduous process consisting of printing and reviewing (and re-reviewing) many reports over several weeks to end up with a final list of actionable items. This type of jargon (along with the fact that the NDA forbade us to view any of the things they were talking about) made it easy for us to misunderstand and misinterpret their needs during the beginning of the project.
The organization of the agency was intentionally siloed, and we struggled with getting a full picture about how the life cycle of the work product was managed. Each section of the agency had their own processes and often used a different module of the legacy system to do their work. This meant that different sections of the agency were, by design, functioning without any information about how other sections worked. Not only were users unsure of exactly what other departments did, they sometimes disagreed about how things were (or should be) done. As outsiders looking in, we could see things employees couldn’t see.
The silos at the agency and the longevity of its employee base helped create resistance to change, which is common when modernizing an old application. Some employees who helped build the original system were still working, and there was a proud sense of ownership not only of the legacy system but also some of the underlying processes. We knew we had to build trust with the agency. We were there not to replace them, but to make their lives easier, from top stakeholders to everyday users.
An often-overlooked barrier to innovation is compliance with laws and regulations. We could build good relationships with the agency and produce innovative design concepts, but we were still bound by existing rules and had to pick our battles strategically when fighting for change.
How to Overcome Barriers
We were up against many challenges both internally and externally (including working during the height of the 2020 COVID pandemic) with this project. However, using a variety of techniques, we were able to uncover user needs and help solve the underlying problems.
Practice the Art of Listening
We spent hours discussing current processes and how (or rather, if) they related to their ultimate business goals. Over time, users came to understand that they were doing unnecessary work with no useful outcome. Through several long interview sessions with users and using visualization tools to communicate back our understanding, we were able to decipher the real goals behind a decades old process referred to as “calendaring” and distill weeks’ worth of manual work into a single action button.
Listening can be one of the most difficult and most beneficial tools we have in our research toolbelt. Here are some practices we used that may help you get to the heart of the matter with your users.
- Build trust. Create a safe environment for users to share information.
- Learn the history. Understand the circumstances that led to current processes.
- Repeat for clarity. Communicate in your own words to verify understanding.
- Probe without judgment. Listen without commentary or feedback as you learn.
- Allow for self-discovery. Give people space to have their own epiphanies.
Win Users Over
Establishing a positive working relationship with users is crucial to understanding their real needs. After all, “users” are people, and if people don’t trust or believe you, they won’t confide in you. During this project, we collaborated with our users, getting to know them as individuals, as employees, and as end users to our new application. Building these relationships early allowed us to be more transparent and receive more honest and direct feedback. It also helps to have existing trust when needing quick feedback.
Here’s the techniques we used when building relationships with users:
- Be a skeptic. Embrace the user’s skepticism about a new system.
- Explain the “why.” Walk users through why you’re asking questions, how UX works, and that we’re there for them.
- Share, share, share. Involve users early and often in design feedback sessions.
- Build excitement. Let users see the incremental improvements.
- Encourage ownership. Help them see how their needs and ideas are incorporated into the new design.
Uncover Hidden Needs
Because of the highly ingrained processes of our target user group, we knew there was more to the picture than we would see during our initial research. We continued to dig deep and seek out underlying problems throughout the project, even when we seemed to have solved them at the surface level. We used a variety of techniques, including:
- Five Whys. Keep asking “why” until you get to root causes. For us, this took several interview sessions.
- Mixed research methods. Usability testing, 1:1 deep dives, and group discussions helped reveal the full picture.
- Reframe the question. Users can speak more to what they need to do than how they want to do it
- Get creative. Think innovatively, starting with how users currently work and then imagining how they could work.
- Push the boundaries. Don’t let existing constraints go unchallenged.
Even with hours of user interviews, design feedback sessions, and usability studies, we still encountered some surprising needs when our application was demonstrated for users. A couple of months before projected launch, we decided to conduct a cooperative usability study to try to uncover problems during the end-to-end process, problems that would be hidden during our siloed usability testing.
We had developed a messaging feature that met all documented user needs and tested well in all our early usability studies. During this less-conventional study, we had representation from each user group in one room and walked through several scenarios with the whole group present. We found that our well-tested messaging feature was a big ‘fail’ when it came to how all users worked together during a real end-to-end process. Without thinking creatively during this study, we could have launched this feature and learned of its deficiencies way too late.
So, What About the Chicken?
Breaking habits is difficult, and it took persistence, curiosity, and creativity as researchers for us to help agency users tap into their real needs and feel comfortable putting the chicken into the refrigerator to thaw. By building trust over time and continuing to learn (always), we left these users with a new outlook on their goals, processes, and an application that met their real needs, instead of their constraints. In other words, a perfectly thawed chicken.
For the past three years, Kristen Lohman has worked as a UX Researcher and Designer for Flexion, an agile software company delivering excellence to government and commercial clients. With a winding career path that has included customer service rep, technical writer, and caricature artist, Kristen is a UX practitioner who strives to understand complex user behaviors and business processes, while maintaining creativity. She has worked in both large organizations and small startups, championing user research and promoting organizational change through human-centered design. At Flexion, she creates complex workflow applications in the public sector. Kristen’s interests continue to wind into new spaces, including information architecture, designing for accessibility, and service design.
