DH · MMXXVI
All Work Shown
Property Of
Intuit
Design leader.
Systems thinker.
From tinkering on vehicles, to drawing tiny art, to photography I really enjoy focusing on the details. Sweating the small stuff, waiting an hour to get the right shot, buying the smallest micron pen. I enjoy a creative pursuit that lets me obsesses over things and make them just how I want.
I began building interfaces in code which has shaped how I think about building systems that ship. I love complex systems and making them easier to use or understand. Finding cretive ways to bring experinces to life and leave users feeling accomplished are work fuel for me.
The best work of my career has been being a part of a team that is encouraged to explore and find ways to get creative and ambitious work done. I love figuring out how to make great work happen with what we have. Constraints are creative inputs and I have grown most as a leader in coaching teams to own constraints as ways to propel forward.
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?
Finding, and shipping, the experiences that belong to both products.
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.
We aim to learn what it takes to ship cross-BU design in market. Each shared feature serves as both a product improvement and an experiment, helping us validate new visual directions, gather customer signal, and build conviction for the long-term Consumer Design Expression.
We needed to find out how to ship experiences across products when we don't write code. HMW build trust across the new consumer org and be deliberate in how we bring value inside of it?
It made the most sense to have the team work directly with the feature teams 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.
Partnership was the best choice, we needed to know what would actually work and stress test our designs with what teams actually planned on shipping with engineers who planned to build it.
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.
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.
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.
The design system, available anywhere a designer chooses to work.
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?
We chose to evolve.
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.
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.
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.
View the demoEngineering 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. This started with a design problem. It's quickly becoming a new way for design and engineering to build together.
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.