Acute Pharma Ordering Capabilities

UX Design Thinking Process

What research challenge were we asked to solve?

Leadership questioned the need to rebuild certain capabilities for the new ordering platform for hospital users. They wondered if large healthcare organizations were employing more sophisticated digital solutions from other providers and were no longer using these capabilities from the Cardinal Health ordering platform.

Because the legacy site had not been appropriately tagged, usage numbers were complex to uncover, and accuracy needed to be more reliable. That is why we could only hypothesize.

One such capability was Interdepartmental Billing (IDB). This feature allows Buyers and Lead pharmacy techs to track the flow of medications between departments, create bills for departments in their network, and streamline the billing process.

This feature serves as an example of how we used the design thinking process for multiple capabilities to help determine the need and improve the experience in a limited amount of time.

To comply with my non-disclosure agreement, I have omitted and obscured confidential information in this case study.

Discovery Research

business goals

Need to sunset legacy ordering platform
Numerous features to rebuild from the legacy ordering platform
Uncover opportunities to eliminate features or reduce complexity to save time and money

WHAT WAS THE PLAN TO ADDRESS THIS?

Our research journey began with the invaluable insights of our internal Interdepartmental Billing SMEs. Their quick accessibility and frequent interactions with account managers and customers made them a reliable initial barometer regarding customer usage and reliance on the functionality.

As the interviews were taking place, we recruited and prepared for remote 45–60-minute contextual inquiry sessions with customers to help us answer our initial research questions.

Research Questions

What do they use IDB for, how do they use it, and why?
What value does IDB provide?
What are the risks of not providing this capability to customers?

Participants

2 internal Interdepartmental Billing SMEs
7 legacy platform IDB users

Findings & Results

Buyers and lead techs mostly use IDB to bill across departments for requisition items to bill the appropriate department.
IDB is critical to hospital networks’ billing process(s) to ensure accountability for different departments, resource allocation, and accurate cost tracking.
Without IDB, billing the right departments would become a manual task, increase labor, and pose a risk of increased errors in billing.

There were also a few usability issues that came out of the study. One of the more significant ones centered around the homepage IDB Account Activity module.

In this experience, participants did not interact with and seemed confused about the purpose of the IDB homepage panel. Most viewed IDB as the next logical step from Requisitions.

“You can also, after you fill the requisition, you can put those products onto the IDB for the month... It’s just one click instead of typing it [drugs product] all in again.”

— Participant 5

UX Feature Discovery Audits

INITIAL QUestions

The discovery research findings paved the way for the next phase of our project. Hospital systems were dependent on the IDB functionality. Our UX Design partners began their discovery process, focusing on simplifying the functionality of the IDB platform to reduce rebuild costs.

Initial Questions:

How does IDB currently work?
- Permissions and department set up
- Billing
What steps does a user need to take to bill the correct department?

UX Feature Audit Process

Jobs-to-be-done

The first audit we conducted was identifying Jobs-to-be-Done. We wanted team alignment on our customer needs and where we had room to make improvements. UX worked with Development and Product to identify the workflows that affect a user’s ability to do the following:

Access IDB accounts & departments
Create, view & edit departments
Create, view & close bills & credits
Print & export billing data
Find closed bills
Search for products
Add products to bills from credits, invoices, lists, & requisitions

USER FLOWS

After establishing the Jobs-to-be-Done, we collaboratively mapped the specific steps needed to complete those jobs and learned some essential insights in the process.

IDB needs to enable users to:

Manage billing of requisitions
Export and print bills or credits to share with internal accounts payable teams
Track the flow of medications between departments

Limitations in Current-state:

Unable to go between departments without restarting workflow
There is no way to quickly get to the department that you want on the Account Summary page
Without the Search function, you are unable to find a specific bill unless the exact date is known
Because bills and credits are combined in one table, it isn't easy to differentiate them

Heuristic Review

The heuristic audit evaluated the legacy interface against a set of standard guidelines —or best practices. The evaluations helped identify design issues in the current interface and establish a baseline goal for improvement in the design.

Some of the identified design issues:

The intended use for the Account Activity IDB homepage module was unclear
There is no indication of successfully created bills
It isn't easy to find editing bills or credit details
Eliminating tooltips for input fields
Error states when copying an invoice to create a new bill
Difficulty distinguishing between intermixed bills and credits because with little to differentiate

UX/UI Design Solution

UXD redesigned the IDB flow to be more efficient by:

Bringing the IDB Jobs-to-be-Done to the beginning of the users' workflow instead of at the end
Users can create bills and credits directly from the IDB landing page without navigating to a department first
Navigating between departments from any point in the workflow
Reducing the number of screens & steps

Further improving the experience:

Providing users with the ability to remain on the page, create multiple bills at once, and associate with a bill from the table
Increased findability within page searches and wider date-range filters
Separating open bills from open credits

LEGACY IDB

Navigating into bills and credits required moving back and forth between pages. There was no way to move seamlessly between departments.
Heuristics uncovered insufficient affordance to distinguish between bills and credits on the same list.
Initial research uncovered that participants do not enter IDB through the homepage component. They prefer to enter through Requisitions.

Redesigned IDB Experience

Bills and credits can be accessed directly from the landing page instead of having to navigate into a department.
All account departments are listed on the left rail, making it easier to move between departments
Bills and credits separated into two different lists
Focused design changes on the 'Accounts Summary' page.

Evaluative Research

WHAT WAS THE PLAN TO ADDRESS THIS?

With the redesigned experience, we conducted a workshop session with the SMEs and product team. The workshop allowed us to address:

knowledge gaps we had about the existing experience
questions about the prototype that needed validation and
blue sky ideas for this feature, like automated bill creation

This workshop became the basis of the Evaluative research study. Collaboratively, we discussed our questions, concerns, and hypotheses about the redesigned IDB flow. Our plan was to uncovered user pain points, gather feedback on the prototype, and get a temperature check for users' appetite for automated features.

business goals

Need to sunset legacy ordering platform
Numerous features to rebuild from the legacy ordering platform
Uncover opportunities to eliminate features or reduce complexity to save time and money

Research Questions

What specific features of IDB do customers use and why?
Where does IDB fit within their workflow?
What pain points do customers experience while using IDB?
Is the redesigned IDB experience intuitive and usable?

Participants

9 legacy platform IDB users

Findings

All participants use the IDB capability to keep a record of products that departments order, request, or move between departments.
Several participants reformat the IDB data to fit their Accounts Payable requirements.
Nearly all participants use Requisitions and IDB in tandem, and Requisitions is the primary gateway for a few customers.
Nearly all participants agreed that the redesigned version of IDB improved legibility and recognized they were only looking at open bills and could find their credits in the next tab.
All participants appreciated seeing most of their departments at a glance. However, they all also wanted to browse over 7-8 product columns at a time, therefore needing to see more of the product table information.

Results

The evaluative research insights guided improvements in the revised version of the IDB designs, demonstrating the commitment to evolving the experience iteratively.

redesigned IDB flow - tested

Department navigation on the left rail was always in view.
Users had Bill type, ID, and Departments available to create a new bill.
Users were provided with Filters for the days they wished to view the table and the ability to customize the date range.

Final round of revisions for MVP

Participants wanted more real estate for the important table content, so the left navigation now collapses.
Participants also used the billing date for new bill creation, so it was added to the component and changed to a simple CTA to bring the table higher.
Filters were also removed to bring the table higher on the page - slimmed to a customer date range and search field.

Lessons Learned

WHAT DID THIS PROJECT TEACH ME ABOUT RESEARCH, DESIGN, OR MYSELF?

This case study illustrates how well UX Research and Design teams worked together in concert and brought our cross-functional team members along with us in this work. Although initially, it felt like the design thinking approach was taking longer, the careful upfront planning and steps saved us time and provided the confidence our teams needed to call the MVP ready for our customers' use.

The case study also serves as an example of user insights influencing product strategy. Otherwise, the vital functionality to our hospital customers could have been excluded from the product roadmap and threatened to compromise patient care.