Systems
The diagrams, lifecycles, and decision logic behind the products underneath the interface.
Most of the design work I do never reaches a screen. It lives in ownership maps, state machines, orchestration flows, and the decisions a finance or comp team has to make in sequence. This page collects a few of those underlying systems — abstracted enough to share, specific enough to mean something.
The path a single share takes from grant to exit.
Every interface in the ESOP product attaches to one of six lifecycle stages. Designing the product means knowing what state a holder is in — and what they're allowed to do next.
ESOP states: what can transition into what.
A grant is never just one thing. It is granted, partially vested, fully vested, exercisable, exercised, lapsed, cancelled, or accelerated. Most product bugs in this space come from missing or ambiguous transitions.
How an AI-assisted recommendation actually gets made.
The interesting part of an AI feature is rarely the model. It's the orchestration around it — what inputs are gathered, what constraints are enforced, what gets shown, and what the human is asked to confirm.
The decision tree behind a single comp adjustment.
The visible interface is usually a slider and a number. The system underneath has to ask several questions in order — about budget, equity dilution, tenure, and policy — and surface only the relevant branches to the operator.
An exercise workflow, viewed as three lanes that have to stay aligned.
A single exercise touches the holder, the platform, and the finance operator. Designing operational UX means thinking about all three lanes simultaneously — and where they hand off.
Note
These diagrams are not artefacts of process. They're the actual substrate I work from — the place where most of the trade-offs are negotiated before any screen is drawn.
If you want to talk through any of them in more detail, the case studies in Selected Work go deeper into the systems they came from.