Design that
moves
systems forward.

Medicare Advantage plans offer supplemental benefits - allowances for eligible health-related purchases - but the way those benefits reached members was broken. Dense explanation letters. Confusing eligibility rules. No clear path to actually spending the money. Members left value on the table, not because they didn't want it, but because the system never made it feel accessible.

The product I designed solved for all three sides simultaneously: give insurers a differentiated plan offering, give members a dignified and simple spending experience, and give vendors like Amazon a compelling integration model that brought high-intent, benefits-allocated buyers to their platforms.

The physical welcome kit was the first act of the experience - and the most underestimated design decision. For older adults, trust is built through tangibility before it is built through digital interaction. Every element in the print material had a direct continuation in digital onboarding, so the member never felt they were starting over when they opened the app for the first time.

In-app onboarding used progressive coach marks - not a tutorial dump. Each coach mark appeared at the moment of first use. The mental model was built through doing, not through reading. The sequence was designed so a member could stop at any point and resume without confusion.

The core mechanic - splitting the benefit allowance across multiple spending accounts - used a visual allocation model that members could adjust before confirming, giving them control without overwhelming them with financial complexity.

The vendor integration layer was the commercial heart. From within the same app, members navigated directly to a vendor's storefront with their allocated benefit amount already recognised. I defined the handoff interaction, eligibility signalling, and the return-to-app flow after purchase.

The organisation had no design system - and no shared language between design, product, and engineering. Every team was solving the same UI problems independently, every sprint.

Inconsistent components. No reusable patterns. One-off solutions built in isolation every time a feature needed a UI. Product managers and engineers describing the same thing with different words, creating rework on almost every ticket. I was the only designer, sitting at the intersection of all three disciplines, watching the friction compound silently with every release.

The problem wasn't that people didn't care about quality. It was that there was no shared infrastructure to care about. Without a system, consistency was a matter of individual effort on every single ticket.

The design system wasn't planned in full upfront. It grew organically - one component at a time, driven entirely by what the product actually needed next.

Each time a new feature required a UI pattern, I designed it in Figma with the system in mind: what's the most reusable version of this component? What states does it need? How should it behave across different contexts? Rather than designing for one feature in isolation, I designed the abstraction that would serve that feature and every future one that needed the same thing.

That discipline - thinking one level above the immediate problem - was what turned a series of feature designs into a design system. It wasn't a single initiative. It was a repeated decision, made every time a new component was needed.

As each component was designed, I worked closely with one UI engineer to bring it into Storybook - maintaining complete parity between what I'd designed in Figma and what was implemented in code.

This wasn't a periodic handoff. It was a continuous, feature-paced collaboration. A new component would be needed, I'd design and spec it, we'd build it together in Storybook, and from that point forward it was available to every team across every product. The system grew every time a product team needed something new - and the growth was cumulative.

The live Storybook became the shared reference that design and engineering both trusted equally. Not a static document to be maintained separately, but a living implementation that stayed in sync because it was built that way from the first component.

One of the most important things the system did had nothing to do with components. It gave product, design, and engineering a common vocabulary - and that changed the texture of every conversation.

Before the system, I was the only person fluent in all three disciplines. I spent a significant amount of time translating - between what product wanted, what design had built, and what engineering could implement. Every misalignment cost time. The system externalised that translation. Once a component had a name in both Figma and Storybook, a product manager could use that name with an engineer and both would understand exactly what was meant. I was no longer the required bridge in every conversation - the system was.

Adoption happened because the system made development genuinely faster - not because it was mandated. Engineers across multiple product teams came to it because it solved a real problem for them.

I trained each team on how to use what had been built, and kept iterating based on what they found missing or unclear. The feedback loop was fast because the system was already growing with product needs anyway. Early adopters became advocates. When engineers started independently reporting that development had become more predictable - that they were spending time on product logic instead of rebuilding UI - that was the moment the system had become genuinely useful rather than just technically present.

FSA and HSA accounts are genuinely valuable - but only if users can understand them. The existing platform assumed a level of benefits literacy that most users simply didn't have, and the interface did nothing to close that gap.

The product covered the full lifecycle of consumer health benefit accounts: checking balances across FSA and HSA accounts, reviewing eligible transactions, submitting reimbursement claims, and completing the CIP (Customer Identification Program) process to open an HSA. On paper, it was comprehensive. In practice, users were left to decode complex financial terminology, unclear account hierarchies, and dense transaction views with no guidance on what they were looking at or what to do next.

The original interface had no design system, no consistent component patterns, and no governing hierarchy for how information was weighted. Each screen felt like a separate design decision - which meant users who moved between them lost their bearings constantly. The product had accumulated features without ever establishing the visual and structural language needed to hold them together coherently.

Understanding how general public users interact with financial health products required getting out of the building. I used guerrilla testing - real people, real reactions, no lab - followed by structured moderated sessions to go deeper on what the street testing revealed.

Guerrilla testing was the right entry point here precisely because FSA and HSA literacy varies enormously in the general public. Some users had never heard of an FSA. Others had accounts they'd never fully used. Taking the existing product to public spaces gave me fast, unvarnished signal: where did people's understanding break down, what terminology stopped them cold, and which flows felt logical versus arbitrary.

The patterns were striking and consistent. Users could not reliably distinguish between their FSA and HSA accounts on screen. The reimbursement submission flow was abandoned at high rates - not because users didn't want to claim, but because they couldn't tell if they were doing it correctly. The CIP process for opening an HSA felt like an interrogation with no explanation of why each piece of information was needed or what would happen next.

Moderated sessions followed with users who had active benefit accounts. These sessions were task-based - submit a reimbursement, find your balance, understand an eligible transaction. Watching users navigate the existing product while thinking aloud produced a precise map of the decision points where confidence broke down. This fed directly into the affinity mapping phase.

The affinity maps grouped observations by behaviour pattern - not by feature. This reframing was critical: it prevented the redesign from inheriting the old product's structure and revealed the four failure modes that cut across every part of the experience.

The four patterns were: inability to establish account context (users couldn't quickly orient to which account they were in and what its current state was), terminology breakdown (benefit-specific language used without definition or scaffolding), action uncertainty (users couldn't confidently identify what to do next after any given state), and process opacity (multi-step flows like CIP felt like black boxes with no progress model).

Before a single redesign screen was produced, I established the design system: component patterns, typographic hierarchy, spacing rules, and a consistent interaction model for status, action, and confirmation states. The system was the precondition - not a deliverable to follow the redesign. Every screen that followed was an expression of the same rules, not a local creative decision made in isolation.

Alegeus operates as a white-label platform - the product is adopted by benefit providers (employers and their administrators) who brand and configure it for their own end users. This meant the redesign couldn't assume a fixed visual identity. To solve for this, I designed a CMS configuration page for admins - the benefit provider layer - that allowed them to apply their own theming: brand colours, typography, logo, and tone. The design system's token architecture made this possible cleanly: admins could remap the surface without breaking the underlying component structure or interaction logic. Any client could make the platform feel like their own product without redesigning it.

The redesigned flows addressed each failure mode directly. Account context was established at every entry point - balance, account type, and status were always visible and always scannable. Benefit terminology was progressively explained inline rather than assumed. Reimbursement flows were rebuilt with clear progress indicators, explicit eligibility signals, and confirmation states that told users their action had registered. The CIP process was redesigned as a guided, human-toned experience - each step explained, each data request justified, and progress always visible.

At a hackathon, I reimagined the entire platform around a different premise: what if your benefits account had a team of specialists working behind the scenes - each one an expert in a specific domain - and the interface was simply where they surfaced their insight to you?

The concept was called Benefits Whisperer. Rather than a dashboard you navigate, it was a proactive, personalised experience driven by a multi-agent AI architecture. Each agent had a named role and a specific domain of expertise - together they formed an internal advisory system that monitored your accounts, transactions, and health profile, and surfaced exactly the right guidance at the right moment.

The agent system was orchestrated in two tiers. At the top, Orion acted as the orchestrator - receiving event triggers and user chat input and routing to the right specialist agents. Sherpa functioned as the planner, coordinating multi-step reasoning across agents before surfacing a response. Below them, a layer of specialist agents handled distinct domains: Bella (Benefit Sage) for plan guidance and eligibility, Cory (HSA Contribution Coach) for optimising tax-advantaged contributions, Ivy (Investments Guru) for HSA investment decisions, Una (Utilisation Guide) for spending and reimbursement coaching, PepTalk for behavioural nudges and engagement, PayMint for payment actions, and Pulse for health and benefit trend monitoring. External vendor agents - MolarMole (dental coverage) and DontGoBrokeR (telehealth scheduler) - connected the system to third-party services via an MCP server layer.

The UI reflected this architecture directly. Rather than a menu of features, the home screen was a Personal Health Benefit Assistant - a living, personalised surface showing proactive insights and recommendations generated by the agent layer based on the user's past interactions, transaction history, and benefit utilisation patterns. A health recommendations screen surfaced agent-generated, contextually relevant suggestions (not generic tips). An HSA contribution analysis screen combined Cory and Ivy's outputs into a rich investment opportunity view. A separate HSA Investment Opportunity view brought financial projection intelligence directly into the platform.

The design challenge was not building the agents - it was designing the interface layer that made a complex multi-agent system feel like one calm, trustworthy advisor. Every surface had to feel coherent and purposeful, not like a chatbot with extra features bolted on.

The hardest thing to design is not an interface - it's a belief. This project was about making investors see a future that didn't exist yet, clearly enough to want to fund it.

Early-stage retail concepts live and die by how quickly a stakeholder can picture them. The vision here - a future of neighbourhood retail that is more accessible, automated, and affordable - was bold, systems-level, and abstract. A pitch deck wouldn't do it. What was needed was an experience that let the idea unfold in real time, both emotionally and intellectually.

I was brought in to translate Tom Fanara's retail vision into a concept video for investor storytelling. My role was not to execute a brief - it was to reframe the idea itself as a user experience, then build the narrative system that made that experience legible to an investor audience in under two minutes.

Before a single prompt was written, I mapped the narrative arc as an experience journey. The story had to move through four emotional beats: speed and immediacy (ordering essentials instantly), intelligent automation (real-time fulfilment behind the scenes), seamless access (the pickup experience), and finally community impact - the systemic vision that made the concept worth investing in. Each beat answered the question the previous one raised. The structure was the design work.

The AI toolchain was itself a design system to be orchestrated. ChatGPT handled scripting and narrative iteration. Kling generated cinematic sequences from refined prompts. Canva assembled, sequenced, and polished the final output. These tools weren't used in isolation - they formed an iterative pipeline where the output of one stage informed the prompts of the next.

A significant portion of effort went into visual coherence: eliminating motion inconsistencies, improving realism across generated sequences, and maintaining a premium, investor-grade feel across every cut. The quality bar was set by the audience, not by the tools.