MSIT Partner Incentives

Where were they at?

Transitioning users to an entirely new platform is not easy. The mandate had been given to create a new platform to reduce the time and cost of processing PI claims. The existing system was more of a mail box, whereby partners submitted information regarding their claims for MS vendors to piece together and approve. With the number of partner claims increasing a new system was necessary sooner than later.

The new Partner Incentive portal was ambitious in its goals. The development had started prior to my introduction to the team and after my arrival, some of its limitations and cracks started to become apparent.

What did we do?

During my time, I was able to collaborate heavily with my UX team and the product managers to develop a wide range of ideal concepts and see a few of them into production. We faced some challenges integrating our team and work into the developer-centric agile process. Through with persistence and patience, we came to gain the trust of the engineers and increase our velocity and impact on the Claims product.

My Role (across all work samples) — User Research, Information Architecture, Interaction Design, Visual Design
Deliverables: — User Flows, Wireframes, Prototypes, Visual Assets

What challenges did we work through?

This project was very turbulent from the get go. Engineering was highly resistant to integrating the UX team and working with us to resolve partner needs that had been identified for change in the beta release. We did our best to establish trust and over-deliver on our part and keep pace with the velocity of the development team. A few months in some of the resistant engineers were removed from the project, which helped us push forward and led to more positive and amenable work environment that had immediate effects on velocity and meeting the partners product expectations.

How did it turn out?

I left this role for a new role after 9 months, but the team continued to push new work and evolve the product after its wide release.

Claim Filing

Early on, the program manager for Claims had communicated that they were experiencing long turn times and delayed payments to partners. The beta testers were having some difficulties filing their claims with the new tool and despite attentive claims support, we were not making progress toward reaching our target goals month over month.

I had dug into the claim process early on through an initial analysis of the claim form right after joining the team. Through additional conversations with partners in the beta and conducting my own extensive audit of every claim, I determined the form had structural and presentation issues that were contributing to our partners high turn times.

I proposed that we consider modifying the experience and built a web-based prototype to test my initial assumptions from my research. Unfortunately priorities changed and I didn't get the chance to get this in front of users to build a case to move forward. The video below shows the original and concept for context.

Duplicate Claims

As partners file claims, there is always a chance that some will include the same proof/invoices invalidly on additional claims resulting in an incorrect payment. To prevent that we needed a method for our vendor partners to determine if there were duplicates in our tool at the time of validation.

I worked with the vendor team to identify pain points in their existing process and developed iterative solutions that I validated with them directly. This led me to develop a solution that allowed the vendor to instantly run a query on the claim in review against all open and previous claims, instantly identifying possible duplicates for review.

Time Slider/Filtering

Our partners were expressing concern over the filtering functions of the Claims Summary page. The period always defaulted to the entire fiscal year, which most of the time was not an accurate reflection of claims funds being accumulated or reflecting the balance of those to try and recoup. This ultimately led to submissions which were either rejected or not paid in full because of insufficent funds.

With such uncertainty, I developed a new IA and visual design aligning it to our users needs, validating the direction via submitted feedback and rolling user interviews being conducted.

The preferred direction had to be pushed due to engineering constraints as we moved out of beta. The final version accomplishes the same goals of easily surfacing accurate fund amounts based on their programs periods by simplifying the methods of filtering. This led to higher partner satisfaction and fewer support issues filed.