Designing the structures that let complex systems operate, scale, and behave.
A practice, ten years in.
I'm a designer with 10+ years of experience across both outsource and product environments - including B2B and B2C products, agency engagements, and in-house roles.
My work sits one layer beneath what users typically see. I'm less interested in the surface of a product than in the architecture underneath - the workflows, governance, rendering logic, and contextual rules that quietly decide how the product behaves.
I describe what I do as design architecture. It draws on systems thinking, product design, and information architecture, and produces structures rather than screens: the underlying conditions that allow a complex organization or AI-native system to operate, scale, and behave consistently.
In practice, this means designing things like identity architectures, permission and visibility systems, contextual rendering logic, and workflow structures - and translating between product, engineering, and organizational needs at enterprise scale.
Outside of client work, I'm currently researching what design systems become when their consumers are partly machine - and writing publicly about the practice.
I also teach as a Design Systems instructor at TELOS Academy, running cohort-based modules on design systems architecture, semantic tokens, and the operating shifts AI-native products demand from the practice. The teaching runs alongside full-time engagements - partly as service to the field, partly because nothing sharpens a practice like having to explain it.
Six positions I keep returning to.
Design the system, not the screen.
Most product problems aren't pixel problems. They're conditions, rules, and rendering decisions wearing a UI disguise.
Identity precedes interface.
Permissions and visibility are downstream of how the system decides who someone is, in which context, doing what.
Components are the floor.
Design systems beyond components: orchestration, governance, semantic contracts, behavioral rules.
Architecture is collaboration.
The most useful design artifacts are the ones engineering, product, and ops can argue against, together.
AI-native is a structural shift.
When the consumer of a system is partly a model, the rules of legibility, rendering, and governance quietly invert.
Mature, not minimal.
Restraint is a side-effect of clarity, not the goal. Strip the noise, keep the rigor.
A path, unfolding.
Languages, tools, and where I'm fluent.
Working on something complex? Let's talk.
Open for consulting, mentoring, speaking, and collaboration on AI-native and enterprise product systems.