Provider Guide: Concept to Launch

Connecting healthcare consumers with better doctors

Project Overview

How might we help employees of large self-insured companies find the best healthcare providers in their area?

Embold Health is a healthcare technology organization that helps self-insured employers improve healthcare for their employees by measuring provider performance and delivering it inside a doctor finding web application.

I joined Embold as they were preparing to launch Provider Guide, their doctor finding tool, to their first customer.

Challenges

Competitive Analysis

As we were replacing a tool that employees were already using, it was important to keep the experience as familiar as possible while introducing the new concept of measured provider performance. We conducted a competitive analysis of the popular doctor searching tools which informed our design of the most important areas of the application: search and provider details.

Design Goals

User Personas

Based on our initial use research and our conversations with internal stakeholders, we created two personas to represent the two major use cases for Provider Guide.

Leo represents the use case of trying to find a new doctor, while Des is using the tool to check the quality and location of a doctor she was referred to. Their pain points include the common frustrations people in our interviews and survey experience with doctor finding tools.

In our usability tests, we asked participants complete tasks related to these two use cases.

Sketches and Wireframes

Usability Testing

We conducted usability testing on a low-fidelity version of Provider Guide with 5 participants. In these sessions, we were primarily interested in whether participants could accomplish the tasks from our personas’ use cases.

We learned that we need to keep the search bar prominent as that is the main access point into the tool. The test also confirmed our hypothesis that users would question the source of the provider ratings, and that this information needs to be readily available.

Out of these tests, we adjusted some of the affordances and ordering of information to make completing a search easier.

Pitching Version 1

Shown here is the wireframe flow for the first version of Provider Guide (at this time called Provider Finder) after our first round of research and usability testing. I pitched this design to the product leaders and got their buy-in to move forward with development. At this point, I started working with the engineering team and internal stakeholders more closely, which led to both visual and structural changes in the application.

Collaborating with the Engineers

Together with the engineers, I mapped out more detailed user flows and came up with solutions for error states and edge cases that had not been considered previously. We were given a narrow scope by our tech and product leaders, which enabled us to focus on improving the key areas of the user flow.

Testing with Our End Users

To overcome the challenges of this launch, I knew it was essential to conduct usability testing with our end users. As the only UX designer on the team, it was up to me to advocate for access to our customer’s employees. I worked with the account manager to pitch an onsite visit for usability testing, and thankfully our customer was able to see the benefit and worked with us to schedule time with their employees. We traveled onsite to their headquarters to conduct this important pre-launch test.

Research Topics

1. Can employees complete the tasks associated with the major use cases?

2. Would employees feel confident choosing a doctor based on the information they see?

3. Which colors help employees differentiate between high and low quality doctors?

Rapid Learning + Iterating

On the first day of testing, we realized after a handful of sessions that none of the participants were confident choosing a doctor based on what they saw on the website.

We decided to end the testing day early to make changes to the prototypes, hoping to get better results on the next day. It was important that we iterate quickly, as we had a short window of access to our end users.

The second day of testing went much better than the first, with all participants expressing confidence in their ability to choose a doctor from the tool.

Usability Findings

1. Participants couldn’t navigate between map and list: needs a better affordance to show list can be pulled up

2. Tooltip to explain labels on providers should be isolated to the specific visualization on doctor card that was interacted with instead of showing all options

3. Color used to show which doctors are lower performers is more important (participants preferred red) than color used for high performers (no strong preference)

Final Designs

Search is front and center on the landing page. We learned from our initial user interviews that on the typical healthcare website, users spend a lot of time navigating through complicated menus before being able to see any doctor information. We wanted our tool to bypass that exhausting process and pair members with high quality doctors quickly.

We had originally imagined large buttons that would lead users to search categories, but we eventually streamlined the page and gave more prominence to the information about Embold and what they do, as our secondary goal was to educate users on how this tool makes finding a doctor better and easier.

Searching for a doctor should be straightforward, so our search experience was designed to mirror what people have grown to expect based on the most well-known search tools. Including autocomplete was essential, not only because it shortcuts getting to results, but because users expect it from any search tool and feel stuck without it.

Our first version of the search results page was structured with two tabs that users could switch between to see doctors on a map or in a list. While this is a somewhat common design, we had learned from our user interviews that the most important factor when choosing a doctor is distance, so I wanted to make sure users could see where doctors were located immediately.

We created a section at the top of the profile based on what information was most important when choosing a doctor. As the application as matured, this has also become a way to highlight health plan specific information that differs between clients who use Provider Guide for their employees.

Another important feature on the doctor profiles is the section of call-to-action buttons that allow users to share doctor profiles, and a schedule button that connects users with a concierge service to help them get an appointment. The share button was especially important for us to include at launch; since the tool does not require users to create a profile, we wanted to offer an alternative way to save and keep track of doctors they find. This feature is also helpful for users who are searching for a provider for a family member.

Post-Launch Learning

FullStory analytics showed that 70% of employees were accessing the site on desktop devices

Our customer had communicated that their employees would most likely visit the site using their mobile devices. From our FullStory analytics we saw that was not the case. While our site was functional on other viewports, we had chosen not to spend resources to make sure it was fully responsive.

Following launch, one of the frontend engineers and I spent the next week cleaning up the responsive experience. Although we were constrained prior to launch (and were told to design mobile first), on future projects I would dedicate more design time to making the site responsive.

Final Thoughts

Our team has made many improvements to Provider Guide since launch, but much of the application has retained the same structure because of our user-centered approach from the beginning. Everything we’ve added and tweaked since has been built on the same foundation that we launched with back in 2019.

I am especially proud of the fact that we conducted usability studies with the actual end users—something we were able to repeat for the launch with our second customer two months later.

This was my first project working with engineers and business teams, and it was an amazing experience. Because we were under time and resource constraints we had to make trade-offs together, but collaborating with cross-functional teams made those decisions a lot easier.