The existing workflow forced pharmacists to move between disconnected systems, configure complex rule logic, and coordinate reviews manually.
Research with clinical pharmacists revealed four key problems:
Rule creation was unnecessarily complex, relying on technical AND/OR logic that didn't match how pharmacists thought about medications.
Work was difficult to track: Pharmacists lacked a centralized view of changes awaiting review, unpublished updates, and other outstanding tasks.
Peer review lacked structure: Changes needed to be validated by other pharmacy team members, but coordinating reviews and understanding their status introduced additional operational overhead.
The learning curve was steep: Workflows often required documentation or help from experienced team members.
I partnered closely with our internal pharmacy team throughout the project.
My research combined:
Interviews with pharmacists
Workflow observation
Surveys
Competitive analysis
Existing-state journey mapping
Reviews of RxFlex and internal Judi workflows
Recurring validation sessions with pharmacy teams
Because pharmacists were the subject-matter experts, I treated design as an ongoing partnership rather than a traditional research handoff. I met with pharmacy stakeholders throughout development to validate terminology, assumptions, interaction patterns, and edge cases before they reached engineering.
I kept our pharmacy team involved throughout the design process, partnering with product and engineering daily and meeting with pharmacy stakeholders biweekly to validate workflows, terminology, and emerging concepts.
I conducted moderated sessions with our pharmacists using realistic formulary scenarios. Testing focused on whether participants could:
Create a rule: Create a new coverage rule that applies to a specific medication and its broader drug classification.
Modify rule criteria: Add another medication group to an existing rule and update its coverage criteria.
Complete peer review: Locate a rule assigned to you for review, evaluate the proposed changes, leave feedback, and approve or reject it.
Find outstanding work: Using the dashboard, identify which items currently require your attention and determine what action should happen next.
Testing revealed two major opportunities:
Simplify rule creation: Pharmacists wanted to search directly for medications and classifications rather than navigate complex data structures, leading to a searchable multi-select experience built around recognition instead of recall.
Design around work, not navigation: Pharmacists thought in terms of what needed attention next, which shaped the dashboard around assigned reviews, rejected work, and unpublished changes.
Iterative testing helped refine workflows before development and produced measurable improvements:
The existing rule builder forced pharmacists to navigate complex filters and classification hierarchies to find medications. I replaced this with a searchable multi-select that lets users directly select medications, drug groups, classifications, and attributes—shifting the experience from recall to recognition while preserving expert-level flexibility.



As more workflows moved into the platform, pharmacists needed a faster way to understand what required their attention. Rather than making users navigate across the platform to find outstanding work, we added a central dashboard that surfaces high-priority tasks in one place, including:
Tickets awaiting review
Reviews assigned to the current user
Rejected changes requiring follow-up
Unpublished rules and utilization management controls
Recently updated work
Early testing showed:
~65% less navigation effort
~70% improvement in task discovery

Because changes can affect medication coverage for thousands of members, rules must often be reviewed before publication.
I designed a dedicated peer review workflow where pharmacists could:
See tickets awaiting review
Filter by status or assignee
Inspect rule changes
Leave contextual comments
Approve or reject changes
Instead of coordinating across systems, the review context stayed attached to the work itself.
We projected the redesigned workflow could reduce manual coordination by approximately 50% and shorten review turnaround by roughly 35%.


Designing the Product to Teach Itself

The individual improvements were valuable, but the larger outcome was creating a more coherent operating system for formulary management. Beyond the metrics, bringing formulary management directly into Judi gave the organization greater ownership over one of its most important operational workflows.
The biggest design problem wasn't the interface. It was complexity.
This project reinforced that enterprise design isn't about exposing every capability a system supports.
It's about deciding which complexity the user actually needs to see.
By deeply understanding how pharmacists reasoned about medications, rules, reviews, and outstanding work, we were able to translate a technically complex system into workflows that more closely matched their mental models.
The result wasn't simply a more usable replacement for RxFlex.
It established a foundation for a more scalable, intelligent formulary-management platform—and created opportunities for automation and AI that would have been difficult to pursue within the constraints of the previous system.


