Creating a 0-1 provider product to increase provider engagement and patient adherence.

Status: Complete / Role: Lead UX Researcher

Through research, we crafted 'guardrails' to design by and built confidence in our decision to invest more time and resources into the nooks and crannies of what would be our new product - an all-inclusive provider portal for prescription digital therapeutics (PDTs), where providers could manage all of the basic logistics of providing care with a PDT and also continue to advocate for and demonstrate the value of this treatment in addiction treatment to their patients and insurance carriers.

A big challenge for providers in addiction treatment is that their patients are extremely resistant to change – they require a lot of reinforcement and reminders to actually adhere to their treatment plan. Due to their patient volume and responsibilities, providers weren't able to be that constant presence in a patient's recovery journey and patients would eventually disengage with their treatment plan. This similar behavior was identified with the PDT and it became a vicious cycle where the provider didn't reinforce the PDT and the patient would not engage with it, resulting in it not being used in recovery. To combat that challenge, an activity feed was created to monitor and communicate progress to provide insight at critical times throughout the patient's treatment plan.

The patient profile also captured information that providers prioritized when their patients used a PDT:

• Past urine drug screens (UDS)

• Self reported cravings and triggers

• Lesson completion

• Rewards earned

Awareness of PDTs as a treatment modality is also still relatively low and our team agreed that the default should be to expect every provider to not know what a PDT is. We intentionally decided to create a resource hub to build advocacy into the provider product experience. A resource hub can grow to become a personalized resource center that introduces, familiarizes, and evangelizes the concept of a PDT to a patient and provider to ensure there is no discomfort with utilizing the product. The hub is meant to scale with the business and provide materials that clarify questions for new patients.

Blast from the Past!

We were facing 3 problems with our business:

1. Low prescription rates

2. Low engagement rates

3. High churn rates

These 3 metrics directly impacted revenue, causing a negative snowball effect on other initiatives focused on product scalability and new user acquisition. The patient side of our product was also struggling, especially with onboarding due to the convoluted process that new users had to go through to get access. Our team philosophy about the patient and provider experience was that they were very intertwined and directly impacted each other – giving us an opportunity to reimagine the current experience.

Research Process

This project happened in 3 cycles and each cycle informed the subsequent cycle to refine what we should create. These happened in 2-3 week long sprints, with time in between each cycle for my team (a designer and me) to plan, recruit participants, conduct research, analyze results, and ideate concepts to test in the next cycle.

1. Cycle 1 - desirability and persona exploration

2. Cycle 2 - concept testing and validation

3. Cycle 3 - prototype testing

All of our participants were healthcare providers in some capacity, ranging from clinicians (MDs, NPs, PA-C, LCSW, and MSW) and non-clinicians (administrators and office staff) who work at addiction clinics. Care for addiction recovery does not happen in the same lens that primary care does since patients see various individuals at a clinic for different purposes.

• Patients see prescribers (MD, NP) for medication management.

• Patients see CTPs (counselor, therapist, psychologist) for counseling and/or therapy.

• Patients sometimes see/have access to office staff (administrator, Peer Advocate) for basic needs support.

Cycle 1

The goal of Cycle 1 was to explore if and how treatment concepts fit into how addiction clinics and treatment facilities provide care for patients.

Cycle 1 primarily focused on assessing the various concepts that were developed based off of existing market and competitor research. A multitude of concept cards and a brief description were created to assess desirability and see what our participants would want as a tool in their day to day work.

Concepts were sorted into the following segments:

Organizing concepts into preference and application categories allowed us to do a larger landscape analysis at what was lacking in how providers were doing their day-to-day work at addiction clinics. Although the majority of the providers were interested in the available concepts, there was slight concern over actual implementation (e.g., material cost and budget, patient comfort, logistics).

The categories that we were most interested in were:

• Good for patients

• Good for me and my process

• Good for my team and clinic

• Most memorable

On top of prioritizing the concept cards in these categories, we also made sure to factor in what we learned about provider workflows (the good and the bad) into any design brainstorm to ensure that what we built would be both 'desirable and usable'.

Moving into Cycle 2 meant that we took the concepts one step further – drafting what a potential workflow based on the concept cards would look like.

Cycle 2

The goal of Cycle 2 was to assess the proposed wireframes against existing customer workflows for feasibility and PDT-specific feature adoption.

Cycle 2 was the start of something new (and yes I am a high school musical fan). We added more substance into the concepts for providers to have a starting ground to think and talk from. These were looong sessions (around 90 minutes each) because we wanted ample time to -

• Probe into how they managed and accomplished their day-to-day responsibilities,

• Gather context and insights about how they worked within their team, and

• Imagine what this flow would be like if it was at their clinic.

For this cycle, we focused specifically on our users (clinics that were actively prescribing our PDTs) to dive deeper into how our product was being integrated into their day-to-day work. The end goal of this project was to create something that would effectively boost PDT adoption in clinics and getting a lens into that day-to-day work was crucial to identify what pain points were preventing that adoption.

With these different flows to show, we learned a huge amount about:

• the importance of "timing" when bringing up a PDT into a patient's treatment plan (we referred to it as the golden window)

• the convoluted process of prescribing a PDT and engaging with it from both a provider and patient perspective

• the variation of roles and responsibilities across clinics

• the lack of patient and provider education and support being provided to clinics as first-time PDT adopters

• the working relationships and collaborative dynamic (or lack thereof) between clinicians and non-clinicians

We were able to strategically think about what product features to include in this first iteration of prototyping and how we could think about scaling it to be useful not just for providers, but also for patients.

Cycle 3

The goal of Cycle 3 was to evaluate the prototype against current customer workflows and clinic implementation.

Cycle 3 (we're almost done!) became the opportunity for us to digitally manifest what we envisioned alongside our providers. Knowing what we learned, we really wanted to emphasize the value of this 'platform' as an extension of a provider's ability to provide care for their patients.

Feedback from providers continued to highlight the existing pain points that our customers were facing when trying to adopt PDTs into their standard line of care, which allowed us to enhance our narrative of why it was so important to build this portal.

The Outcome

When sharing this to stakeholders, we followed this 'formula' to best engage our stakeholders:

• Research Finding --> Design Decision / Product Feature --> Company OKRs

We found that doing it this way clearly connected the dots and told a narrative from the provider perspective and how these design decisions impacted company priorities.

• Increasing Sample Access

'Sample' was a pilot that our company launched briefly to increase awareness and usage of the PDT, but didn't really fully pursue. Based on our data and our providers in this project, sample was a huge indicator of PDT adoption because it allowed patients to quickly get into the app when they were in the clinic; timing was so important here because these patients tended to not follow up on what they needed to do in order to use the PDT and providers didn't introduce the PDT to patients until they were at a more stable state. The golden window of PDT introduction and adoption was tiny and providers had to capitalize on it.

We included a feature that would allow providers to quickly get a 'Sample' into the hands of patients. We minimized the amount of information needed to fill out a 'Sample' request form so that providers could easily complete it and spend the clinic visit time on discussing more pertinent issues. The existing way required information that wasn't particularly relevant to the 'Sample' request and removing it would reduce the amount of work needed from them and streamline the process.

Another benefit of having this quick action item was that it made it visible to providers. Some customers weren't aware that 'Sample' was even an offering. Having this feature would increase visibility of 'Sample', which we hypothesized would increase the rate of prescriptions being written and fulfilled, and ultimately increase revenue for the company.

• Prioritization and Identification of Tasks

A recurring sentiment that's widely recognized and known throughout healthcare is the massive amount of work the providers are required to do. Using our product added to that workload because there were so many extra steps (different logins, different websites, different billing codes, independent learning of systems and content) they needed to do and we wanted to minimize it as much as possible. Our inclusion of this functionality served to notify/remind providers of what they needed to do and how they could do it quickly.

By having the responsibilities of the provider clearly listed, it allowed for easy follow-up. In our research, we learned that there was not a lot of visibility into what was happening because the tools used weren't communicating with each other and providers felt like "things were going into the void and were hoping for the best." Unless they manually checked the different sources of information to make an assumption about their progress, it would be left unattended. We also decided to apply this concept of quickly identifying and prioritizing items to patient profiles to inform providers about how their patients were engaging with the PDT.

• PDT Queue

Similar to the sentiment about how "things were going into the void," there was concern from providers about how they hoped for the best when the prescription was signed off and that the patient could get access. We decided to include something called the "PDT Queue" to give providers a bird-eye perspective on where the patient was with the prescription. It also correlated back to the provider to inform them if there was any step they needed to do.

By providing this transparency, providers could follow up with their patient about the PDT instead of hoping it would happen to ensure that prescriptions that were written were fulfilled and patients could actually access the product. Ultimately, this contributes to the rate of prescriptions being fulfilled and engagement with our product.

• Provider Resources

In our conversations with our customers, we also learned that they often let our Sales people on-site handle questions about the product from patients. Providers voiced that they felt like they were "trying to sell the product to the patient," which represent a discomfort or lack of understanding about how to talk about the PDT.

To continue building advocacy for the PDT, we decided on creating an in-product resources tab that housed relevant information about the PDT for education purposes (not just for the provider, but also the patient) to increase awareness and visibility of both sides.

A resources tab was something that could also scale as we continued to grow our product. By empowering providers to learn about the PDT, we increased our chances of adoption and implementation, which would ultimately increase prescription, revenue, and engagement goals.

Limitations

Stakeholder alignment and prioritization continued to be huge challenge for this project due to the pharma, engineering, and design teams clashing heads in this new space. There was (and still needs to be) a ton of design education and awareness to be done in order to streamline how product discovery and development can occur.

One of the exercises we did to help with alignment and priority was to treat it like an "investment opportunity" (since money is always important!)

We were also made aware of the 'tech debt' that our engineering team had to overcome before being able to tackle this, which added to the timeline of how to roll this out as a V1. However, this initiated the "Unification Strategy" project for our engineering and data science teams to consolidate data sources and think about how this deliverable would manifest.