Benefits Destination

Background

Where this started

Every year, enrollment season hit the same way. A pile of client requests, not enough time, and sites that were technically different but doing the same thing. Each one was built from scratch. Each one had its own quirks. And every customization added to the next one’s timeline.

The business needed a way to serve hundreds of employers without treating every single one as a unique project. I needed to figure out how to design for flexibility without losing the structure that made the product work.

Discovery

Understanding the full picture

Before jumping into solutions, I spent time mapping the actual pain. I talked to the teams configuring the sites, looked at the patterns across existing clients, and traced where the bottlenecks lived. What I found was that most variation was surface-level (branding, language, a few plan differences), but the underlying structure was nearly identical across clients.

That told me we didn’t need more flexibility. We needed better defaults, with flexibility in the right places.

Process

How I approached it

I started with the components that appeared in every single client site and worked backwards from there. Once I had a clear inventory of what was truly shared vs. what was client-specific, the system structure became obvious.

The work

What we built

The core of the solution was a templatized system where the structure was locked but the content, branding, and plan configuration were exposed as client controls. Clients could set up their own benefit websites without needing to open a support ticket for every change.

On the employee side, I redesigned the enrollment flow to actually guide people through their options rather than just presenting them. That meant surfacing the right information at the right step. Not everything upfront, and not making people hunt for it.

Client config panel

Employee enrollment flow

Accessibility & inclusion

Built for every employee, not just the ones who read English

Benefit enrollment is already complicated. Doing it in a second language shouldn’t make it harder. For clients who opted in, the platform supported translated benefit content, a combination of machine translation and human review to make sure the language was accurate where it mattered most.

My job was designing the workflow that made that possible inside the platform. How content moved from English source to translated output, where human reviewers stepped in, and how the internal team managed it without a separate tool or process.

Learnings

What I’d do differently

This project taught me a lot about designing systems that other people configure, not just systems that designers control.