Member Switching Navigation
UX Case Study
Our initial approach to managing multiple members within a household was creating problems for everyone. See how we overcame these challenges and created a better navigation experience for members.
Looking for a more in-depth version of this case study?
If you are reviewing my work and want a more detailed version of this case study, feel free to view the detailed version.
Introduction
The Problem
Our initial approach to the Head of Household Member Portal experience was inspired by user feedback. This feedback indicated that Members enjoyed the idea of being the “manager” of their household. To create this feeling, we decided to provide a flat navigation structure throughout the application. The Head of Household would just need to navigate to a feature and select the desired dependent from a dropdown in order to view their information.
This format had tested well, but it eventually became apparent that it was very difficult for the development team to implement due to the way the member data was structured. Over time, we accumulated many defects due to this flat navigation structure. These defects would ultimately have a negative impact on the Member Experience and required constant fixing. This put a lot of pressure on the team which reduced morale. Our initial approach was clearly not working and something needed to change.
Previous user research and conceptual work on the Member Delegate feature had shown that we may need to add a way for users to switch between accounts in the future, however the project had been put on hold in favor of other features. Equipped with this prior knowledge, I used this opportunity to push for an update to the way we handle the Head of Household navigation that could scale with new features like Member Delegate.
The team agreed.
Target Users
Head of Household Members
The Head of Household is usually a parent/guardian with dependents under the age of 18. They need to manage care on their behalf. This user type may also have their own separate plan.
Dual Plan Holders
Some Members may be enrolled in a plan that has two separate memberships. Typically a Medicare Member that also has Medicaid.
Caregiver/Delegated Members
In the future, there are plans to allow some members to grant access to their health information to other members. The best example of this would be a daughter managing the care for their elderly mother or grandmother.
My Role & Responsibilities
Charles Estes (Me)
Lead UX/UI Design Consultant
Responsibilities
UX/UI Design from strategy to development
Synthesizing business, technical, and user needs into a delightful Member Portal Experience
Supporting user research
Securing stakeholder alignment and buy-in
Maintaining a consistent design direction for the Member Portal
Maintaining client relationships
Cross-functional Team
Kevin C. (Business Owner)
Director of Project Management
Kathy S.
Product Analyst
Trevaughn D.
Technical Lead
Bengisu D.
UX Researcher
Desired Outcomes
How do we know that we've succeeded? What are we trying to achieve with this feature?
Business Outcomes
A greatly reduced amount of defects will be created when implementing the Head of Household and Dual Plan business rules.
Some defects had been the result of specific business rules not being recorded within the user story. Other times it had been the result of the complexity of providing a combined view of the data while maintaining privacy and security. Any solution needs to make things easier for product to document and the development team to implement.
Reduced occurrence of things breaking during the process of modernizing the backend data.
Over the years, it had become obvious that what we had originally implemented was breaking whenever other teams made progress on the ongoing modernization efforts. This slowed us down and resulted in frequent defects. The solution needs to be less prone to breaking.
We will retain or even increase the amount of enrolled Head of Household Members.
Reducing friction for the Head of Household members should help improve the digital customer experience. Therefore, we expect to retain and possibly increase the members enrolled in these plans. Since the plan benefits themselves are out of the team’s control, there is a risk that we cannot reach this outcome if they are dissatisfied with the plan itself.
User Outcomes
Users will be able to easily manage the plans of everyone within their household.
In previous research, we determined that it is important that the Head of Household user “feels” like they are the manager of their household. Any solution needs to maintain this feeling.
Users can find plan information of a dependent quickly and efficiently.
It should be very clear when information is. All patterns should match existing mental models.
Design Process
Existing Head of Household Experience
Overview
The current Head of Household experience combines all available memberships into a combined view. When wanting to view a dependent’s information, the HoH can select them in a dropdown at the top of each feature. Later we found that some applications we were consuming do not support this “combined” view. As a result, we had to create a modal that would allow for the desired member to be selected in order to send them to the correct place within the portal.
The solution should be just as simple to navigate while satisfying the technical requirements.
Designing the New Navigation Model
Approach #1
Filter by Plan/Membership
Our first thought was to filter Member information by the Plan. This would separate each plan into it’s own portal. At first this made sense, but during the ideation phase, we realized that we would need to account for at least two years of plan history. If we use this model, the navigation would behave like the flow below.
How this Translates to UI
The member would log into their account and be prompted to select the plan that they’d like to view. Once taken to that view, they can switch between other plans using the Profile Menu within the navigation.
Team Feedback
Segregating the member’s data was the simplest to implement which lead us to favor this approach. Once we realized that we needed to account for 2 years of historical data, the UI started to get more complicated than we hoped. After socializing with the team, it became apparent that we needed to consider something different.
Pros
Prompting user upon login should help reduce confusion for new members.
Segregating member data by membership is the easiest to implement with the existing data structure.
We would not longer need the membership select dropdown for Dual Plan Members.
Cons
Historical plan selection makes the UI more complex than we’d like.
Inactive plans will also appear within the dropdown, adding clutter.
This approach does not fulfill the goal of greater scalability.
It may not be obvious which plan you are viewing.
Approach #2
Filter by Person (Customer ID)
When looking at the existing data structure, and with some additional trial and error, I determined that the other viable way we could filter the information was by Person (CustomerID). Since we also need to maintain 2 years of historical data we could group all of the years together under the person.
How this Translates to UI
The member would log into their account and be prompted to select the person that they’d like to view. Once taken to that view, they can switch between other people within their household using the Profile Menu within the navigation.
Team Feedback
The feedback for this version was generally more positive, so I had a hunch that the team would chose this direction. Filtering by person made the UI much less complex since we did not need to account for each year the plan was active. There were some remarks that there would still need to be some groupings made to combine the plans into a single view, but overall it was simpler for the team to implement than what we have been supporting.
Pros
The UI has much less complexity due to the lack of historical selections.
Can scale to allow for many people within the menu list.
Should be more obvious which plan you are managing.
Cons
Historical information needs to be accounted for on the feature level.
Dual Plan members would still need to use the plan select dropdown.
Slightly more complex to implement since data still needs to be grouped on the backend.
Getting Stakeholder Buy-in
Alignment Workshop
After a few discussions, the team was having a hard time deciding on which approach was best. We needed a working session to get everyone on the same page. Using Miro, I guided the participants through the designs and explained the two different navigation models we could use. Everyone was able to as questions and record any technical or UX concerns that had not already been discussed. In the end were able to agree that the simpler navigation modal was the best for members. After agreeing on our preferred direction, we moved on to user validation.
Participants
Kevin C. (Business Owner)
Director of Project Management
Kathy S.
Product Analyst
Trevaughn D.
Technical Lead
Charles E.
Lead UX Designer
Duration
1 Hour
Tools
Miro
Final Decision
Filter by Person (Customer ID) Chosen
Prototype & Test
Validation Testing
Once we had a direction, I collaborated with our UX Researcher to get ready for the Validation Research. My main task was to craft the prototype in order to help get our questions answered, as well as contribute to the study guide. I chose to create a very open prototype for this study, allowing for the possibility to complete each task as any member. The goal was to allow them to complete the task and then observe if they completed it for the correct member.
Facilitator
Bengisu D.
UX Researcher
Total Participants
7, Ages 27-49
Recruitment Criteria
1
They make healthcare decisions in the household either on their own or with their partners.
2
They help manage HealthInc plans for a child, dependent, or legal guardian.
What We Wanted to Learn
1
Evaluate the findability and usability of the new profile switching design component.
2
Can Head of Household members understand how to switch between dependent member plans?
3
Evaluate the proposed solution to understand if it improves or worsens the member’s experience consuming healthcare information or completing tasks across multiple dependents.
4
Test the assumption that Global profile switching will improve the experience for head of household members to view and manage healthcare information across members in their account
5
Learn about HoH members’ current experience using customer center (motivations, behaviors and pain points)
Study Results
Participants like seeing their dependents under one umbrella.
After switching members, participants expected to land on the homepage of the profile selected, as proposed on the designs.
Some participants failed to switch members when they were asked to change PCP for themselves.
2/7 who were less tech-savvy failed to find the member switcher.
3 HoH mentioned they struggled with account set up for their dependents, 2 of them dealing with multiple logins and passwords.
Recommendations
1
Find a way to make the function of the expandable container more obvious.
2
Come up with a way to make the profile switching more obvious or improve education around it.
2
Self service: Include onboarding online to guide members on how to correctly and effectively add their dependents under their accounts to reduce the member support cost. (Future Enhancement)
Post Research Enhancements
1
Make the Function of the Member Container More Explicit
Since the icon on its own was not clear enough for all members, I modified the accordion to allow for supporting text.
Old
New
2
Add and Onboarding Slideshow with Coach Marks
Stretch Goal
I’d been pushing to make onboarding slideshow modals a standard practice for introducing new features within the application. This was a great opportunity for us to start by communicating the navigation changes to members as they login. If we have the scope, we could even add a Coach Mark tutorial at the end of it.
Final Designs
Learnings & Next Steps
Learnings
With the mostly positive results of the validation testing, it would appear that we accomplished our primary goal. Member’s understood the navigation model and were able to successfully switch between members of their household. The changes made after the research should make things clearer for the population that might not understand right away.
The study also uncovered an opportunity for us improve the overall Head of Household experience in the future. During the interviews, we found out that there were some inconsistencies in how the HoH members were guided to create and activate their accounts. Our suggestion was to improve the training of customer care agents and to create a self service account attachment feature could help streamline this process.
Next Steps
At this point in the process I rolled off the project. If I had stayed on, the next steps would have been to finalize the documentation of the mock-ups within Figma in order to get ready for the implementation phase. This would include refining all of the responsive designs and documenting all special interactions and desired animations.