Redesigning Annual Enrollment
Role
Design lead
Timeline
Sept - Dec 2025 (4 months)
Team
Researcher, PM, Dev Leads, Stakeholders
Tools
Figma, FigmaMake, Miro, Co-pilot
CONTEXT
Alight's biggest moment was overdue for a rebuild
Annual Enrollment is Alight's Super Bowl, the one flagship moment each year when nearly all of its users touch the product at once, making decisions about their healthcare for the next year. If something breaks, it breaks for everyone, in the same week, when Alight can least afford it.
But the flow they were relying on hadn't kept pace. Years of client-by-client customization had left it outdated and fragmented and it showed in the feedback: employees consistently described the process as overwhelming, without a clear sense of where they were or how much was left.
Our challenge was to re-align the flow before the next enrollment cycle began.
The cost of confusion
PERSONAS
Two users types, two different needs
Alight sells to its Fortune 500 HR leaders, not to the employees who actually use the product. If enrollment confuses employees, support tickets escalate, and so does operational cost. Eventually, that shows up as a renewal decision, made by someone who never had to click through the flow themselves. Design has to impress the client without frustrating the people who actually use it.
IDEATION
Merging the teams to align
We kicked off the project with an intensive, cross-functional alignment workshop. Representatives from engineering, domain leads, PMs and design convened to unpack the architecture.
We mapped flows, identified gaps, and sketched early directions together. We successfully built a shared understandings and constraints to tack the problem together.
CONCEPTS
Single vs. multi-page structures
The workshop ended with the room split in two directions: a single-page approach optimized for speed, and a multi-page designed to reduce cognitive load.
We needed to test it.
CONCEPTS TESTING
User preference isn't always the right move
We tested functionality, not user-desirability.
The research objective was to validate navigation, the stepper, and flow clarity. Asking users which layout they prefer at the end of test is a different question entirely.
We tested both concepts on navigation and task completion, and both worked, users finished the task clearly and can navigate back without friction. But when asked which they liked better, they consistently chose the Single-Page setup. I had to take a closer look at it.
The prototype used fabricated data.
Participants clicked through placeholder content, and simple questions with no personal weight. Real enrollment questions involve personal healthcare decisions, and sensitive choices. The cognitive attention of the actual product is different from what we tested.
UX principles of cognitive load.
People make better decisions one step at a time. A single-page layout might look simpler and appears to accelerate the flow, but it would overwhelm the user. Multi-page allows users to have more control over the pace, one topic, one task, one screen.
RE-ALINGMENT
Building the argument
To secure executive buy-in for the Multi-Step design, I couldn't rely on design principles alone, I had to build an argument system backed by real business cases.
Instead of presenting a design prespective, I walked stakeholders through each argument and scored the matrix with them live. The end result spoke for itself, with multi-step having the path of lease resistance, I was able to quantify design decision forward.
The redesigned enrollment experience
A guided, step-by-step experience that helps employees make confident decisions about their coverage — breaking a dense, single-page form into one clear decision at a time.
Leadership approved, not on preference, but on the business and systems case.
The compromise
Multi-Step couldn't feel like starting over from scratch every year. So we built in a faster path for returning users, especially those with more complex situations, like multiple dependents.
Reflection
This wasn't a perfect project. Here's what I learned from where it.
Designing against research is highly uncomfortable. Before this project, I would have treated "users prefer X" as a strong signal to move toward X. This project rewired my thoughts to be more critical when connecting research data with the conditions they were under.
Designing for scale forces better decisions. Having to design a system that works across 4,000 different employer configurations pushed me to make decisions I might otherwise have deferred. I have to find a pattern that will work with clients that may offer all benefits to just one benefit.
And What I would have done differently
Set success metrics and product roadmaps early. We never established the success metrics nor the roadmap at kickoff. That gap created the conditions for the summary page to land mid-project, with no solid foundation of what success looks like.