Group 27.png

CASE STUDY: Healthcare Spending Feature (Accolade)

Group 25.png

Healthcare Spending Feature (Accolade)

CASE STUDY

 

Design Goals

The Accolade app’s “Spending” feature allows users to track their healthcare expenses and easily escalate claims issues to their healthcare assistant. Prior to designing this feature in the mobile app, Accolade’s users had no way of viewing this information independently. For healthcare spending help, they would have to call Accolade and speak with a healthcare assistant on the phone.

My Role

I worked on this feature independently, leading the end-to-end UCD process. I independently conducted the user research, designed the workflows (from lo-fi to hi-fi) and conducted two usability tests. As always, I incorporated feedback from my design manager and PMs along the way.

After I completed this feature, I worked with the designer of Accolade’s web portal, the sister product to the mobile app, to scale the designs while maintaining feature parity and visual consistency. I also supported my iOS and Android engineers throughout implementation, ensuring they understand the rationale behind design decisions and troubleshooting any issues on the fly.

 

 

Who Are The Users?

Accolade’s customers are companies that provide Accolade as a healthcare service to their employees and their families — these are our users. Accolade’s health assistants, nurses and clinicians help our users navigate through the healthcare system with the goal of educating them on their health insurance coverage, handling issues with claims and finding the right medical providers for each users unique care needs. The Accolade app empowers users to better manage their healthcare and connects them to their health assistants and clinicians via a messaging UX.

 

The Problem

Users need a way to conveniently track their healthcare spending and loop in their health assistant when they have more granular questions on service charges or health insurance coverage.

Current Process for Users

Prior to the release of this feature, calling Accolade was the sole method of getting answers to healthcare spending questions. There was no “self-service” option for users who want to manage and plan their healthcare spending independently at their own convenience.

Business Rationale

If more users opt to use the healthcare spending feature rather than call Accolade with questions, this reduces the operational costs and drives scalability.

 

Research Methods

Prior to brainstorming and sketching initial design concepts of the feature, I triangulated research methods to generate findings in order to guide my design priorities.

Analysis of engagement analytics - to gather quantitative data on all the triggers or reasons why users call Accolade with healthcare spending questions.

Focus group with health assistants and clinicians - to uncover the current process of how health assistants help users who call in with healthcare spending questions.

Competitive analysis of existing apps and web tools - to familiarize myself with the existing mental models in this space so that my design can leverage the strongest design patterns.

 

Research Findings

There is a dramatic lack of transparency in the US healthcare system regarding coverage and cost — this has a huge impact on users’ health and economic well-being.

Claims

Users often do not understand why their health insurance bills are so high… and they need help understanding why.

  • Users aren’t sure about the network status of their doctors and think their medical bills may be high due to seeing an out-of-network doctor.

  • Users do not know their health plan coverage details.

  • Insurance companies do over-charge at times, and in such cases, filing a grievance or appeal is a confusing and opaque process.

Engagement analytics showing subtopics of users’ claims questions that are asked over the phone to health assistants

Engagement analytics showing subtopics of users’ claims questions that are asked over the phone to health assistants

 
In order to flesh out what claims questions users have, I conducted a focus group with health assistants and created these themes

In order to flesh out what claims questions users have, I conducted a focus group with health assistants and created these themes

 

Plan Balances

Users find it challenging to track their in-network vs. out-of-network deductibles and out-of-pocket maximums.

  • It’s even harder to manage this for users’ individual and family plans.

  • Without knowing plan balance information, planning healthcare is challenging and worrisome because coverage (cost) is unknown prior to seeking care.

  • Tracking this manually Not every healthcare service counts towards both the deductible and out-of-pocket maximum. Some services only apply to one or the other based on the complex coverage details of the given health plan.

 

Process of Helping Clients

Since there was no “current” existing feature, I mapped out Accolade’s manual, “human backend” process. This helped me understand how the spending feature could fit into our users’ journeys and the strategy behind supplementing the experience with personalized guidance from users’ health assistants.

 

Initial Design Concepts

Iteration

Following the research phase, I generated several design concepts that were rooted in technical feasibility (available data). I explored how this feature could potentially live solely within a conversational UI, which would involve tailoring the app to power-users that are familiar with current messaging design trends. I also wireframed an “explore” feed that could contain healthcare spending insights and connect to the full feature.

Casting a wide net with these design concepts sparked a lot of productive discussions with product owners regarding the long-term goals of the app and what use cases to strategically optimize for. Aside from messaging, “healthcare spending” was the Accolade app’s first major feature, so these discussions were pivotal to defining the approach of the future features to come (“programs,” “find care”, “profile”, etc.)

Constraints

As the sole researcher and designer of this feature, it was challenging to manage investing the time needed to create a strong MVP while still meeting roadmap deadlines so that I wouldn’t be a bottleneck to my engineers. Thankfully I handed off my MVP designs on-time with the help of capacity balancing from my amazing PM.

I also had very little visibility into technical requirements of the claims portion of the feature, as our service had not yet been built during my research and design phases. This took a bit of refinement of the designs later as my devs were implementing the feature. With the plan balances part of the feature, we had a TPM as a go-between, translating all the potential technical scenarios into more consumable requirements, which helped me focus my time more on design.

 

Plan Balances Lo-Fi Exploration

plan balances copy.png
 

Experimenting With a Conversational UI

CLAIMS1.png
CLAIMS 2.png
 

Usability Studies

I independently created the usability study plan and collaborated with business stakeholders to align study goals with product owners’ goals. I then facilitated two rounds of iterative, un-moderated usability studies through Validately, testing with 5 participants in each study. In order to measure the usability improvement from the first to second study, I leveraged the same script and simply replaced the prototype with an updated version for the second study. Here are the findings from the first usability study, which tested embedding the healthcare spending feature within a conversational UI.

 

What Went Well

 

Opportunities for Improvement

 

Final Mobile MVP Designs

Pivoting from a Conversational UI

After I conducted the usability studies, I made several design updates. The feature now lives on the bottom nav bar (in iOS) and the drawer (in Android), which has ushered in a new philosophy on balancing “self-service” features with Accolade’s human backend (nurses and health assistants). The Accolade app was initially envisioned by product owners to be primarily a messenger app with features embedded within a conversational UI. Separating the healthcare spending feature from messaging empowers all our users to be able to easily navigate and monitor their healthcare spending — users that are not necessarily power-users and may not be familiar with the latest conversational UI trends.

 

MVP Feature Flow

Screen Shot 2018-10-18 at 8.59.44 PM.png
 

Plan Balances

The spending feature is organized in a tab view, with plan balances separated from claims. Here are a couple UIs of plan balances.

  • In-network section: showcases two visualizations - individual plan balances and family plan balances (if the user has a family plan). My research revealed that health assistants used a scrappy work-around to provide users with the dollar amount left until hitting their deductibles and out-of-pocket maximums. Because of this, I prioritized those values in the UI.

  • Out-of-network section: (not pictured) also showcases individual plan balances and family plan balances since deductibles and out-of-pocket maximums are different depending on the network status of the healthcare services the user received.

  • Learn more section: provides plain language definitions of the terminology used in the visualizations in order to increase users healthcare literacy. My research showed that many people do not know what these terms mean and are therefore unable to efficiently plan or understand their healthcare finances.

 

Claims List & Expanded Claim Showing Details

When the user tabs to “My Claims,” they can see a chronological list of their medical (including behavioral health) and pharmacy claims.

  • Claims list (left UI): I chose to include this information on the claims because health assistants use service date, provider/clinic name and the amount the user owes ($) in order to identify a claim and assist the user. I included network status, as well, since that is a common question users would ask health assistants on phone calls (“am I being charged so much because this was actually out-of-network?”).

  • Expanded claim (right UI): The user can select a claim to expand it and view a breakdown of the amount they owe their insurance company (“my responsibility section on the right UI). My research showed that users call Accolade because they do not understand why their claim is so high (why their insurance company is charging them so much).

  • Tech constraint: At this moment, we are unable to support delegate status in our products, which means a parent who is a delegate for their child is unable to view their child’s claims or medical data in our products. This is something actively being worked on so that we can create a more inclusive experience for users that manage their families’ care.

 

Claims Message Card & Filters

  • Claim message card: from the previous (expanded claim) UI, the user can select the “ask my Health Assistant” button, which sends the claim to a message thread where they can ask specific, granular questions to receive personalized healthcare navigation from their health assistant.

  • Constraint: MVP scope allowed for filtering but not searching of claims, which will be released in a future version of the feature.

 

Translating to Web

The spending feature is now live in the Accolade app. Some users only have the claims portion, as the plan balances data comes from a third party that not all our customers leverage. From a design pattern perspective, the tab view design of the feature makes it easy to serve both user groups.

After my devs implemented the feature in the mobile app, I got the opportunity to fly out to our office in Prague to collaborate with the lead designer of the web portal. We spent one week translating the mobile designs to the web. I was also able to share all my research and the rationale behind my design decisions with her engineering team, which is especially important since the Czech healthcare system is drastically different than ours.

Below are some of my initial designs completed during my week in Prague. The lead web portal designer then transformed our initial concepts into hi-fi MVP designs. This feature is currently live in the web portal, as well.

Here are some initial concepts I sketched. The lead web designer and I then critiqued our collective sketches prior to creating lo-fi wireframes.

Here are some initial concepts I sketched. The lead web designer and I then critiqued our collective sketches prior to creating lo-fi wireframes.

web 1.png
web 2.png
web 3.png
 

Lessons

As mentioned, the claims portion of this feature had very ambiguous requirements, as the service was in-development and being shaped by the design requirements. To cope with this ambiguity, I concentrated on building strong relationships with my product managers, engineers and the lead designer of the web portal. Delivering designs and making changes on the fly was much easier having full buy-in from our Seattle and Prague teams.

Additionally, having a strong partnership with our health assistants was essential while conducting my initial research. We have contractual and HIPAA barriers that prevent me from reaching directly out to our uses, so being able to leverage health assistants’ domain knowledge was critical.

 

Next Steps

My product and design org has been so focused on shipping MVP features over the past couple years — we have delivered so much and have a lot to be proud of. After shipping this feature, I have worked with product managers to discuss how we might leverage usage data and other research methods to further optimize the UX of the spending feature. The claims service also has new data on pharmacy claims, so clinical stakeholders are also looking into what type of data we may want to add to the UX of the spending feature.