Overview

Simplifying a complex internal workflow

We set out to design an internal tool for RxChange employees to improve a complicated process workflow. Their in-house Pharmacists use the process to build out alternate medication recommendations to save customers money.

Why does RxChange matter?

Adults fill 4.5 prescriptions per month on average. Each bottle costs approximately $53, which totals $238.50 being spent on prescriptions every month. RxChange offers quality alternate medication recommendations that can save customers 80% of what they are paying. This puts $191 back into the customer’s pocket each month. When looking across an entire year, the customer could save over $2,000.

Problem

Reduce the bottleneck

Dr. Brett Jones is the primary Pharmacist making recommendation switches for RxChange. His current process is completely manual using Google Sheets. The documents are cumbersome to navigate and do not easily allow for quality checks and sometimes result in a duplication of work, all of which creates a bottleneck in the workflow.

The team at RxChange wanted a tool that could house all of their medication switches and interact with their other internal tools, so that they can operate more efficiently and process more recommendations.

Users & Audience

Pharmacists are the primary users of this tool

The users for this tool were the employees of RxChange. We spoke with several different members of the team and identified that the primary user of this tool was Dr. Jones, the in-house Pharmacist. Using an affinity map, we created a persona off of Dr. Brett Jones and the part-time Pharmacists on his team.

The affinity map allowed us to understand the goals and pain points in Dr. Jones’ current workflow and determine what we needed to address when building the tool.

Motivations

• Process more recommendations

• Less confusion within the tool 

• Provide quality recommendations

Goals

• Reduce risk

• Reduce time 

• Reduce technical error 

• Save people money 

Frustrations

• Using multiple spreadsheets

• Relying on multiple external websites

• Multiple screens needed to make decisions

• No checks and balance system

• Duplication of work

• Time and complexity of manual tasks

• Overall navigation

Roles & Responsibilities

• Timeline: 3 week sprint

• Team: 3 designers

• My Role: Information Architect, Interaction Designer

• Tools: Slack (stakeholder communication), Trello (project management), Figma (wireframes & prototyping)

Scope & Constraints

Building a brand new tool in 3 weeks

The biggest constraint with this project was the limited timeframe to build a tool from scratch. Since none of our design team was familiar with pharmacy or drug knowledge, we had to ramp up quickly to understand the work that was being done by Dr. Jones. Once we wrapped our heads around the subject matter, we then had to craft the interface design.

There’s a lot we wanted to be able to include in the tool, but we had to stay within the original scope of the project. The tool needed to be able to add, edit, and delete. As this was an internal tool and there aren’t many visible competitors, research was a bit tricky. Most of our insights came from RxChange employees and other internal systems. We were unable to complete a standard competitive analysis. We also were unable to interview a larger user sample for the persona we created due to limited number of employees.

Design Process

Design Studio

Because this design challenge was not a redesign of an existing site, the design team had different inspiration for how the new tool should look. To bring the designs to a productive place, we engaged in a design studio to flush out the concepts.

Site Design

None of the websites relating to pharmaceutical medications we reviewed provided the same functionality of the tool we were attempting to build. However, we did notice the functionality we were trying to create had some similarities with task-based tools like Salesforce and Zendesk. When building out the site framework, I leveraged the versatility of a left-hand navigation to help orient the user and provide easy access to a variety of tasks. This was largely influenced by the answers we got during user research. Many of the people we spoke with said the initial view they expected would depend on what action they needed to take at a given time.

User Flows

Usability Testing

Because the users of this tool are internal employees and there was an NDA in place, we were not able to test with external users. We completed usability testing with the in-house Pharmacists that would actually be using this tool. Here are the primary takeaways:

“Can I see the preview of a fax?”
Users really want to be able to see a preview version of the fax with information populated before it gets pushed live to the doctor. Due to the scope of this project, I had not originally included a preview fax button in the design.

“I need to view all relevant actions.”
There are many different actions that can be taken on a specific task. Being able to see them all in one place is really important to the user’s workflow. This created a challenge as it meant there would be nine buttons that needed to be visible instead of five. My solution for this was to group related actions under a button dropdown.

“I expected to see a different page.”
Originally, the user would see the display page after saving a new medication or switch, which confused users. Because the workflow can differ depending on the task at hand, the user didn’t necessarily want to go directly to the display page. Users need to see options of what action to take next after building out a new function or deleting a page. Additionally, this allows us to track user behavior in the future to learn more about their needs and behaviors in the tool.

Style Guide

Prototype

Outcomes & Lessons

Our client was pleased with design we came up with. They are currently discussing next steps internally to see if this design fits into their product roadmap. To date, this tool has not been launched. Regardless, they did confirm they plan to integrate some of our features across their existing internal tools.

Takeaways

• Learning a new subject matter can be a challenge. The best way to ensure that it doesn’t slow down the project is to immerse yourself completely in the material. It’s also critical to ask questions when you’re unsure and never make assumptions about a topic you don’t understand.

• Research limitations are a reality with some projects but that shouldn’t prohibit progress. It’s important to get creative and find the best alternative to get the research you need when encountering research constraints.

• When taking on a big project in a short period of time, the dangers of scope creep are constantly present. It is critical to take the time to understand what constitutes an MVP (minimum viable product) and to use discernment about features that can wait.

Next Steps

Due to time limitations, there were things outside the scope of the project we couldn’t work on. If I continued to work on this project in the future, here are the items I would want to tackle next:

• User education and help

• Permission level and security settings

• User analytics and task tracking