A note before you scroll. This project is from 2018 — three design systems ago, and the visual language shows it. It is here for the scope and the research, not the chrome: seventeen separate applications collapsed into one, and the user interviews that made the case for doing it. If you want to see my current visual and interaction work, the Leapfrog platform and MedLab case studies are the recent ones.
Project Overview
So what are we talking about here?
MedImpact is a PBM (pharmacuetical benefits management company). One of the key deliverables MedImpact offers its clients is the creation and maintenance of benefits to clients such as Kaiser Permanente. Over the years, more and more applications have been created to support this process as needs and requirements have evolved.
What's the problem with the current system?
As mentioned, the current process comprises of many different applications to support the creation of benefits and the components that comprise them. In return, turn-around-time for Benefit changes/creation is not at fast as market desires. In addition, MedImpact pays a large amount of warranty payouts due to configuration errors and is suffering from employee retention due to convoluted workflow.
Enter ECS - the new workflow solution!
ECS is a visionary application that redefines the end-to-end creation process. The new workflow will be role based and broken into two intuitive streams: project creation and task management. From initial customer consultation to publishing their new benefit, we anticipate this application will improve turn-around-time to meet client expectations, reduce warranty payouts as well as reduce onboarding and training of new employees.
Context around this case study
This case study covers the end-to-end contextual flow of benefit creation against its current state and the user pain points that drove the redesign.
How UX Helped
As lead UX for this initiative I scoped out this initiative and prioritized the UX deliverables based off business needs given a tight timeframe. Not all elements of UX analysis and design were budgeted for the project so I leveraged what I could within the time constraints. So that being said...
What did I provide?
- Contextual inquiry around current user interaction outlining several pain points
- Huerestic analysis of current system helped me provide current user flow vs target flow diagram
- Conceptual modal via iterative wireframing
- Highly interactive and high-fidelity Axure RP prototype used for usability testing and stakeholder demo
Contextual Inquiry / Pain Points
I interviewed 3 users: a project owner, a task configurer and a supervisor of client services. I asked the supervisor to create a common task scenario to walk through with the two users. Both roles needed access points to multiple applications to complete their scenario. Each time the user needed to leave their current work flow to begin another within the separate application. It was very disjointed and to move from one activity to another (configuration to QC to approver) was done via email and moving the task along in Salesforce. The scenarios were realistic and the users stepped through the paces. Even with all the given data needed and no blockers, the process would still take days to complete with so many touch points. Upon asking the 2 users how they feel with the process within the given common scenario, there were several responses:
- Frustrated and disappointed
- Overall stressed out and overwhelmed
- Lack of automation
- "Feel I'm always in crisis mode"
- "I shouldn't need to be Einstein smart to do this job!"
Current Flow vs. Target Flow
As shown, the current flow touches 17... yes, seventeen different applications between the Configuration and Validation phases of creating a benefit. This is causing Configuration to be too manual and too complex with a lack of automation. It requires a high degree of knowledge required to be efficient/accurate to use all these tools and is not modular enough.
The target flow will be an intuitive wizard-based UI user experience that will require much less training. This will get benefits out to market faster to foster customer delight as well as greatly reduce configuration errors.. Instead of 17 applications, this will comprise of a single access point for the entire e2e benefit creation. From consultation to publication, the lifecycle of the benefit will live within the new ECS application.
Iterative Wireframing & Collaboration
We've spoken with the users and have a list of theirs and the business requirements. The data model has been created. The flow model has been created for the two defined user roles. We've collaborated with the Voice of the Client and Configuration Supervisors. Time to design!
While collaborating with some key stakeholders, we began wireframing out the project creation experience. The project will contain created tasks. These tasks will be assigned to different user "activities" (configurer, qc, approver, etc). These tasks will then populate the task worker's queue for them to begin their part in the benefit creation. These two swim lanes were whiteboarded and sketched in Axure for rapid review, then iterated. Once we had something we feel was baked enough to place in front of the users, we moved on to the next step... Interactive Prototyping.
Interactive Prototype and Usability Testing
This prototype walks through both the Project Creator and Task flows. Phase 1 testing was conducted in person with Scenarios for both roles. Each session was recorded via webex allowing us to review user behavior. I notated areas of user delight and concern and acquired qualatative user feedback that was prioritized and made into action items.
PW: Demo01
Configuration Services All-Hands Demo
Initial reaction was astounding. This was the first time most of the 50+ members of the team have seen the demo. There was true amazement upon some of the features and workflow. It made me feel very happy to hear comments such as, "I can't believe it. I'll believe it when I see it" and "I think I'm gonna cry". When I asked why she was going to cry, she stated that she's been here for a long time and this new application was something she never thought was possible.
Message from the the Director of Configuration Services
“This application will change the way you all do your work. The days of managing projects through Salesforce are now being replaced with a one access-point for your configuration. We will no longer have to shift between Classic, EFS and spreadsheets to configure a simple Plan Standard. I hope you're all excited as I am because this is BIG and really game-changing in regards to all of configuration.”
What it was built to achieve
The business case rested on four targets, and they are worth stating plainly because they are what the design was measured against during review:
- Seventeen applications down to one. A single access point for the entire benefit lifecycle, from consultation through to publication.
- Turnaround time fast enough for the market. Benefit creation was taking days of elapsed time, much of it spent moving work between systems and chasing it through email and Salesforce rather than doing it.
- Fewer warranty payouts. Configuration errors cost the company real money. Most of them traced back to manual re-entry across disconnected tools — which a single wizard-driven flow removes by design rather than by training people harder.
- Onboarding that does not take months. One of the interviewed users said it out loud: “I shouldn’t need to be Einstein smart to do this job.” Retention was suffering because the workflow was the hard part, not the domain.
Being straight about the outcome
I can show you the research, the flows, the prototype and the reaction from the people who would have to live with it, including the director who owned the function. What I cannot show you is a post-launch metric, because I was not the one tracking it after handoff. I would rather say that than put a number on this page I could not defend if you asked me how it was measured.
What I would point to instead is the project that came after it. The MIDAS Pre-Pay redesign applied the same method — contextual inquiry, current and target flow modelling, interactive Axure prototype, moderated testing before development — on a tighter scope, and that one I measured end to end: throughput up by half, per-claim time down from twelve minutes to seven, training time halved. ECS is where the approach was proven on a seventeen-application problem. Pre-Pay is where it produced numbers.