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"
The rainbow chip is our first shared component across Credit Karma and TurboTax, shipped live in product during TurboTax's peak season. This is what it looks like when two design systems teams operate as one.
Two products. Two systems.
One team trying to connect them.
TurboTax and Credit Karma have technically incompatible backend architectures and separate design systems built over years of independent development. The question I was brought in to answer was whether shared UI experiences were even feasible, and if so, how a design systems team should approach building them.
I came in to answer a question nobody had resolved yet. Getting to a shipped component meant mapping the technical landscape, building trust across two product orgs, and being deliberate about how my team would operate inside both.
Embedded,
not adjacent
I chose to put the team directly inside the feature work rather than hand components over a fence. That meant protecting dedicated collaboration time across two organizations, staying close to implementation reality in both codebases, and navigating the constraints of shipping during tax season when TurboTax's risk tolerance is at its lowest.
Embedding was the slower choice. It was also the only choice that produces something that fits a live product under real constraints. I made the call to protect that collaboration time — it wasn't a default way of working.
The AI Chat
Library
The first library built under the Consumer Design System name, designed to serve the consumer group across both apps. Built as working proof of what unified CDS components can look and feel like in the wild, ahead of the formal design language unification.
One win
becomes a model
The rainbow chip proved the approach. I am now building it into a repeatable framework for cross-product collaboration. The work in flight now is not a collection of separate projects. It is the same methodology applied to new surfaces, with each partnership adding to what we know institutionally about how two design systems can operate together.
A shared visual language for the TurboTax and Credit Karma app headers. High visibility, cross-platform, with real organizational implications for how the two products present themselves as one.
Unified views across both apps built on the same embedded partnership model. Requires deep understanding of how Intuit platform teams currently connect to Credit Karma and where the technical seams are.
Identifying behavioral overlap in specific components and creating shared design patterns, starting where both apps already agree on intent if not on form.
Building the
factual foundation
Before proposing an ambitious shared vision to leadership, I led an investigation into what shared UI actually requires technically. That meant mapping platform dependencies, understanding the architectural gap between the two products, and auditing the accounts and profile surfaces across both apps to understand where shared components were feasible and where they were not.
I didn't design a single component until I understood what we were actually dealing with. That audit became the factual foundation for everything I brought to leadership.
Using the how to shape the what
- Operating as one design systems team months before the org officially merges
- 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
AI
Readiness.
The design system, available anywhere a designer chooses to work.
Lock them in, or
meet them where
they're going.
Designers were already experimenting with AI tools outside of Figma. When they did, they left the design system behind. Components got rebuilt from scratch. Inconsistency compounded. Our VP of Design identified AI readiness as a strategic priority, and the question became clear: do we try to keep designers inside Figma, or do we evolve the design system to exist wherever they work?
I chose to evolve it.
Daily iteration,
systematic learning.
I worked directly alongside Kim and Dave running structured daily experiments, exporting Figma components and iterating with Cursor. The goal was not to find the right answer on day one but to develop a rigorous understanding of the variables: what made outputs better, where component complexity degraded quality, and what the model actually needed to produce something worth shipping.
I was in the experiments, not directing from a distance. That proximity to the craft is how I found the patterns that became the methodology.
Console logs
for AI.
The key discovery was that output quality is not just a function of input data. It depends on how you interact with the model during generation. I developed an approach I call console logs for AI: strategic interaction points built into the generation process that guide the model toward the intended output. This changed how we thought about the pipeline entirely.
Component complexity affects output quality in predictable ways. Once I understood the pattern, I could design around it instead of fighting it.
Three workstreams.
One sprint.
Ten hours.
During GED, I merged Sarah's visual exploration work with our AI tooling pipeline. In a single day, one designer went from a blank environment to a fully interactive React prototype with micro-interactions, at a quality level indistinguishable from a Figma handoff. That result proved the approach was teachable, repeatable, and faster than anything we had done before.
This isn't a project. It's a platform-agnostic methodology for extending the design system 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. We are currently running a proof-of-concept sprint to validate whether the pipeline can generate production-ready components at scale while maintaining design system integrity.
We didn't pitch this to engineering. They came to us. That's the signal. I started with a design problem. It's becoming a new way for design and engineering to build together.
What we've
built.
- A repeatable, documented pipeline for generating coded assets from Figma components
- Fully interactive React prototype built in 10 hours during GED, proof of both quality and speed
- Platform-agnostic validation: the same approach produces SwiftUI components on iOS
- 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.
