I carry the problem
all the way through.

I find the breakpoints in a system, then stay with them until they become working products, services, or infrastructure.

At Yerbba, I co-founded a healthcare platform for breast cancer patients. The problem was straightforward to name and hard to close: patients were leaving appointments holding clinical information they couldn't use. So I did what the work required: business planning, user interviews, service design, frontend engineering, and enough backend work to make the data flow the way patients needed. Yerbba is operating now.

At Fixli, I'm doing it again. Homeowners and handymen often circle each other without a shared language for cost, trust, or project scope. I've designed the two-sided workflows, built key features, and shaped the database structure underneath them. Fixli is ready to launch.

The institutional work is a different kind of ownership. At ICPSR, I led the UX for ResearchDataGov, a platform that unified restricted federal data access across 16 government agencies. Nobody handed me a scope that covered all of them. I built one. The design system I inherited there was unmeasured and drifting. I reclaimed it, rebuilt its architecture across three phases, and put measurement on it so drift became visible.

The breadth is practical. Sometimes the work needs a business model. Sometimes it needs a token architecture. Sometimes it needs someone willing to open the database schema and ask whether the structure is part of the problem. I go where the problem needs me.

I start with structure before solutions. Before I sketch a screen, I want to understand the system: what states exist, what causes transitions between them, where the error cases are, and what a user believes is happening versus what is actually happening. This makes me slower to wireframe and faster to ship, because the decisions have already been made at the right level of abstraction.

I build. At both founding companies I've written production frontend code, touched backend APIs, and shaped database design when the structure underneath the product needed design attention. I'm fluent in Figma, HTML, CSS, React, and Python. I can read a schema, have a meaningful conversation about tradeoffs with an engineer, and ship the feature myself when that's what the moment requires. That range is not incidental. It's what lets me own a problem rather than hand it off.

I write. A designer who can write clear prose is a better collaborator than one who can't, because writing forces a point of view to become visible. Clear design usually starts with clear thinking.

Right now that practice includes an M.S. in Applied Data Science at the University of Michigan, because every complex service problem eventually hits a measurement problem underneath it. Design envisions the bridge. Data science tells me whether it's holding.