TL;DR Summary

Path is a web application developed to aid Humana's telephonic sales agents in navigating Medicare insurance plans and processing enrollment applications efficiently. With agents often managing multiple software tools during their eight-hour shifts, Path aims to streamline their workflow by delivering timely information, minimizing reliance on outdated systems. Initially launched as a Minimum Viable Product (MVP), Path's success during the annual enrollment period prompted plans for further scaling. I conducted surveys and user research to identify areas for improvement post-MVP. Feedback highlighted issues such as incomplete product coverage, cumbersome plan listings, and the absence of essential features like application lookup. Through iterative research and user interviews, the team sought to refine Path's functionality and address user concerns. I tested key assumptions regarding agent preferences and usage patterns, guiding subsequent enhancements. I developed and tested prototypes to gather feedback on proposed changes, leading to insights into user expectations and preferences. The team prioritized feature enhancements and usability improvements based on these research findings, aiming to make Path the primary tool for all Humana telephonic sales agents.

The Product

Path is a web application built for Humana’s telephonic sales agents to view plans and process electronic enrollment applications for medicare insurance. Humana’s sales agents are licensed state by state to sell and have strict compliance guidelines they need to follow when speaking with customers. They typically have to juggle a number of software applications in order to complete each call, balancing between google searches, internal applications, and Microsoft Excel spreadsheets to deliver the correct information. Agents are on the phone eight hours a day while using these software applications. Path was started as a way to streamline the viewing of plans and applications to better match the conversations agents were having with customers. Path accomplishes this by delivering the right information to the agent at the right time, reducing the back and forth they need to do on Humana’s unreliable legacy systems.

*An example of a legacy application that agents typically use.*

The minimum viable product (MVP) version of Path was launched just prior to our annual enrollment period (Oct 15–Dec 7) when most Medicare customers would be switching or signing up for new medicare insurance plans. The product team shifted from pushing new features to production to a support role for the approximately 100 agents that were part of the pilot during that time.

Post-MVP

I joined the team in January to support a roadmap that had its sights set on scaling beyond the pilot. Our goal was to support the rest of the 1300 telephonic sales agents at Humana for the following annual enrollment period next October. I served as a member of a product team that was a Humana/VMWare collaboration consisting of a product manager, two designers, and four software engineers. Telephonic sales agents are responsible for a large majority of Humana’s plan enrollments and our work was aimed at supporting those agents in assisting customers in learning about, shopping for, and enrolling in Medicare plans.

*An example of one of our agent personas*

The team conducted a survey of all participating agents following the pilot, and began to identify areas that we would have to explore in order to make Path a more mature offering. During annual enrollment, the number of agents using it expanded beyond the initial pilot when another internal legacy app went down during a crucial time for enrollments, but agents were looking for some additional changes before they could commit to using it full time. We followed up our survey with user research and uncovered a number of items for improvement including:

Path didn’t support all of the products that Humana agents are authorized to sell such as Medicare supplements, or add-on optional supplemental benefits
Agents felt that the listing view of the plans required too much scrolling to view all the available options
Path did not offer the ability to look up a previously submitted enrollment application, which was key to troubleshooting customers' concerns when something was wrong.
For agents who were not part of the pilot, they felt that the prescription drug tool was not something they could trust as it produced different results from a legacy tool.
The ability to create a list of medical providers was valued, but the search function was confusing, and lacking in certain functionality

User Research

With the understanding that our team’s focus would be shifting in the next few months, we worked with our product manager to prioritize research and changes to the interface in order to help ensure that it becomes the primary tool for all of Humana’s telephonic sales agents. One of our research iterations was focused on identifying what could be improved with our medical provider search tool.

*Results displaying in the provider search tool*

Our research iterations on Path commonly took the form of five interviews per week, consisting of a broad selection of agents across the country conducted through Zoom. The Nielsen Norman Group notes that this interview volume is an industry best practice, exposing approx 85% of software issues. With iterative research, if you miss a problem with this round, you can always expect to find it next time. This time we focused on agents who had not necessarily been trained on the software to better understand where things might be falling short with them. We focused on qualitative research at this time since our survey results led us to the understanding of what was happening in the product today, and with our interviews, we would be able to probe a little deeper and understand why.

Interview

We started agents off with a few softball questions to get them talking, and to build rapport. We asked them how long they had worked for Humana, establishing whether they were a tenured agent. This fact gave us some additional context into their relationship to the technology they used; longer-serving agents were sometimes more resistant to taking on newer tools and tended to stick with what they knew best. We asked them what their favorite aspect about being an agent was as well. No surprise, they loved helping people solve problems with their insurance and finding solutions that worked best for them. And their least favorite thing, no surprise again, Humana’s technology was unreliable and unusable, a clear opportunity for our team to champion Path as a solution.

We asked our agents to share their screens and bring up the application and then presented them with the following scenario, “Talk us through a time you recently had to look up a medical provider for a customer in Path. Using Path, show us the steps that you went through.” This got them into the mindset of showing and telling, allowing us to see how they were using the software. We also asked them how these conversations tended to go, what information they needed from the customer to perform a search, what situations tend to work well, and which ones are more difficult. Agents were prompted to explain what steps they commonly took to mitigate more difficult situations.

Key Assumptions

In planning our research we identified our key assumptions that were important for us to learn about in these sessions, they were as follows:

Agents want to be able to search by address and phone number
Agents are unable to discover the sort function in its present location
Medical provider search results should be default sorted by distance, not clinical quality
Website links are sufficient for agents to find medical providers with large networks (known as JOA)

*Our assumption tracker, a table in our collaborative whiteboarding tool, Miro.*

By key assumptions, I mean ideas that we assume to be true about our agents’ relationship to our product. It is important for us to list these out distinctly from the rest of our discussion guide so that we ensure to collect data on them because without enough data, we run the risk of having to run our research again to ensure that we are indeed tracking some kind of trend, rather than making decisions based on an individual’s experience or opinion.

Prototype

Following that, we showed users a very simple form prototype to gather some final data on our assumptions. Originally, our provider search combined both a name and specialty search into the same field, displaying results based on some ideas around how users had originally said they always wanted to know which doctors would be closest to the customer, thus they defaulted to sort by distance. This prototype differed by clearly separating our name and specialty search and including address and phone number as an option for matching results. Additionally, the sort function was moved to a spot in the user interface that matched everyday user experience patterns rather than a place in the search form where users seemed to be missing it.

Results

*Our board for tracking and categorizing our qualitative research*

In terms of tracking our key assumptions:

We confirmed that agents wanted to be able to search by address and phone number.
And that they were unable to discover the sort function.
We learned that while they loved being able to see the website links, they weren’t quite sufficient for our agents.
And finally, we learned that our search and sort did not match up to the mental model of the agents. When searching for a doctor’s name, they rightfully expected that a direct match of the doctor’s name would produce that name at the top of the result, while still expecting that when they searched for a specialty, the closest doctor would be at the top as well.

Additional findings:

There are two clear use cases for using the medical provider search tool: 1. Finding a specific doctor for a customer to ensure that they are covered by our insurance plans, and 2. Finding a new primary care or specialist for the customer that is close to them and high quality.
Our tool’s results did not always line up with that of other Humana tools.
Customers are often looking to find a doctor that speaks their language.
Virtual care providers show up in the results with no address as the closest option for customers, even if they are looking for an in-person doctor.
Customers often go to a practice group, or hospital for care rather than an individual doctor.
Customers are looking for providers that offer virtual visits.

General Product Feedback:

Agents who weren’t trained to use our prescription drug pricing tool were not aware that that feature existed, or that it functioned in a similar way as a legacy tool.
Agents want to be able to sell stand-alone dental and vision plans through Path.

Next Steps

*Our team’ prioritization exercise in Miro*

We shared our research with the team, identifying a number of changes that could be made to the tool to better our agent's ability to serve customers. Following that we facilitated a prioritization exercise on those changes. We walked our engineering and product management counterparts through each of these new ideas and charted them in order of how feasible it was to build on a scale of easy to hard. Easier items were added to our backlog along with new designs, and the more difficult ones were assigned to our engineering team to assess feasibility for how we might tackle them in the future. Here was the final result:

Path