It was late 2021, and I was the lead designer on GoodRx Care, a telehealth product. My PM and I were putting together some projects we thought could move our needle (primary metrics: telehealth visits started and completed). GoodRx Care had recently been integrated into the GoodRx homepage, and we were enjoying a nice bump in visits started that came with all of the new eyeballs. The previous quarter, we had been focused on making optimizations to improve conversion in our funnel to make the most of the influx. Things were good for our squad, but we had a White Whale. While we had been integrated onto the GoodRx homepage, the majority of GoodRx users were on the native app by about 5 to 1. We wanted full native app integration.

What is GoodRx?

GoodRx is a product that creates drug discount coupons that can be redeemed at pharmacies when picking up prescription medications. It has about 6.4 million monthly users.

Our problem though, had always been that our telehealth product was a purely web product. We didn’t have any native app engineers to retool our product to live inside of an app. Aside from the baseline work required to recreate our product in the native app, it would be a big lift to reimagine our complex product flow and navs to work within a section of a larger app. Other teams with native app eng resources were busy trying to move their own metrics. We were a small team with big dreams and it seemed for a time that we’d just have to be content with our web only platform.

Things began to change in November 2021. During our planning for 2022 Q1, two completely separate factors were introduced that would change what was possible for our team:

1. A company wide initiative called Build Once, Deploy (BODE) Everywhere was spinning up. It was an initiative that would make engineering resources available to help streamline the disparate products of GoodRx so that they could all live on a single platform, the native app.

2. Word that a new prioritization of account generation on the core GoodRx product was starting to get around.

The GoodRx core product (rx discount coupons) had long operated without collecting any user data. They had tried time and time again to capture some kind of user information (gating the product behind user accounts, etc) but the existing userbase had just been too accustomed to using the product without any account creation or sign in. Our telehealth product, however, was another story altogether. It required an account to use and because it involved receiving highly individualized care, there was no expectation that it could operate without the storing of personal data behind a secure login. We decided to pitch the integration of GoodRx Care into the native app as a worthwhile vehicle for account creation and use some of the new BODE resources to build it.

GoodRx had purchased quite a few products to integrate into its core offering over the years, telehealth being one of them. After poking around a bit, I was surprised to find out that our telehealth product was one of the only secondary offerings that required user data to function. Our pitch was basically making itself at that point. We just had to connect the dots.

One of the challenges we had to overcome was the view that telehealth was a niche product that didn’t overlap too much with the core usage of the app. The idea was that users come to the GoodRx app to look for discounts for prescriptions that were mostly used to treat chronic conditions. Telehealth simply didn’t have anything to offer a patient that had had complex, chronic conditions. We pushed back on this idea with research we had done with our telehealth userbase.

We had been offering a medication refill service in our product that never really made sense for our patients in their healthcare journey. Most of our users came to us because they were searching for treatment for an acute condition. But, since most core GoodRx coupon users were chronic condition sufferers, this service made quite a bit of sense for them. If we led with this refill service, this could be the ideal introduction of our telehealth product to the GoodRx app userbase.

We made the pitch to the heads of product and were ultimately successful in making the case that GoodRx Care could turn the GoodRx product space into a loop that would address patient health concerns at just about every stage of their healthcare journey.

Once we had the engineering resources that would make the project possible, I still had to solve the complicated design challenge of retooling our telehealth product to be able to work within a new information architecture.

While most flows could be adjusted by closely working with the other design teams that owned the different parts of the product, I was beginning to realize that I would have to create more than just some gap fillers. I would have to create big chunks of the product, net new, to make it work within the app. One of these areas was the concept of a dashboard. Somehow, our telehealth product had been operating successfully without any sort of home-base landing page up until this point. This became a really fun challenge: Can I make the dashboard an integral part of the product that improves the experience rather than just acting as some IA scaffolding?

Going back to the beginning of this story, my PM partner and I had been working on ways of improving our telehealth conversion funnel. One of the baffling things we had noticed was that there was a big drop-off after a patient had paid for a doctor’s consult.

Ideally, a user would pay for the visit and then wait a relatively short time (15min to 1 hour) before a doctor would be sourced to conduct their asynchronous telehealth visit. A large chunk of users never returned after paying. We had always hypothesized that this was because our methods of notifying users that their doctor had begun messaging them was not particularly ideal. We were a web product, after all, and we were mostly stuck with email as a method of notification. But honestly, we suspected our problems were bigger than just the notifications being received. When a user would start a telehealth visit, their journey would take them through multiple branches of the product, all of which required some sort of waiting period where they would leave the product and come back at some later point. We suspected that returning users were losing the thread of their telehealth visit, and this was confirmed by user interviews. These problem had always been too much of a technological lift for our small team to address, so we had historically put it far beyond scope. Being able to build a dashboard on a native app that could send push notifications and display actionable next steps for whatever stage a visit was in could help us out dramatically.

Testing

I really wanted to know if there was anything to our hunches as quickly as possible, so I put together some user testing very early on in the wireframing process. These were a mixture of moderated and unmoderated sessions, and a mixture of existing GoodRx Care users and GoodRx Core users. Immediately we learned something interesting: GoodRx Core users didn’t really know what telehealth meant in this context of the GoodRx app. Early on, we had put together surveys testing the general comprehension of the terms commonly used to refer to our product. Telehealth, telemedicine, etc. Telehealth had returned promising comprehension, but there seemed to be a disconnect. After digging a bit, we realized that a large chunk of our potential users considered telehealth to be when they conducted a virtual visit with their own doctor. They weren’t fully sure that they could use the service outside of their primary care provider. This was a great thing to catch so early on and the solution ended up being fairly simple. I created a first time use informational carousel that answered the most common questions Core users had about telehealth. The carousel tested well, and I could move on to digging into my previous hunch about users returning to visits in progress.

With the same group as before, I structured tests that would gauge how well users would be able to take action on a visit in progress. Group A got the existing mobile web experience, and Group B got the wireframe prototype with a new “action card” at the top of the interface. The action card was simply a shortcut to any visits in progress. It would link to whatever stage the visit was currently in, and the user could take action to progress their visit from there. Group B performed dramatically better on the test across the board, which I found slightly surprising. I had expected the existing Care users to already be familiar enough with the product to not need the action card’s help, but even they performed much better on the task.

After many rounds of wires, testing and refinement, the confidence in the designs were very high. While finalizing the designs, I had to work very closely with our design systems team to expand the functionality of many components to support the telehealth product.

Shipping

When our project shipped, we ended up with multiple successes:

1. Dramatic increase in our product’s core business because of access to a whole new audience on the GoodRx native app.

2. A winning narrative that put our product at the head of the GoodRx core pipeline, leading to core business support, including the priority metric of account creation.

3. Last, but most important, a better functioning product for our users. They could more easily track the status of a telehealth visit and could more easily address pending action items.

But we had also collaborated with teams across the company, forging new working relationships with product leadership and engineering teams from multiple platforms and products. We had worked with design systems teams to reimagine global navigation components and flows. Most importantly, we had been able to knit our product into the main revenue driving stream of the company with minimal disruptions.