I build for moments when life has gotten more complex than existing tools were designed for.
Product and research across applied AI, 0→1 systems, and high-stakes workflows. I run the same loop at every stage — find the real constraint, test it fast, and change direction when the evidence says to.
Selected work
01 RefWorks, Clarivate
Designing for verifiable research integrity
Librarians and systematic review specialists wouldn't migrate to a new platform — not because they resisted change, but because their professional credibility depended on evidence they could personally verify. I found that constraint, reframed the product around it, and stayed close through four years of voluntary migration.
Read the case study →
02 AI Diagnostic, applied AI
Using AI prototypes to find when automation is the wrong answer
Two prototypes worked exactly as designed. Testing them inside real workflows revealed a different problem: one interrupted a photographer's connection with her subject at the worst possible moment, and the other surfaced a missing shared standard that was quietly stalling every PRD review. The prototypes weren't the answer. They were the diagnostic.
Read the case study →
03 Sensory Sprout, 0→1 AI
Predicting whether a meal will work before it reaches the table
For families navigating sensory-sensitive eating, dinner isn't a recipe problem — it's a reliability problem. Three interviews killed the original hypothesis. Two product reframes followed. What families needed wasn't discovery. It was a system that protected the small set of foods that already worked.
Read the case study →
How I think
Principles that have held up in high-stakes, ambiguous work.
Trust is earned, not installed
Trust belongs to the user. My job is to design the conditions that let it form — transparency, verification, and safety boundaries that make each interaction evidence, not a claim. The families and professionals I've worked with weren't skeptical of the technology. They were accountable for the outcomes. That's a different design problem.
Diagnose the real problem
Before designing anything, identify what is actually blocking progress. The visible problem is rarely the real one. In AI work, the request is often “build this feature” when the real answer is “pause and establish shared criteria first.”
AI needs judgment, not just enthusiasm
Separate layers by failure cost, and match each capability to the right technology. A missed allergen is not the same as a suboptimal suggestion. Know which failures are recoverable and which are not.
Restraint is a strategy
Sometimes the most valuable deliverable is the recommendation to stop. What we choose not to build is a first-class decision — especially in AI, where scaling the wrong thing compounds faster than fixing it. Some of the most important decisions I've made were about what not to automate, and why.
About
Strategy, not just delivery.
I work best where product direction is still forming, when teams need clarity, not just execution. I help define the problem, surface constraints, and decide what actually matters before building.
The domain I keep returning to is people in the middle of something hard — caregivers, families navigating a child's complex needs, professionals accountable for decisions with real consequences. These aren't niche users. They're people at a moment when the stakes are high enough that a bad product experience isn't just friction. It's a failure of care.
My background in UX keeps me close to users and interaction quality. My product work pushed me upstream, shaping the problem before committing to solutions.
I’ve designed AI systems from research through evaluation, shipped enterprise tools to thousands of users, and earned the confidence of experts who had every reason to resist.
The throughline across my work: AI products hold up when someone does the hard thinking about where human judgment still needs to live.
Contact