Project Details
MY ROLE: Product Designer
COMPANY: Cigna
DURATION: 8 Weeks
PRODUCT TEAM: (1) Product Owner, (1) Product Designer, (10+) Dev Team, (5) Data Team
COMPANY: Cigna
DURATION: 8 Weeks
PRODUCT TEAM: (1) Product Owner, (1) Product Designer, (10+) Dev Team, (5) Data Team
About
When Members make a payment to Hospitals, Doc offices, or pharmacies they all use different platforms to collect and share that data. Payments are reflected in the member’s balance and determine how much the member needs to contribute to their deductible before they can stop paying out of pocket. If the claim platform, provider, and member all have different data it’s difficult to determine who is responsible for payments and why.
We needed a system that can collect data from various claim platforms, that data then has to be researched, validated or reconciled to produce a single source of truth that can explain why Cigna couldn’t pay a claim or why the deductible might be more/less than expected.
Problem Definition
The initial discovery workshops were between myself, the product owner and the development team lead. I interviewed the product owner to elicit the context around the design opportunity. We then worked together to identify a group of user we could use for upfront research. I conducted interviews with users from each of the 3 teams that our product will be supporting. We focused on defining the problem, recognizing the impact it had on our members, and identifying the value this project brings to the business.
It was important to me that we considered the member as the end user in this project. While the user would be the person interacting with the product itself, the member would be most impacted by it. This helped us see the problem from the member’s perspective as well as the business’s perspective.
To sum it up: Members want to be sure they are paying the right amount for treatment/drugs so that they can trust and continue their relationship with Cigna.
During user interviews we learned that users needed to bounce between a number of green screens to find data from different sources. After a few mins of searching for the right data and cross referencing different Claims Platforms the user’s screen quickly is overwhelmed with information from several different sources, making their process very cumbersome. These screenshots do a great job of capturing the messy process the Claims Adjustment team needed to go through each time they want to adjust a claim.
After sharing insights from user interviews, I worked with the product team to develop and refined our problem statement:
“As a user I need to be able to find, review, and validate payment data from various claim platforms so that we can build trust with our members by accurately identifying member balances and who is responsible for payment, but the information I need is spread out across many platforms and documents that might not share info with each other.”
This fits into the overall vision of the project :
“Build trust with Cigna members by providing a source of truth on their deductible balance, so that it is up to date, accurate and we can identify who is responsible for payments.”
So our design prompt for this project was:
“How might we design a central location to collect, reconcile and validate data between a given claim platform (i.e. Facets, Power, Proclaim, etc)
Design
The ideation phase started with user flows of what the current process looked which we were able to capture in our upfront user interviews. We then shoped those flows around to the development team as well as the team of data scientist to get some idea of where we could combine the data and how feasible our solution was.
The product team and I worked quickly to design some rough wireframes that we can use to test with our users.
The first prototype was a dashboard that let the user know how many claims discrepancies they needed to adjust. Allowing the user to quicky drill down to find the information that they need about those claims.
We knew we some users would have discrepancies on multiple platforms so we designed this table that would show the user which platform they have discrepancies on. We had a lot of questions for the users during testing around how the discrepancies would be displayed so we wanted to show them allto the user to facilitate those conversations, but we knew eventually we would only show the valid platforms to the users.
The number to the right of the platform title was the number of discrepancies, if the user clicks that number we take them to a screen that shows the user Client Group that has one of more discrepancy.
if the user clicks on the count belonging to each client group the can drill down to see the member specific information. This is what they will use to write their claim adjustment request.
*I know what you’re thinking, why not just design it so the claims adjustment can happen from a button or some interaction that removes the data table from the equation all together. We designed a prototype for this but there were certain data limitations and part of the claims adjustment teams job was to reconcile the data itself. For example perhaps someone had the wrong group ID or there was other info that wasn’t correct. However the team is going to work towards this solution in the future.
The next we designed some rough prototypes for the claims adjustment request forms. The requirements we were hearing from the business included 3 different workflows, entering a single claims adjustment, entering multiple claims adjustments, and uploading an excel sheet with a very high number of claims adjustments. So we designed 3 rough prototypes that we could test with our users.
User Testing
When we tested this dashboard with our 4 sponsor users we learned some key takeaways. 2/4 users didn’t think the landing page was intuitive, they didnt know that you could click the number in order to see the client group and mismatch counts.
We also learned that the menu on the right was confusing to users as well. This was meant to be a menu of options for the user so that they can quickly navigate the app but also serve as a way to educate the user on the different features. We have to consider people who join the team for the first time and an on-boarding flow wasn’t in the budget. 2/4 users thought that they would select a platform from the left then choose and operation from the right.
From the claims adjustment forms we learned that all 4 users were confused by the multiple claims adjustment form. It sounded like updating multiple members claims could be done but we would still need to enter the information in separate forms for each member. In other words members dont share enough identifying information that we could do this all in one form.
Refine
User testing was super productive. We had a good amount of feedback/insights from our users for me to go back and make iterations to the prototypes. Starting with the dashboard. We added call to actions on the dashboard that made it much more clear to the user that they need to click into them to find the information they were looking for. We also visually changed the menu on the right so that it doesn’t look so similar to the platforms on the left.
For the Claims Adjustments request forms we refined the prototype to include a way to add multiple claims adjustments to a single transaction. Now that we knew the had to add multiple members information separately we were able to design this new form interaction.
Second Round of User Testing
We set up a second round of user testing with our users because we still needed to figure out how the multiple member claims adjustments were going to work. We discovered that the new dashboard was very successful, all of the users understood how to interact with it intuitively. But more importantly when we were showing them the multiple claims adjustments prototype we learned that while our designs were successful at allowing the user to perform this operation, 4/4 of the users said that to do this they would simply use the batch upload. The reason being that they would often do a single claim adjustment but very rarely do 2-3 at a time, typically they are either adjusting 1 person at a time or around 25 at a time. When the number of members increases it just becomes easier for them to use excel to enter the info.
What we learned
We were able to save the team at least 2 sprints by removing the multiple claims adjustments from the requirements. That allowed them to spend their budget elsewhere in order to help move the project forward. Often we hear requirements from the business that may not be what the user is asking for, I think this case study really shows the value of design and user testing.