Background

In 2019, my colleague and I conceptualized a tools system centering around a user’s daily interactions with their health. This project pitch aligned with corporate objectives and in 2020, we launched the optimized Drug, Doctor, and Pharmacy Tools for eHealth Medicare to help customers personalize their search for a Medicare plan.

About eHealth

eHealth is an online health insurance marketplace where customers can find plans from 180+ top insurers nationally. With over 5M+ customers served, eHealth is a leader in providing a customer-centered experience in the complex system that is healthcare.

About eHealth Medicare

eHealth Medicare focuses on the Medicare customer and provides a unique level of comprehension and guidance through our dedicated agent-centered phone services and online shopping tools. In the online shopping experience, our personalized tools and customer-focused dashboard provide a self-guided process that connects the language of insurance plans and costs in a way customers relate to and comprehend in their daily lives.

Key Highlights

Designed the optimized Drug Tool, Doctor and Pharmacy Tools - a customer-centered features which increased enrollment by 17.7% and allowed users to shop for plans that cover their personal needs.
Defined the framework of our Tools UX, which continues to be used and expanded upon within the eHealth online shopping experience.

Details

Drug Tool

Designing the drug tool required taking a step back to look outside of how the health industry understands drugs and drug pricing, refocusing attention on how a consumer understands their medications.

Insurance and pharmacies comprehend drugs at a much more complex level and include details like packaging, dosage, packaging size, and brands into their calculations.

The customer’s level of understanding can vary greatly based on life experiences. Customers with chronic conditions, for instance, constantly deal with drug management in their daily life, but that doesn’t mean these “seasoned warriors” want to be required to have constant up-to-date knowledge in order to live their lives. Medications are meant to enable their lives, not burden them with complications and management.

At its simplest, we found (through user studies, data analysis, and call center observations) that most Medicare-aged customers know the name of their drugs, or at least what they take them for. They can also easily recall the rate at which they take the drug and any visual identifiers (i.e. “round white pill”).

A sample of drugs from a heart transplant patient with a pre-existing chronic condition. At its extreme, a person could have a whole spreadsheet of drugs they need to make sure they continue to take once aged in to Medicare.

We couldn’t do anything about the visual identifiers due to API limitations, so focused our attention on simplifying drug data entry on our website.

The old Drug Tool (pre-2020) took the user out of the shop experience and into a separate page.

The new Drug Tool (2020) floats within a modal to allow the same component to be opened from various pages and keep the user within their current experience.

The original drug tool was difficult to navigate and required the user know their dosages, package distributions, generic vs brand, and the exact spelling in order to include it for drug pricing. The new drug tool simplified customer data entry to JUST the drug name. The user could search for their drug like a normal browser search. We even handled fuzzy searching by surfacing the most likely match as the user typed. The rest of the details became optional. We defaulted the dosage and quantity to the most common and made packaging details unnecessary (we could average out the costs without it without hurting customer trust).

These design changes altered the tool from a “give us the necessary information” mindset to a simpler “just tell us what you know.”

Drug Tool (Mobile) - on first launch of Drug Tool, user sees the search to start.

Because of how drugs are catalogues in database, we cannot combine ass “Humalog” into 1 listing, so we surface the most likely match to the top (“most likely” is based on most commonly prescribed and fuzzy keyword search that reacts to each character typed)

Prescription details are pre-filled with most-common dosage and frequency. Bellow the fold the user can also indicate package size, though we do not surface it strongly since it is not necessary to the flow. The most common user case user can just verify the vitiable information and click “add drug”

Once a drug is added, the user is taken to a summary screen where they can see their drug list. On desktop, the user can also print this list for their own uses

Once a user adds their personal information and exits the Drug Tool, they are able to filter and select plans based on coverage and pricing of their prescriptions.

Tools UI Framework

Drug Tool (and Doctor and Pharmacy Tools) was conceptualized with the potential to do more for the user than narrow down Medicare Plan options. My passion to reduce friction in personal healthcare is what led to the ideation of these "manage your information" tools. Therefore, it was important that its design be flexible so it could exist in multiple experiences.

A modal framework was ideal to allow the tools to be opened from various locations while still keeping the user on the current page.

The design of the tool itself was kept minimal in order to not create visual clutter in this modal state. Rather we relied on typography, spacing, and blocks of color to create a visual flow. Certain navigational elements (such as a sticky header with a close X and optional back arrow (depending on whether the user entered this screen from another modal or from a host page) were kept consistent across all tools to create a reliable and recognizable UI pattern for the user.

Full design specs of the modal, including screen height variances . This was used to keep the layout consistent across the designers and the different development teams using this component.

Doctor and Pharmacy Tools

Doctor & Pharmacy tool had extra challenge with the technical constraints of legacy API and scope limitations. We made sure the design kept a visual consistency across the eHealth Medicare experience.

Prescription details page of the Drug Tool

I’m a strong believer that the best way to learn is to try. I would preemptively collaborate with the Product Owners and stakeholders to define the deliverables and project structure before initiating a “kick-off” with the primary designer.

Alongside Drug Tool, Doctor and Pharmacy also are used throughout the eHealth experience and have been integral in improving conversion. Customers who used Doctor Tool were 3x more likely to enroll in a plan.

Final Thoughts

As eHealth continues to grow and expand their online capabilities, these tools become a foundation to the customer's self-guided experience with us. My original intention was to move eHealth away from a single-transaction mindset to considering themselves as a reliable web portal for the Medicare customer.

Each year brings eHealth closer to this vision and my hope and intent is to encourage that focus as new projects are defined and scoped each year.