Decision Support

Why this matters

Benefits confusion is a real problem

Before getting into the work, here’s the context that made this project worth doing in the first place. These aren’t my numbers. They’re industry research that shaped the brief.

The throughline: when employees actually understand their benefits, they feel better supported, they stay longer, and they make better decisions for themselves and their families. The platform wasn’t helping them get there.

The brief

Three asks, one timeline, zero wiggle room

The project came in with three separate pressures pulling in different directions. The product team wanted AI-powered benefit guidance. The sales team wanted a modernized UI to drive engagement. And the business wanted all of it in three months on top of an existing legacy system.

Discovery

Finding out what was actually possible

Before designing anything, I needed to know what the system could handle. I worked closely with engineering to map out technical feasibility, document constraints, and make sure I wasn’t designing for a fantasy version of the platform. That investigation shaped every decision that followed.

The biggest find was the HIPAA issue. The AI needed health-related inputs to generate recommendations, but as an HR platform, we couldn’t store that data. The solution: session-only retention. Data stayed live long enough for the user to get their recommendation and make a selection, then it was wiped. No storage, no violation.

I also mapped every scenario where a user would need benefit recommendations during enrollment: medical, life, voluntary additions, retirement. Each had its own workflow. Documenting them side by side helped surface overlaps we could consolidate, and clarified which benefit types needed personalized recommendations versus statistical ones.

User flow. Enrollment journey

Flowchart. Data handling

The solution

A modal. Not my first choice, but the right one.

With the constraints clear, I started working through how to actually surface the feature. The business wanted users to stay within the page. No external navigation, no new screens pulling them out of the enrollment flow. Given the legacy system architecture, that left one real option.

I ran a quick wireframe sprint: multiple layout options, team vote, fast feedback loop. With three months on the clock there wasn’t room for extended deliberation. Once the direction was locked, I moved straight to high-fidelity mockups so stakeholders could actually visualize the feature rather than interpret wireframes.

I also handed the dev team a working demo with cherry-picked HTML, CSS, and JS, not because they needed me to write their code, but because it closed the gap between design intent and implementation in a way that documentation alone wouldn’t.

High-fidelity modal. Question state.

High-fidelity modal. Results state.

Outcome

Shipped on time, adopted in the field

The feature launched within the three-month window. The first integrated build showed personalized recommendations rendering directly in the platform UI, which was the proof point we needed that new solutions could genuinely coexist with legacy architecture.

Post-launch, employees reported more confidence and clarity in their benefit decisions. And because I anticipated that the full UI vision wasn’t achievable in this round, I proactively built out a detailed future-state mockup, so when resources and timelines allowed, the foundation was already there.

Learnings

What I'd tell myself at the start