In 2014, an affiliated national insurer, announced an ambitious goal to redesign and change their benefit system. Their goal was to make benefits more accessible and transparent with providers and members. The change meant changing the entire company's take on benefits.
To comply with a non-disclosure agreement, I have obfuscated confidential information in this case study.
The road to new benefits has taken over three years and work continues today. So far, I have worked alongside a UX team, several project teams and several client stakeholders. All of which included creating a design strategy, designing a benefits-coding system and redesigning a provider portal (the member portal benefits update has not been completed).
This case study covers the projects I have worked on that are related to the new benefits experience.
UX led a research-based approach that lasted more than three months. We focused on delivering a shared understanding to inform future business and design decisions by using a user-centered design process.
In 2015, the benefits system was nearing the end of its life span in the market. Which was initially created in the 1990s. New products were being released to keep up with healthcare reform and the system struggled to keep up. The business was seeking to modernize their capabilities and keep up in a competitive market. Consumer behavior continues to evolve, therefore the insurance market must anticipate future needs.
Our vision for the benefit research initiative was to make sure the client had a design strategy that ran parallel with their business. We called it the runway.
I focused on understanding the breakdown of benefits text, completed analysis of required features for user testing and conceptualized displays for member screens. I worked alongside a UX developer who built HTML prototypes based off my designs. After testing, I co-led the creation of the final test findings to be communicated with the client.
We knew that members struggled with industry-specific jargon. So our first steps were to compare the old language with a new simplified translation. What we did was very tedious, but worthwhile. I pulled data from the old benefits system, worked with a subject-matter expert and translated the verbiage. The text was simplified from high-level reading levels to about 6th and 7th grade reading levels. I did this by rearranging text to have procedure name listed first along with glossary-like explanations that described benefits in layman's terms and shorter sentences.
When we tested and compared verbiage in the first round of testing we validated very quickly that members were looking for simplified and translated text.
Test A - Technical Text Feedback
"The site did not use words that the everyday person could understand."
Test B - Simplified Text Feedback
"I think it was user friendly and really easy to understand."
Task completion scores for technical language finished at around 70% while scores for simplified text finished around 95%.
We also explored new patterns for visualizing data, numbers and percentages. Dollar amounts and totals would be displayed separately as opposed to being surrounded by unnecessary text.
“When I come to this kind of website I am already a little bit stressed because numbers and technical things confuse me.”
In the first round of testing we created a visual panel that displayed family deductible information.
In the second round we reduced the deductible panel to one color, pushed individual members to a hidden expandable panel and removed visual lexicon. This significantly increased user comprehension and reduced the amount of time it took for them to complete specific task.
As we continued testing we did further business analysis on how benefits were grouped and categorized. We found that things were grouped differently throughout the customer experience. Sales and marketing displayed benefits differently than the portals. End users were completely overlooked. The organization missed the opportunity to create a consistent experience from the time an enrollment booklet is opened to the point claims are being processed and paid.
Providers were looking for benefits that displayed what is and is not covered.
“You never want to go in guessing what the codes are and if you have a list of the things that are covered, it is helpful to have a list of what isn’t covered.”
We introduced a search filter feature. Many different keywords were being used to reference the same thing. Similar to how people refer to pancakes, they can be called pancakes, of course, but also flapjacks, hotcakes or even crepes. We felt that a filter would be useful because it removed anything the user didn't want to see. However, it would need to be a smart search to incorporate keywords.
A quick look to the future – through a conversation with customer service stakeholders we created a repository of consumer friendly keywords. They had plans to implement a new tool that would record conversations and convert it from speech-to-text. We could pull out the data and find ways to collect commonly used or unique words. Customer service is pushing forward with the solution, but the update will need to happen in the future.
The findings were shared with key stakeholders within our client's organization. The impact of our research has not been fully realized, but it has been shared in project kick-offs and referenced by multiple stakeholders during project meetings and collaborative sessions.
As we improved the member experience we found that the provider audience appreciated the same changes. We initially thought that providers would be power users and have different needs. When in fact it was the complete opposite. Office administrators usually have no formal training and typically question the doctor to learn.
Our client wanted to move from green screens to a modern dashboard where the new, easier to use, benefit data could be displayed. The data transformed from long paragraphs of text to individual chunks of meaningful data.
Redesigning benefits data to be accessible was a large architecture and design problem. The architecture team spent over a year working with benefit coders to understand the system and come up with a better solution. I was added to the project after the initial year as the sole UX designer to design a new interface for the benefit coders.
To help the client understand our benefits process we used the analogy of a restaurant. The restaurant is split into a kitchen and dining area. The consuming applications coming later would represent the dining area. For this project we focused on the kitchen. In the kitchen we have the ingredients which represent the individual pieces of benefit data. The coders must mix them together, using the correct amounts, to produce something people can eat. We worked with the coders to create a recipe to produce a consistent product.
I led design efforts pulling in other UX team members for critique and feedback. My role included facilitating collaborative meetings and helping communicate direction with customers. Since the project was completely new, I led a project team to gather requirements directly from the customers. During the design process my team had to align with a newly implemented Agile process.
Due to the technical complexity behind the system, our team held several meetings every week to collaborate, question and build out the data structure. We started at the data-level and worked our way up to build out complete plans. I worked in parallel to design the UI and held separate meetings with the customer to elicit business requirements. Through continuous conversations and managing a diverse team I built a strong rapport with the customer and began successful implementation of the dashboard.
I chose to approach this project Lean because the project involved more UI design than experience thinking and the customer and user were the same people. By sketching core concepts and projecting them on the whiteboard, I then invited the team and customers to critique and draw on the whiteboard. Once everyone was comfortable enough to sketch in front of the group, we found a flow and things progressed quickly. I was able to take a sketch and receive buy-in within the same day.
The customer requested to use a drag and drop interface. The concept was simple. Starting with the data layer the user would drag and drop to create statements. Then they would combine those statements and continue until the final layer where the statements were all grouped together under a plan. The problem was the not drag and drop feature but the barriers between layers. It was hard to reference and compare data as you moved up layers. We had to introduce search capabilities and clear validation to help users find what they were looking for and know if they were making a mistake.
Our best feedback came when I was able to user test with our customer. I put together a test plan and set up user testing sessions. As they used the prototype and walked through task, we were able to collect feedback and pivot on our design decisions. An example was iterating through a well-designed navigation system. It needed to be structured enough not to confuse users but loose enough to scale in the future. Because we used AngularJS we had scalable capabilities. The customer made a decision to scale multiple layers deep with a single tree navigation instead of using the page for secondary navigation. Something I recommended they not do considering the complexity of the system. A year after the project an enhancement request was made by the customer because of performance issues with the navigation tree.
A year after implementation the benefit coders have implemented nearly all of the plans in the old benefits system. Tweaks and enhancements have been made to increase performance. Today we have significantly simplified their process and reduced the amount of time it takes to code and train new employees to use the system.
The provider portal is the most used application and arguably the most important. Providers are the face of medical care and need to be trusted as experts. We need to feed them accurate on-demand information so they can educate and care for patients.
The provider portal was the first major external facing application to consume the new benefits data. This meant we needed to get the design right. If we made a design mistake, that mistake would affect everything that followed like a domino effect. We knew that continued user research would be a vital and invaluable tool for making informed decisions and honing in on the best designs. The first hurdle we had to overcome was getting buy-in from the stakeholders. We had to win them over and build a strong rapport to make our process easier. This was done by making them a part of our process.
My role was shared with a lead designer’s. He led most of the meetings, user testing and managed the stakeholders. I built the portal prototype, supported user testing and worked directly with the customer to realize requirements. We shared duty on planning user testing, ideation and communicating design.
Since the benefits experience strategy research was complete, we applied it immediately in this project. Based on customer requests, we added new features.
After convincing stakeholders to buy-in and participate, we conducted user testing. We found, while listening to customer service calls, that most providers ask the same set of questions. Most providers have a check-list of questions they need answered. We built our user test plan based on those questions.
Our goal was to test with 10 providers, actually reaching 9. Our hypothesis was that if providers were able to complete the tasks with ease, we could increase self-service adoption rates and reduce the amount of customer service calls. We knew, from Opinion Lab feedback, that providers lacked trust with the old system for two reasons.
During the Benefits Experience Strategy Research a great deal of time was spent designing various ways to show benefit data. Providers know what they’re looking for and refer to service ranges to find procedures. All we needed to do was lay out the services in a clear-ranged format. My original accordion-design tested well and fit the mold.
We spent a lot of time during the benefits experience strategy research designing different ways to show benefit data. Because of that testing we already knew how we wanted to display and group the data. Providers know what they’re looking for and refer to service ranges to find procedures. All we needed to do was lay out the services in a clear-ranged format. My original accordion-design tested well and fit the mold.
In the new benefits, we wanted to display special plan details and member-specific data. We made informed decisions to educate providers about additional plan features for their patients. Members are being educated by their providers and that is where the conversations are happening. We wanted to educate the provider as much as possible about the member’s benefits.
We didn’t want to leave some providers behind while others kept up with technology. So we redesigned the print functionality. Any doctor’s office can access their information regardless of technical capability.
Solution: We decided to show outcomes for both true and false cases.
Solution: We decided to use keywords based off the test.
Solution: We changed the layout and moved related data to be in close proximity until we are able to do the calculations for the user.
Our team launched the redesigned portal in December of 2017. After the first month we successfully increased usage rates by 47%. We also received anonymous feedback a provider that stated we had the best portal of all competitors.