Enterprise UX
Information Architecture
Cross-Functional Collaboration
Designing a Guided Annual Enrollment Experience
Turning a complex benefits decision into a guided, personalized experience across enterprise constraints.

Overview
Role: Product Designer
Timeline: October 8 – December 12
Team: 2 junior and 2 senior designers
Primary ownership: Personal Health Packages and Additional Benefits steps
Status: Launched
At Alight Solutions, I helped design a new guided Annual Enrollment experience as part of a four-person team. I co-defined the overall enrollment journey and owned the Personal Health Packages section end to end: the page where employees reviewed, compared, and selected a health benefits package built around their own household, usage, and finances. I also designed the Additional Benefits step that follows it.
The Challenge
Choosing benefits asks people to weigh far more than a plan's price: deductibles, employer contributions, tax savings, and what happens if a "normal" year turns into an expensive one. We needed an experience that guided people through that decision without taking away their control, made dense financial information digestible, and still shipped on a fixed deadline within Alight's existing design system and engineering constraints.
Structuring the Journey
Together with the team, we split enrollment into six stages (Profile, Personal health packages, Package follow-ups, Additional benefits, Benefits summary, and Completed), supported by a stepper. That structure turned one overwhelming decision into a sequence of smaller, manageable ones. I owned the second and fourth stages and supported the rest of the journey.

We also drew on lessons from an existing benefits-recommendation product, working directly with the designers who'd built it. Rather than copying their patterns, we used what they'd learned to decide what would actually hold up for Alight's users and systems.
Translating Research Into Decisions
A dedicated researcher ran the studies; my job was interpreting what came back and turning it into interface decisions. One finding stuck with me: 3 out of 10 participants didn't understand the label "Supplement Benefit Plans." That single insight led to a renamed category, a clarifying tooltip, and a supporting footnote: small changes, but the kind that decide whether someone trusts what they're looking at.
Other sessions surfaced things that weren't as easy to fix in one pass. Several participants said they had no way to know how their packages had actually been put together, which told me the real problem wasn't the algorithm itself, it was that nobody could see it working. And when a later round showed people still getting tripped up between "Expected Year" and "Difficult Year" after we'd already touched that tooltip once, we went back in and revised it again. Not every fix lands the first time, and knowing when to reopen something you thought was done is as much a part of the job as the first fix. The final version is shorter: a plain description of the scenario, what it includes, and a pointer to "Estimated net annual cost details" for the full breakdown. An earlier version itemized every number inside the tooltip and explained everything well, but a brief tooltip was easier to digest, and the packages themselves now made clear where the costs came from.

Designing the Personal Health Packages Page
From sketch to final. I started on paper, exploring several layouts: a carousel that focused on one package at a time, cards with an expanded detail panel, and three tall cards with checklists. In those first sketches the three options were labeled OK, Good and Best. In the final version they became named strategies, so each package reads as a tradeoff and not as a ranking.


The first digital proposal listed every benefit open on the page and priced each package per pay period. The next iteration added personalization cards, Expected and Difficult Year scenarios, and collapsible sections. The final version brought in the six-step stepper, a toggle between pay period and annual costs, and plan-level detail.

I organized the final page around four decisions:
Making personalization visible. Upfront, participants could see exactly what was shaping their recommendations (household, anticipated usage, HSA balance, income) and edit anything that no longer matched their situation.

Your household income modal

Comparing strategies, not plans. Instead of a flat list of plans, we framed three package strategies (Hold Steady, Lower Premiums, Lower Deductibles), each representing a different tradeoff, with deductibles, copay, and coinsurance laid out side by side so the comparison people actually wanted didn't require digging through each card. Participants could also toggle between annual and per-pay-period costs.

Showing more than one price. Each package shows an estimated net annual cost for an Expected Year and a Difficult Year, so people can see not just what a plan costs normally, but what it would look like under pressure. An expandable "Estimated Net Annual Cost Details" table breaks both scenarios into the same components: plan price, out-of-pocket costs, employer contribution, tax savings and supplemental plan payouts. It also explains why a difficult year can net out cheaper for some packages. In Hold Steady, for example, supplemental plan payouts jump from $350 to $2,993 and more than offset the higher out-of-pocket costs. For someone who expects a hard year, that can change which package is the right one.

Managing density through progressive disclosure. Each package carried real depth: plans, coverage, HSA contributions, cost breakdowns, rationale. I used accordions to let people scan the essentials first and open what mattered to their decision, with clear paths to edit a package, explore alternatives, or build a custom one. Editing opens a short modal flow: pick a category, choose a plan or decline that coverage, then save and return.

I also designed for waiting and for failure. Calculating personalized packages takes a moment, so a skeleton state holds the layout in place and tells people their options are being worked out.
Designing Additional Benefits
After the package decision comes stage four, Additional Benefits. Product managers defined that this step needed to exist, and my job was to design how it should feel: a pause between choosing a package and reviewing everything else, with two clear paths. "Guide me" walks through key benefits before the Benefits Summary, and "Enroll on my own" goes straight to the summary to choose plans to review. It went through several iterations. In the end I built it with a new design system component and added photography, so the step feels welcoming and less like another form.

Working Within the System
Fitting all of this into Alight's existing design system was one of the hardest parts of the project. Personal Health Packages needed data density and interaction patterns the system didn't fully have answers for yet, which meant constant back-and-forth with senior designers and engineers to decide what to adapt versus what to build new, all against a fixed deadline.
Everything was designed for desktop and mobile. On mobile the three packages stack vertically and the stepper collapses into a compact step label, so the same decision works on a small screen.

The page went through many iterations, shaped by product managers, engineers, senior and junior designers, researchers, and benefits specialists, until it reached alignment across Product, Design, and Engineering by December 12.
Outcome
Personal Health Packages and Additional Benefits launched on time as part of Alight's new Annual Enrollment journey, connecting personalized recommendations to real household data, supporting comparison across best- and worst-case scenarios, and giving participants room to explore, edit, or build their own package. I don't have post-launch metrics to point to, but the project is proof I can own a complex, data-heavy product area and carry it from early mockups to something real people used to make real decisions.
What I Learned
Simplifying a complex decision never meant stripping out information. It meant giving people what they need at the right moment, and letting them open the rest whenever they want it.
With so many voices around the table, from product, engineering, research and benefits specialists, I learned to defend my judgment as a designer. In the end, someone has to speak for the person using the experience and make sure we guide them without overwhelming them. I learned to do that with evidence and respect, and to know which patterns are worth defending and which to let go.
I always enjoy working with people who think differently from me, and I loved working with this team. Their perspectives sharpened mine, and they made a demanding project a real pleasure.