Design leader.
Systems thinker.
Care is in the details
I enjoy being close to the details. In my personal life I am drawn to things that let me take my time and soak up moments to obsess over the little things.
From code to systems
I began building interfaces in code which has shaped how I think about building systems that ship.
The best teams play
I love figuring out how to make great work happen with what we have.
Two teams
becoming one.
TurboTax and Credit Karma teams are officially becoming united as a consumer group in 2026. What would it look like for the design systems teams at each to operate as a unified team before the merge?
Shared
Features.
Finding, and shipping, the experiences that belong to both products.
"Points on
the board"
Say hello to our first shared component across TurboTax and Credit Karma, the first experiment of this new AI experiences component shipped during TurboTax's first peak. How we made it happen is the fun part.
Managing the
connective tissue
Shared Features is two-thirds of the team I manage. My job: identify the right opportunities, shape the design artifacts that tell a unified product story, and navigate a complex web of stakeholders , product, engineering, and platform teams across two technically distinct architectures.
This role sits at the intersection of management and IC craft. I'm not just directing , I'm actively shaping the strategic framing, running cross-functional alignment, and making sure the work we ship actually lands in product.
How we
found the work
Map shared jobs to be done across both product surfaces. Find the experiences where a single component , or a single design pattern , can serve two ecosystems without asking either to compromise.
Work with Intuit platform teams to understand existing integrations, technical constraints, and the backend architectural gap between TurboTax and Credit Karma. Know what's buildable before committing.
Create the design artifacts, run cross-functional alignment, and move from concept to live experiments in product , not just Figma files sitting in a shared library.
The AI Chat
Library
The first library built under the Consumer Design System (CDS) name , designed to serve the consumer group across both apps. Built as a working proof of what CDS components can look and feel like in the wild, ahead of the formal design language unification.
Beyond
chat
Creating a shared visual language for the TurboTax and Credit Karma app headers , a high-visibility, cross-platform design problem with real org implications.
Unified views across both apps. Requires understanding how Intuit platform teams currently plug into Credit Karma and where the technical seams are.
Identifying behavior overlap in specific components and creating shared design patterns , starting with where both apps already agree on intent, if not form.
Two systems
One design
TurboTax and Credit Karma have technically incompatible backend architectures. Real shared experiences require more than shared designs , they require understanding how platform teams are plugged into each app, what's feasible today, and where to push for alignment versus work around constraints.
The lesson: systems thinking in this context means holding the design layer and the platform layer simultaneously. The Figma file is only half the work. The other half is knowing who to call, what question to ask, and when to stop designing and start aligning.
What we
shipped
- First cross-platform design system library built for the unified consumer group
- Live experiments in both TurboTax and Credit Karma , first CK experiment this week
- Framework established for identifying and prioritizing shared jobs to be done
- Cross-org relationships built across PM, engineering, and Intuit platform teams
- Operating as one design systems team months before the org officially merges
AI
Readiness.
Extending the design system beyond Figma — everywhere designers and engineers actually work.
The design system
only lives in
one place
A mature, well-maintained design system in Figma is invisible to the tools designers and engineers increasingly rely on , Lovable, Cursor, Figma Make. The result: components get rebuilt from scratch, drifting from the source of truth. Inconsistency compounds at scale. The design system stops being a system and starts being a reference doc.
"A button in Figma is a button in code. Exactly."
The charter: extend the design system so it's available wherever people work. Every component in Figma should have a coded equivalent , and those two things should match, one to one. Not approximately. Exactly.
Building the
pipeline
Develop a system for exporting tokens and foundational data from the design system as structured, LLM-readable output. Figure out what "readable" actually means in practice.
Extract component data from Figma , not just metadata, but behavioral intent and relational structure , in a form that an LLM can reliably interpret and act on.
Build a pipeline that consistently produces coded assets closely matching their Figma counterparts , iterating until the delta between design and code becomes negligible.
Proving
it works
- All foundational components processed through the pipeline ✓
- Large subset of the full component library complete ✓
- Results: closest to 1:1 match of any approach previously used at Credit Karma
- Now tackling data visualization components , the most structurally complex challenge
- Actively validating outputs in a live prototyping environment
Global Engineering
Days
During Intuit's hackathon week, we turned the pipeline toward a new platform , and built a proof of concept for SwiftUI components on iOS.
The result wasn't just a cool demo. It was evidence that the approach isn't web-specific. The same pipeline , the same way of thinking about structured Figma data and LLM generation , can extend to anywhere code is written.
The signal: AI Readiness isn't a project. It's a platform-agnostic methodology for extending design systems into the full surface area of how product gets built
Engineering
came to us
Engineering got wind of what the team was building , and wanted in. Not just for prototyping, but for production. A three-week sprint just kicked off to explore whether the pipeline can be made robust enough to generate production-ready components at scale.
This is the Stronger Together moment: a design systems initiative that started as a design problem is now reshaping how engineering builds , because the work proved itself. We didn't pitch this to engineering. They came to us
What we've
built
- A repeatable, documented pipeline for generating coded assets from Figma components
- SwiftUI proof of concept built during GED week , platform-agnostic validation
- Engineering partnership forming around production-ready component generation
- A framework extensible to any tool that accepts coded components: Lovable, Cursor, Figma Make
Design systems as
connective tissue
Both projects are the same bet, placed twice: that great design systems work isn't just about components , it's about connecting people, teams, and products in ways that create momentum. The "how" is always cross-functional. The output is always shipped The measure is whether the org moves differently because of the work.
I'm not just building a design system. I'm building the conditions for two organizations to work as one.