readme
how I think, work, and build
I created this document to help define what I do.
I started in graphic design and branding. Moved into web design. Eventually product design. Somewhere along the way I became deeply interested in systems, workflows, operational complexity, and the strange sociology of software teams.
Today, I primarily design enterprise SaaS systems.
But even that feels incomplete.
A lot of my work lives at the intersection of:
product design
frontend implementation
design systems
organizational alignment
operational UX
and infrastructure thinking
This document exists partly because interviews rarely leave enough time to explain how those pieces connect.
So this is the longer version.
What I Actually Do
I help teams create clarity inside complex systems.
Sometimes that means interface design.
Sometimes that means design systems.
Sometimes it means identifying fragmentation across workflows, products, or teams before it compounds into operational debt.
I’m especially interested in products where:
trust matters
workflows are consequential
complexity is unavoidable
users operate under pressure
and consistency becomes infrastructure
Most of my recent work has involved mature enterprise SaaS platforms where the challenge is not inventing features, but making large systems more coherent over time.
I Don’t Think Simplicity Is Always The Goal
This is probably one of the more important things to understand about how I approach design.
I think a lot of software teams accidentally confuse:
reducing visible complexity
with:reducing actual cognitive burden
Those are not always the same thing.
In enterprise systems especially, users often do not need products to feel “simple.” They need products to feel:
understandable
survivable
trustworthy
Understandable means users can read the state of the system and anticipate consequences.
Survivable means mistakes are recoverable and workflows do not feel fragile.
Trustworthy means the product behaves predictably, explains itself clearly, and avoids hidden side effects.
Sometimes a dense but legible interface creates more confidence than an aggressively simplified one that obscures important context.
Why I Care About Design Systems
I’m less interested in design systems as visual governance and more interested in them as operational infrastructure.
To me, a good design system:
reduces fragmentation
creates shared interface language
improves product coherence
accelerates implementation
and lowers cognitive load for both users and teams
Features should not have to reinvent interaction patterns every sprint.
The best systems create consistency structurally, not performatively.
A button is rarely just a button. It’s accumulated product decisions, accessibility considerations, implementation standards, and behavioral expectations compressed into reusable infrastructure.
My Relationship With Engineering
I enjoy working closely with engineering.
Not performatively.
Not “handoff culture.”
Actually collaboratively.
Over time I found myself increasingly drawn toward implementation-aware design workflows:
Storybook
component systems
React-based prototyping
design tokens
frontend architecture discussions
CI-connected UI workflows
I’m not trying to become a full-time engineer. But I do think understanding implementation constraints fundamentally improves product design judgment.
Especially in scaling SaaS organizations.
What Kind of Problems Energize Me
The problems I enjoy most usually involve:
operational complexity
fragmented systems
scaling organizations
workflow-heavy products
infrastructure-level UX
product coherence
design maturity
AI and systems interaction
high-trust environments
I’m especially interested in products where UX is not decoration layered onto functionality, but part of the operational integrity of the system itself.
Things People Sometimes Misunderstand About Me
Because my background spans multiple disciplines, people sometimes initially assume I’m either:
too visual
too systems-oriented
too strategic
or too implementation-focused
The reality is probably that I move fluidly between those layers depending on what the organization actually needs.
I like strategy.
But I also like execution.
I like systems thinking.
But I care deeply about craft.
I enjoy leadership.
But I still want proximity to the work.
A Few Things I Believe
Complexity should be organized, not denied.
Operational clarity is a feature.
Consistency is more scalable than customization.
Design systems are infrastructure.
Enterprise users deserve good UX just as much as consumers do.
Products should communicate consequences clearly.
Trust is built behaviorally, not cosmetically.
And increasingly, I think the most important software challenge is helping humans build confidence inside systems too large for any one person to fully understand.
Why This Exists
Partly because modern careers become difficult to compress into titles.
Partly because interviews flatten nuance.
And partly because I think more people should write down how they actually think about their work instead of only presenting polished outputs from it.
Software products are shaped by the mental models of the people building them.
This is a small map of mine.
