If you’re anything like me, you love to watch sunsets. While the sun may be going down like it always does, there’s something unique about each, whether it’s the composition of clouds, the mixture of colors, or the company you are with.
Sunsets in technology — the planned phase out of a product, service or policy — are similar in that vein. Each has its own challenges and contexts, but they all boil down to the same thing — something is going away.
If you’re a UX Designer or Researcher, you may be involved in sunsetting a product, especially if features or services from a legacy product will be transitioned to a new application.
Currently, I’m involved in a project with a government agency as they’re phasing out 4-5 legacy applications and consolidating them into a newer available application. A user could interact with only one or maybe all five in this lineup. Each of these old applications was designed to help users submit and review forms for eventual decision-making. These also aren’t just any old forms. These forms and the data provided in them play a foundational role in running Medicaid programs for millions of people across the country.
The challenge, though, is that all of these applications differ from each other significantly in everything from interface design, information hierarchy, user flows, and navigation. Consolidating these services that people have become accustomed to is no easy feat. Transitioning services into this newer application without intention and without input from stakeholders, and especially from users, could have unintended negative effects on running Medicaid programs nationwide.
With so many differences between applications, UX Designers and Researchers can play an important role to prevent disruptions to users’ workflows as products are sunsetted.
Below are some of the steps I worked on to sunset one legacy product in particular and transition its features to a new application altogether.
Clarify your agency’s or business’ goals, timeline and risk tolerance
Asking why an agency is sunsetting and consolidating systems helps your team ensure that its recommendations align with the agency's goals.
It’s also important to understand time constraints including when certain services from your legacy system must be available in the new system. Proposed timelines assist in estimating how much time you have available to conduct, analyze and synthesize research into actionable insights that enable your product team to conceptualize and develop features in the newer system.
Similarly, when presenting prioritized recommendations of features to integrate (or not to integrate) into a new product, it’s important to understand how much information stakeholders require before making a decision. Is talking to small samples of users enough for the agency to accept your recommendations, or will they only feel comfortable after polling hundreds of current users? Different kinds of information-gathering require different levels of time and effort.
Identify your inventory
Before interviewing users, our product team identified the features that were only in the legacy application, the features that were only in the new system, and what features overlapped between the legacy application and the new system. I focused the research on features only available in the legacy application. I needed to identify which of those features users interacted with, which they didn't, and assess the importance of each to their work. It was as if the organization was down-sizing from a richly decorated mansion to a small, furnished apartment. We needed to assess their belongings to see what they could leave behind and what was important to move into their new home.
Facilitated feedback activity for user engagement
Without product analytics with application usage information for the legacy system and without the resources to survey a large number of users, we opted to interview a small sample of users.
The legacy system comprised two main workstreams: a submission workstream and a form review workstream. We made sure to speak with both Submitters and Reviewers, about their experience with each workstream and the features each offered.
During each interview, I facilitated an activity called the $100 Game. If you’re familiar with dot voting, the $100 Game is the same activity except instead of dots, interviewees vote on features with metaphorical money. To facilitate this activity, I showed each interviewee a picture of screens from the legacy system with different features highlighted, which were not yet available in the new system.
Then I asked them to move through the board ascribing a value to each feature from $0-100 noting what they used and what they didn’t. Users were not forced to spend the whole $100, which might skew and over inflate their valuations.
I compiled the information into a spreadsheet and generated graphs that explained how many users ascribed any value to a particular feature and the average and median value they ascribed. The graphs illustrated what this sample of users found valuable and how much value they placed on it.
Stopping at quantitative information wasn’t enough, though. For instance, one interviewee noted that a certain feature in the legacy system was integral to her work, but it also caused her undue burden as deadlines approached. This information was important to pointing out opportunities product development teams could address as they conceptualized the feature in a new environment.
Analyzing how much users valued this feature in comparison to others helped me prioritize a list of features to integrate into the new system. Understanding users' challenges with each feature allowed me to craft user stories for product teams that emphasized the value the new system would need to provide while identifying the challenges the new system would need to prevent.
Signals over certainty
When I started this project, I was so nervous about the size of the sample we were speaking with — 10-15 users for a product supporting hundreds. Would it be enough people to know what features we needed to transition? Would these insights be true?
What I learned is that being a user researcher is not about absolute truths or unequivocally validating or disproving assumptions. For this current project, I leveraged signals that came from Medicaid policy experts and the $100 Game results to guide recommendations for which features to integrate into the new system and in what order.
Limiting the time for deciding which features to transition was more helpful than endlessly chasing an illusory truth. Improving a product is ongoing, and a team can adjust its approach as more information is identified.
When everything is important, nothing is important
It can be nerve-wracking to prioritize features to transition from a legacy system to a new application. Throughout my experience on teams sunsetting products, I feared leaving some features “behind” while other features integrated into new systems might lead to a disastrous user experience.
However, this work reinforced to me how much easier it is for a project to gain momentum when you have clear constraints and priorities. It’s easier to integrate features to a new system when you understand what to build first, what to build later, and what doesn’t need to be built yet, if at all. Trying to migrate every feature from the legacy application simultaneously into the system would require understanding the policy intent, logic, user requirements, and technical aspects of all features all at once, making the process cumbersome and challenging for product teams to manage and deliver.
Like real sunsets, sunsets in technology happen incrementally. Integrating features from a legacy application to a new system works well when product teams take the same incremental approach. In the words of systems theorist John Gall, “A complex system that works is invariably found to have evolved from a simple system that worked.”
