A leading American pharmacy chain offers health insurance providers Pharmacy Benefits Management (PBM) services that handle negotiation of drug costs and patient access to medication.

This case study focuses on a Plan Requirements tool that is offered as part of PBM services, that helps Benefit Analysts at health insurance companies create and modify pharmacy benefit plans according to complex, and lengthy specifications.

The pharmacy chain approached VMware Tanzu Labs for help with this and other products as they shift from waterfall to agile. They needed to move quickly, enable healthy design and development practices, and bridge the gap between lean and business teams who sometimes struggle to work effectively together. As a Tanzu Labs designer, part of my job was to work with these goals in mind and support the larger efforts at hand.

** Note - Please keep in mind due to NDA agreements, I was unable to download high res artwork files or show the identifying markers.

The Plan Requirements Tool was originally created for internal use only so the research and goals established during the original discovery and framing were based on a different user group. So we were dealing with a lot of untested assumptions.

The product had a multitude of designers with fluctuating tool boxes so it suffered from a lack of consistent research and questionable design patterns which created skepticism among Business Product Managers toward Designers.

The product team fully bought into the AG Grid library with came with a plethora of technical limitations that sometimes prevented the best design solutions from being implemented. Engineers were also beholden to data points created by other teams which weren't always flexible enough.

Business teams managed the client directly and passed on requirements to product teams. Designers could only get to the bottom of the ask and understand the user's needs through hearsay. Research and usability testing was only allowed with internal Pharmacy Benefits Managers who had adjacent, but not identical needs.

Now, let's look at a specific problem within this space...

The problem with hearsay...

Designers were told that users wanted to apply dozens of filters and it was too difficult to apply them one-by-one, column-by-column, so they needed a single place to apply multiple filters.

The problems that come with a lack of usability testing and research...

We were solving the wrong problem! The filter panel didn't have all the features that users wanted. So designers requested the ability to speak directly with the health plan Benefit Analysts. Unfortunately, because they had already spoken at length with them, it felt like if we did that it might undercut the business team's efforts.

So, we did our best to facilitate discussions with Business Automation Team members and get our hands on examples of existing user workflows so we could understand the ask.

You can see in the examples below that users wanted to search across multiple filters AND they also wanted to search across multiple valid values within a filter.

This was the first step in the workflow of Benefit Analysts. How could it have been left undiscovered?! The Business Automation team wasn't deeply exploring user needs and the happiest paths users wanted to take to complete their workflows.

Their goal when they start their workflow was to combine unique criteria to hone in on a specific plan that most closely matched a new plan they needed to create, so they could make a copy and only edit a few things, rather than building a new plan for scratch.

Because this mission-critical step surfaced late, only weeks before users were expected to onboard, the real risks related to a lack of testing and research became very clear.

Let's use this as a learning moment...

Because it was such a surprise to learn that the filter panel was insufficient and that our product didn't get the workflow entry point right due to a lack of research, it was a great time to keep pushing for research and usability testing. As the Tanzu labs designer who was senior to my Pharmacy labs pair, I presented arguments for research and steps we could follow to get moving in the right direction.

We did it! We got buy-in for Usability Testing with Benefit Analysts!

Through presenting the information above to Business Automation stakeholders and raising discussion in our weekly product team retro, we finally got buy-in to test with real actual users: Benefit Analysts at the health insurance company.

Now, let's align on a process...

We collaborated with design practice leads, business stakeholders, and our product team to come up with a transparent testing process that everyone felt comfortable with and that could be reused by other teams.

Let's get to work...

Due to AG Grid's technical limitations and the way the data team formatted data points to be singular, we couldn't implement a solution that involved typing serial values on one line. So we collaborated with developers to come up with a solution together. We designed an interactive prototype based on the most technically feasible solution which was basically a user-friendly query builder.

We used the workflow examples provided to come up with Search Templates that might help the user save time and grasp the concept of the search tool more quickly. We also created a save search feature to allow the user to name and reuse searches that they build from scratch.

If a user loads a template (spoiler alert...they all chose a template rather than building a search from scratch) they just have to fill in blank values. This was as close as we could get to their original workflow.

Because we wanted to test the smallest version, we did not prototype for the ability for users to add entire additional criteria sets. We wanted to explore the simplest option first to make sure we didn't overbuild the feature.

But because some of the workflow examples provided had 4-5 value sets needed, we did add the ability for them to build out a single set of criteria.

Let's test our idea...

Below shows an overview of how we set up our research along with the results of our assumption testing and the themes that emerged.

What changes were needed?

Most of the themes that emerged didn't require changes and our prototype was overall successful. But the one big change that was definitely needed did really need th4e ability to add additional criteria sets.

My impact...

I am proud of establishing design thinking and a regular user research cadence within the context of an existing business ecosystem and adding value to the product. This is just one example of an outcome I achieved on this team, but I worked on multiple problems like this for a duration of 4 months.

I left the team with the experience of what healthy build, measure, learn cycles look like along with frameworks and processes in place that help them continue to iterate on their collaboration and methodologies in a way that makes sense for their team and product.

But that UI was pretty underwhelming...and why is it so low res

As is the case with large enterprise Tanzu Labs clients, I often have to work within existing design systems that are limited and immature. I also am unable to download high res files due to NDA's and system monitoring.