“
Sabrina Comins, Decisely
Creating a UI for mapping group structures allowed two new ben-admin clients to manage their enrollments with Noyo.
Smaller ben-admin platforms tend to rely on a complex spreadsheet to manually map their members into insurance carrier codes for billing. This process is not compatible with Noyo's API, it's time-consuming, and it's costly for the ben-admins.
As the Design Lead, I:
Led research workshop sessions
Conducted usability testing sessions
Created all our mockups and prototypes in Figma
Collaborated with engineers & product managers
Category
0-to-1 Design
Role
Design lead
Methods
Research, usability testing, interaction design, prototyping
Type
Web app
I held several workshops with key stakeholders to understand the mapping process, and to see in their own words (and drawings) what an ideal mapping tool might include. I learned that the process involved custom variables and conditionals, required a lot of copy and pasting in a manual spreadsheet, and that other data sources often had to be referenced for more context.
After learning about the needs of the tool, I built a clickable prototype and held usability sessions to test it out with internal and external stakeholders. 100% of the users I tested were able to complete the mapping accurately with minimal assistance, even those who were new to the concept of mapping.
I designed a rules-based UI within the Noyo dashboard. Clients are able to easily manage their data mappings in a way that is compatible with Noyo's main offering, the API.
Key findings from discovery
The mapping process had “rules” that used custom variables and conditionals. It seemed a lot like coding.
There was a lot of redundant manual copy and pasting in their spreadsheets
If you didn’t know the specifics of the insurance carrier codes, creating rules to map to them was a lot more difficult.
Usability testing results
100% of participants were able to complete the mappings accurately.
Some rules needed to be weighted higher than others, so we ended up adding a priority indicator.
We needed a catch-all rule so that any members not captured by a rule would still land in a carrier category
The split-screen view was working well, allowing participants to scroll each side as needed to scan, reference, and compare data.
Providing more information about carrier codes was helpful for those who didn’t know anything about the codes, and allowed even users who knew nothing about mapping to confidently create accurate rules.
Adding information about the insurance billing codes (like member types, locations, and other data) enabled the users to make rules that would put the right people in the right billing codes. It mattered much less how experienced they were with mapping, or how much they knew about the insurance carrier codes - the contextual details paved the way.
During our workshop sessions, I observed that our users were essentially coding to categorize data, but using a spreadsheet. We needed a way for them to be able to effectively write code in the UI, but more efficiently than their spreadsheets.
One of the assumptions at the beginning of the project was that users would not need a UI to populate their dropdowns, since they would be able to use the API to do that. So I did not test that part.
However, when we actually onboarded them, we realized that they were unable to use the API, and we had to quickly figure out a workaround for them.
