Know Your Benefits: turn policy confusion into instant clarity

Working with Data, Backend, Ops, Onboarding, Sales, and Client Servicing, I synthesized member interviews, customer-service tickets, claims data, and stakeholder conversations.

The diagnosis: the problem wasn't persuasion. Members knew cashless existed but couldn't tell what their plan actually covered, so reimbursement became the safe default.

Sales sells every client a custom package, and the UI was force-fitting all of them into one rigid layout. Auditing live client configurations with Sales and Onboarding, I found that every policy — however custom — maps to one of five structural patterns based on how money flows.

This became the backbone of the system: design once per pattern, and any policy Sales can sell is covered.

Employees use benefits but don't understand them. HR fields questions the platform should answer. The business loses margin on every reimbursement. Sales sells custom packages into one rigid UI.

I mapped the journey into phases to surface the highest-friction tasks and align the team on what to act on. The map shows members know cashless exists — but they don't understand their benefits: what's included, what's excluded, how the process works, who's eligible, what the limits are. The comprehension gap is the friction.

I worked with the team to identify every user story through the JTBD lens, then mapped each to its current pain and design response across five jobs: Understand, Check, Verify, Use, Find.

The JTBD map let the team align on a prioritised plan with defined scope, known constraints, and design impact — turning an ambiguous problem space into a roadmap. We scoped the first launch to P0: the comprehension layer and the pattern system.

I ran working sessions with Backend, Frontend, Ops, and Onboarding to define and align on the page architecture — how the wallet, sections, and detail pages would adapt to all five patterns while sharing one codebase.

Grounded in the research and the IA, I explored several layouts. Testing with internal teams surfaced the core issues: everything shown at once overwhelmed members, technical labels like "T1, T2" confused them, and cryptic eligibility codes made coverage unclear. Members didn't know who was covered or how to use their benefits.

Acting on that feedback, I consolidated the scattered information into a progressive flow. Members land on a wallet hero that matches their pattern, browse grouped sections, tap to expand cards, and reach detail pages with clear tabs. The path from "what do I have" to "how do I use it" went from eight confusing steps to six clear ones.

I tested three layout models: a flat list showing every benefit detail at once, grouped sections with expandable cards, and progressive disclosure with a dedicated detail page per benefit.

The flat list overwhelmed members — too much information, no hierarchy. Grouped sections were better but still dense. Research showed members wanted to glance first and drill down only when needed. Progressive disclosure with detail pages matched that mental model.

Working with Frontend, I designed the core components that make the page work across all five patterns — consistent where it should be, adaptive where each pattern needs to surface its own information.

Two calls shaped the product more than any screen. I pushed the team from one rigid layout to a pattern-based system despite the higher upfront cost. And I killed a feature — configurable per-service caps — after a working session with Backend surfaced that the many-to-many data model couldn't enforce it. Shipping an honest dual-constraint display beat promising HR a control the system couldn't keep.

Every benefit renders through one card component. Across the five plan patterns it renders 39 distinct services — six body variants cover the states a benefit can be in, and modifiers layer on top: nested bars, per-claim caps, member co-pay, discount banners, programme strips.

The constraint I held: the collapsed row is identical in every variant — icon, name, one-line status, one balance figure. Only the expanded body changes. A member scanning the page never has to re-learn how to read a row.

Sales sells limits, not layouts. A benefit might draw from the shared pool, own a ring-fenced wallet, carry nested sub-limits, or be capped separately for cashless and reimbursement. Each needs a different balance display — but the same card anatomy.

The rule I set: one number when collapsed, the full structure on expand. The member sees "what's left"; the structure only appears when it changes what they can do.

A benefit isn't just "available." It can be locked behind a life event, waiting on enrolment, fully used but still discounted, or discounted-only from day one. Each state needed an honest label and a clear next action — never a dead end.

The rule I set: nothing disappears. A used-up benefit stays visible with its self-pay discount, because hiding it makes the member think they never had it.

Before handoff I walked the prototype through with Ops, Client Servicing, and Onboarding — the teams who field member questions daily — using real client configurations across all five patterns. Two changes came out of it: the Service Chooser modal ("Use benefit" was too vague) and relocating "Used in this service" into the card header so it was visible without scrolling. Every pattern was verified with automated screenshot comparison after each iteration.