How I Work
Designing intelligence into product.
I've been designing predictive and AI-native products for high-stakes decisions for most of my career. Investing at Ellevest, pet health at The Farmer's Dog, benefits at Nayya, revenue cycle automation at Adonis. Visual search and discovery at Shutterstock before that. The hype came and went. The work didn't. What changed recently isn't that AI got interesting. It's that the models finally caught up to the kind of product I've been trying to build the whole time.
The thing I've learned across those years isn't really about AI. It's about domain. Customers ask for a faster horse. My job is to know the work well enough (the claims, the benefits, the portfolios, the nutrition plans) to design the car they didn't know to ask for, and then make the intelligence inside it feel trustworthy enough to drive.
Domain depth is the unfair advantage
Most AI products fail not because the model is bad, but because the team doesn't understand the work the model is supposed to do. I spend the first weeks on any product mapping how the work actually flows. Shadowing ops teams, sitting with billers, reading the policy docs, watching real claims get worked. The AI gets useful at the moment the team understands the job better than the user does.
"Customers ask for a faster horse. The work is to know why they're riding in the first place."
Trust is designed, not promised
When you're designing AI, you're designing belief. Confident outputs aren't enough. People need to see the reasoning, understand the limits, and know when to override. I design for explainability, graceful uncertainty, and human override paths from day one, not as a layer added at the end.
"The best AI experiences make intelligence feel clear, with just enough magic.”
Ship to learn, not to validate
In AI systems, behavior beats Figma frames. Static screens can't tell you whether an agent feels trustworthy, whether a recommendation lands, or whether a workflow holds under real claim data. I lean on real prototypes and live data early, not to prove the design is right, but to find out where it isn't.
“Clarity of behavior matters more than clarity of pixels.”
Design systems are product strategy
A system isn't a component library. It's how speed, consistency, and edge cases get encoded into a team. I've rebuilt design systems from scratch at high-growth companies because the system is the product's velocity. Every shortcut you didn't take, every edge case someone else doesn't have to rediscover.
"A good system is a living conversation between product, design, and engineering."
How I partner
Good design doesn't ship in isolation. The work I'm proudest of has come from sitting inside the "Golden Triangle" of product, ML, and engineering. The closest of those partnerships is usually with whoever owns product.
With Product.
This is usually my closest partnership, whether it's with a CPO, a Head of Product, or a founder running product themselves. I treat the roadmap as a shared artifact, push for the question behind the question, and try to give product leaders sharper choices instead of more options. The best work happens when we've spent enough time inside the domain together that we're finishing each other's sentences about what to build.
With ML and Data Science.
I translate model behavior into product behavior. That means understanding what the model can and can't do, designing for its failure modes as carefully as its strengths, and making sure the experience holds when confidence drops.
With Engineering.
I prototype with real data, hand off with intent, and stay close through implementation. Most of the design decisions that matter happen after handoff. I'd rather be in the room than behind a Figma file.
With GTM.
Trustworthy AI sells differently than it ships. I work with sales, success, and marketing to make sure the story we tell customers matches the experience they get, and that what we learn from them gets back into the product.
On leading
Leadership is design at a different fidelity, whether I'm running a team or setting the bar as a principal. The same instincts apply. Structure context, name the real problem, build feedback loops where good work can compound. I've built design functions from zero, scaled them through hypergrowth, and shaped product direction without a team underneath me. The shape of the role matters less than the shape of the work.
What I'm drawn to
AI-native systems where intelligence has to feel trustworthy. Healthcare, fintech, anywhere a confident output carries real weight. The model is rarely the hard part anymore. The hard part is the domain, the workflow, and the trust. If that's the problem you're working on, let's talk.