Date: 2021-2022
Role: Senior product designer and also acted as a co-PM around launch
Official launch announcement here
Background: Members need to be categorized correctly in the insurance company systems. However, insurance companies and benefits administration (ben-admin) companies often use different classification systems. In order for the systems to get synced, ben-admin companies have to map their data to the insurance company’s data. This is either done by managing large spreadsheets by hand, or by building custom code at the ben-admin platform.
Problem: The traditional solutions to this mapping issue are costly to build and maintain, time-consuming, and not the same across ben-admin platforms.
Goal: Our goal was to build a in-app tool that would allow ben-admin companies to easily and quickly map their data to the carriers’ data.
Process: My team and I talked to people who either previously or currently did data mapping at ben-admin companies. We needed to understand the ways in which the mappings were done, where the pain points were, and how these folks themselves would envision a tool that would make their jobs easier. We held workshops and collaborated closely with them as we prototyped. We held prototyping usability sessions to see where we needed to make changes. Once we were satisfied with the results, we launched the product. Then, we observed how the tool was being used, to see if it held up with their data.
Result: We hit our goal of making an easier-to-use mapping tool, which is now in use by several Noyo partners.
The right side of the screen contains all the possible categories at the given carrier. It can be scanned quickly (usually there are no more than 10-15 categories, but this could vary) and each category can be opened up to show more details about the category, which can help the user understand why each category exists and how they might classify their data to the carrier’s. For example, category 83346-1 might have a descriptor of “employees only” and “CA residents”, which means you would not map dependents from Michigan to this category.
The left side is where the magic really happens - users create their own rules that map to the carrier categories. For example, if they wanted to map to category 83346-1, they might create a rule that says “IF member type is employee, AND state is California, map to category 83346-1”
Users can also duplicate rules, like if multiple rules are very similar, and deactivate rules, rather than deleting, in order to save and energy. They can also prioritize rules the way that they see fit - perhaps one rule is more important than the other, and needs to be run first.
They can also determine if there are no categories that someone can fit in, to put them in a specific category - rather than those people getting uncategorized by accident.
Now that we’ve seen the final product - let’s check out some of the process to get there. We’ll start with the some of the results of the workshop.
The above screenshots are images of our workshop results. We (as the team building the tool) had never done any mapping ourselves, and needed to understand what this process was like. It turned out it was slightly different for everyone, and everyone used slightly different terminology.
It seemed like there was a clear consensus of there being “a result categorization at the carrier” and “how do ben-admins arrive at that categorization”. There were also several types of things that would be mapped at once, like some carriers had classes and divisions, others had billing codes and plans. So, we’d need to account for multiple categories of things being mapped at once.
One of the earliest prototypes (shown above) - it was based on the idea that we would use kind of a guided 1-2-3 step process. We had thought that maybe existing spreadsheets could get uploaded and parsed by the system, but that idea turned out to not be feasible in our project scope. This mapping screen was pretty simple, and did not account for enough rule complexity.
In this version, the thinking was that we could display the existing spreadsheet and parse out the mappable fields on our end. Then, users could create a more complicated rule for each field.
This one has many of the same concepts as the previous one - complex rules and parsed out distinct values. But, the spreadsheet would be displayed as built-in UI objects (not just an iframe)
We also realized a couple of things: we didn’t need to use a 1-2-3 step process because there wasn’t a particular order things got done in. So we got rid of that.
We also decided we needed more focus and more working space in the UI. So, we collapsed the home menu and created a full-screen focus view of the tool. Once users were done mapping, they could leave the page and return to the main screen.
Another thing we thought might be useful would be to be able to manipulate the columns, such as pinning them, so the rest of the columns could be studied for context while keeping the user’s place on the column being mapped.
By the time we got to this iteration, we realized that uploading and parsing a spreadsheet was not only out of scope but also not needed to create a useful tool.
We kept the focused view because that was testing well with our collaborators, as were complex rules. We also realized that the main action on the page was actually creating the rules, so we moved that to the left. It also works better in this order because English is read left-to-right, and putting results on the right not only felt like it made more sense, but also tested better.
We also realized that we definitely needed to provide more context about each carrier category, because a common question we got during our testing was “How can I learn more about this category - how will I know who goes in this category?”
After testing these prototypes we learned that even though the general mechanism of rule making was clear, it was unclear what each side was - it was not highlighted, for example, that the right side came from the carrier.
So in the final version (below), you will see that we added that to the title of the right side. We also added a little tracker summary on that side, to show you how many categories are left to map, also based on feedback/observation. And, we found that we needed to add a category for any potential stragglers, anyone who wasn’t accounted for with the rules that were made.
Not pictured, unfortunately, is the screens a user sees after hitting “publish”. What they see is a more readable summary of all the rules they made, so that they can view them once more for accuracy before going live with them.