About

I am a product designer and engineer in Austin, Texas, trained in HCI and strategy. I work on the kind of problem where nobody has decided yet what the thing is — my job is to make that decision legible enough that a team can build against it, build the system that keeps it from drifting, and then ship it.

Most of my work sits in two places that look unrelated and are not. At Intapp I spent three years designing risk and compliance workflows for regulated professional-services firms: dense, consequential software where a bad interface has legal weight and the users are experts who will tell you exactly what you got wrong. Then I built Saddle Pass from nothing — field research with barns and trainers, a design system three codebases consume, an AI assistant, and a marketplace with a trust problem at its centre.

Enterprise taught me to design for people who know more about their domain than I ever will. Building 0→1 taught me to make decisions before the evidence is comfortable. The combination is most of what I am good at.

A systems thinker, specifically

That phrase gets used loosely, so here is what I mean by it. The screens are rarely where a product fails. It fails because one word means two different things to three teams, or because the design system has no enforcement and drifts within a sprint, or because four groups are designing in parallel against a brief that never settled the decisions that cross their boundaries.

Those are the problems I go after. At Intapp, a card redesign turned out to be a taxonomy problem and the fix was renaming a component across a shipped design system. On Saddle Pass, keeping one system honest across three codebases meant putting the tokens in the repository with tests that fail the build. That is design ops, and it is most of what separates a system that holds from a component library nobody checks.

How I work

I do not prototype in code so much as work in it. I build with AI in the terminal — Claude Code and Codex — which means the distance between a design decision and a running implementation is hours, not a sprint. I ship to real codebases: React and React Native front ends, enough backend to be useful rather than dangerous, and the integration work in between. The specs I hand off are ones I have already built against.

That changes what design is for. When the cost of trying something falls to almost nothing, the bottleneck stops being production and becomes judgment — knowing which thing is worth building, and being honest about what the evidence actually supports.

I build design systems with enforcement, not just inventory. A component library nobody checks drifts within a sprint. On Saddle Pass the tokens live in the repository with tests that fail the build when a codebase diverges — because a design decision that cannot be enforced is a suggestion.

AI-first, and agents specifically

The interesting design work in AI products is not the chat box. It is the scoping, the error states, the moment the system is wrong, and what the interface does to keep a person calibrated about how much to trust it.

Most of what I have learned about that came from building agents rather than drawing them. I design and run a set of them in production — scheduled and event-driven, wired into real tools and APIs, each one with an approval gate where a human has to say yes before anything leaves the building. That constraint is the whole design problem: an agent that needs permission for everything is useless, and one that needs permission for nothing is dangerous. Deciding where that line sits, per action, is the work.

The studio

I run Carrington Design Co., a design studio that takes on web product, event design, and interior design contracts. Recent work includes a $20K portal and landing-page rebuild for EquiStaff — UX audit through an AI chatbot assistant and a React front end — alongside event and interior design engagements. Interiors run as Stagecoach Design Co., a studio of Carrington Design Co.

Running the studio means I sell, scope, and deliver. That has made me a sharper designer in a specific way: when you write the statement of work yourself, you stop treating scope as something that happens to you.

Leading teams

I was President of Ladies That UX Austin, running a chapter with 50+ attendees per event, and I led pro bono design programs through it — including a three-month redesign for the Austin startup Allhers across four parallel teams and eight-plus volunteer designers. Leading volunteers is leadership without any of the usual levers: nobody has to show up. What is left is whether the brief is clear, the scope is sized to the person, and the critique is worth someone's Saturday.

I am currently open to senior and staff product design roles, remote or relocating. The short version of what I am looking for: a team that takes craft seriously and has a problem hard enough to be worth it.