Systems
archive
Four systems. Four contexts. One approach.
Systems are a
leadership problem
disguised as a
design problem.
Every design system I've built had to earn adoption inside real organizational constraints: uneven process, changing priorities, limited dedicated support, and teams that still needed to ship.
If a system isn't used, it doesn't exist. That's the metric that matters. Everything else - token architecture, component API, documentation quality - is in service of that outcome.
Proof in practice.
Full case study →Web hosting platform backend and marketing site. Four years, two major versions. OKLCH color architecture, full dark mode, token system built for a data-heavy application. Solo execution from V1 skeleton to full V2 marketing unification.
SaaS product.
Tight scope.
Fast adoption.
Design system for a SaaS product organization. Smaller team, faster iteration cycle, different constraints than Pantheon. The challenge here was building something rigorous enough to scale without overengineering for a team that needed to move quickly.
Fintech.
High stakes.
Dense data.
Design system work for a financial services platform. Fintech has its own set of constraints — regulatory considerations, data density requirements, accessibility standards, and user bases that require precision over personality. Built to hold up under those pressures.
Systems that
get used.
Fit
Every system was built for the specific environment it lived in — not adapted from a template. Data-heavy apps need different color logic than marketing sites. That distinction is the difference between adoption and abandonment.
Scope
Knowing what to include is as important as knowing how to build it. An overengineered system that nobody uses is a failure. The right scope for the team and the product is the design decision.
Token architecture
Semantic tokens over static values. Color decisions that survive context changes. Typography scales that work across product and marketing. The infrastructure that makes the system adaptable.
Execution
Across these systems, constraints forced practicality: limited dedicated DS staffing, lean process, and close collaboration with engineers. The result is a designer who knows how to define the system and get it shipped.