A more intuitive experience for configuring benefits for Carrot customers
Context
In 2023 one of Carrot’s top goals was to enable “modular journeys”. In other words, Carrot wanted to offer more custom benefit packages to customers than what was currently being offered.
Problem
The internal administrative tool used to configure benefit settings for Carrot customers was not set up to allow these “modular journeys”.
Additionally, the existing tool was terribly confusing and disorganized, which occasionally led to companies being configured with the wrong benefit settings.
Goal
Enable the ability to configure custom benefit packages for Carrot customers, while creating a more intuitive user experience for the implementation team.
Role
Senior Product Designer
User Experience Research, Wireframing, Information Architecture, UI Design, Engineering Support
Team
Rebecca Gilbert, Product Manager
Jorge Enriquez, Content Designer
Bailey Peng, Engineering Manager
Ryan Burke, Erik Coonradt, Gigi Scarboro and Angela Lim, Project Engineers
Duration
7 months, 2023
*Duration includes research, design, and engineering
EARLY IDEATION
Information Architecture
The first order of business was establishing an information architecture that made sense to the implementation and customer success teams (the core users). Meanwhile, the architecture also needed to be conducive to growth since Carrot frequently added new settings.
Working closely with my Content Designer, we roughly outlined the architecture in a Google Doc. We focused on:
Improving the labels for each setting so they would make sense in the new architecture
Grouping settings into three large buckets: company information, general company settings, and journey-specific settings
Further grouping the settings by journey type under the journey-specific settings
Nesting settings that relied on each other
Adding new settings that would allow for custom benefit configurations
It’s worth noting that while we did not conduct any formal research for this project, we frequently collaborated with internal stakeholders who use the customer configuration tool on a regular basis. This looked like shadowing folks using the tool, a Slack channel dedicated to collaboration, and frequent design review meetings to collect feedback.
Early Wireframing
With the introduction of nested settings, we needed to visualize how this might look in the customer configuration page, and determine if or what settings might need to be added to make this work.
I used Figjam to translate our rough Google Doc concept into a wireframe, as I find it helps the team focus on architecture and layout rather than pixel perfection. Below are the first and last iterations that I explored in Figjam. There were three iterations between these that went through design reviews with the rest of the UX team, engineers, and core users.
DESIGN
Phase 1: Laying the foundation for “modular journeys”
Before we could add modularity to the company configuration tool, we needed to apply the new architecture and a new design system. This allowed the implementation team to get used to the new experience before we introduced more complexity with “modular journeys”. It also allowed the engineering team to work on this project in phases.
Design system
Just as we were beginning the design phase of this project, another team was starting to revamp Carrot’s design system to be more accessible. This allowed me to influence the design of core components that were essential for the company configuration tool. I worked closely with the design system team on the error states for form inputs, and emphasized the need for a tooltip trigger point.
Note: the toggle component is not seen in the final designs because it was not ready and in the design system by the time we launched this project. Instead you will see a checkbox in place of the toggle.
Nested settings
I also took this time to establish the visual design for nested settings, paying special attention to those that had multiple layers of nesting.
Engineering started implementing the final “pre modularity” designs, while I continued working with my Project Manager and Content Designer to think through the next two phases.
Phase 2: Enabling modularity for menopause and low testosterone journeys
To keep with a phased approach we started applying modularity to our less prolific offerings: menopause and low testosterone.
With this approach we needed to ensure the implementation team understood that fertility care and preservation, adoption, and gestational surrogacy were still sold as a package. In other words, a company could choose to only offer menopause and low testosterone benefits to their employees, however, if they wanted to offer adoption then they still needed to offer fertility care and gestational surrogacy.
I explored several ways of handling this. The simple solution was to provide guidance above these settings and flag an error message if they were configured incorrectly. The more complex solution was to group fertility care, adoption and gestational surrogacy under one setting. We ultimately chose to go with the simple solution since this phase would only exist for a couple months.
Phase 3: Enabling modularity for all journey types
The final phase of work focused on enabling all benefit offerings to be modular. From a UX perspective, this was the easiest phase as I just needed to enable locked settings and remove any explainer text that was specific to the previous phases.
Additional Considerations: Parent page
The screens I’ve been showing thus far have all been for the “child” company configuration. In addition to the “child” page, I redesigned the “parent” company page to have a more logical information architecture and to reflect the new design system. The work for these pages were happening simultaneously, as they are directly tied to each other.
One thing I had to consider during this process was how to treat the components on the “child” page that were directly tied to the “parent”. Because these settings had three options, I landed on a dropdown where implementation managers could select “Parent: [--]”, “On”, or “Off”. If a child was connected to a parent, then these settings defaulted to “Parent: [--]”. This means that if the setting is changed on the parent configuration, then it also changes on the child. If “On” or “Off” is selected then, it overrides the parent setting.
RESULTS
A more intuitive company configuration tool that also allows Carrot to offer custom benefit packages.
These changes helped Carrot meet its goal of being able to offer custom benefit packages to customers.
The information architecture and design system changes also help new implementation managers onboard much faster than they previously did. This is especially important when Carrot hires contract employees for a couple months during the open enrollment season.
As we launched each phase of this work, we continually received positive feedback from the core users. In particular, the implementation team expressed their appreciation for the following:
Conditional logic:
Reduces cognitive load by hiding settings that should not be applied
Tooltips:
Previously the team had to refer to separate documents to understand each setting. The tooltips remove this back and forth.
Error handling:
By flagging errors and preventing a user from saving an incorrect configuration, we greatly reduced the number of companies that are configured with the wrong benefit package.
REFLECTIONS
This form got VERY long very quickly, and it will only continue to grow as more settings are added. This makes it challenging for users to review a company’s settings and can cause slow loading.
In the very early stages of this project we had considered the idea of breaking the form into sections—either a page by page form or collapsing sections that are not in focus. We did not move forward with this concept because we figured it was out of scope for engineering. In the end, we finished this project several months ahead of schedule. It was great that we were able to dedicate time to smaller and often neglected projects, however we probably could have applied one of these other concepts after all. Not to mention, it would have prevented the very likely need to revisit the design of this form in the near future.