What This Work Is

My work on design systems goes beyond component libraries or visual consistency.

I build design systems as operational infrastructure — systems that help teams make faster, better decisions under real pressure.

That means owning the system across:

• Design principles and visual language
• Tokens, variables, and constraints
• Frontend implementation
• Tooling that removes friction
• Direction, governance, and evolution

The Problem

Most design systems fail quietly.

They look good in documentation but break down in reality:

• Design and code drift apart
• Tokens exist but aren’t trusted
• Engineers reimplement decisions
• Designers bypass the system to move faster

The result isn’t inconsistency — it’s loss of confidence.

My Approach

I treat design systems as products, not artifacts.

The goal is simple:

• Reduce decisions, not options
• Make the right thing the easy thing
• Align design and code around shared constraints

Every system decision is evaluated on whether it improves speed, clarity, and trust across the team.

Design Foundation

On the design side, I establish clear foundations before building components.

• Token-driven colour, spacing, and typography systems
• Themeable variables for brand and context variation
• Explicit constraints to avoid subjective styling decisions
• Clear rules for when — and when not — to break the system

The system exists to guide decisions, not police them.

Engineering Implementation

Design systems only work when they are real in code.

I’ve implemented design systems directly in frontend stacks, ensuring:

• Tokens map cleanly to code
• Design intent survives implementation
• The system is performant and predictable
• Engineers don’t need to reinterpret design decisions

This often includes Tailwind configuration, theme logic, and component architecture aligned directly to the design system model.

Tooling to Remove Friction

When design systems fail, it’s rarely because the system itself is wrong. It’s because the workflows around it are slow, manual, or fragile.

Instead of adding more documentation or stricter rules, I build tooling that makes the system easier to use than to bypass.

Design Tokens → Code, at Scale

A major source of drift is the gap between design tokens in Figma and their implementation in code — especially once themes and modes enter the picture.

In our case, this was compounded by a practical constraint: we couldn’t justify a Figma Enterprise plan, which meant there was no native API available for exporting tokens.

Rather than accept manual syncing as a cost of scale, I built a Figma variables to Tailwind exporter to close that gap.

• Reads tokens directly from Figma variables
• Supports multiple modes (e.g. light, dark, brand)
• Exports modes as theme-aware Tailwind configurations
• Preserves naming, hierarchy, and intent
• Removes the need for manual token translation

This allowed a single token system to drive multiple themes without duplication — and kept design and engineering aligned despite platform limitations.

Speed at the Point of Use

Even the best system slows down if accessing it is cumbersome — especially inside design tools.

To remove that friction, I built a Figma plugin paired with keyboard and mouse-driven shortcuts via BetterTouchTool.

• Instant access to common design system variables
• Keyboard and mouse shortcuts for rapid application
• No panel hunting or context switching
• Encouraged correct usage through speed, not enforcement

The fastest interaction became the most correct one.

Tooling as Governance

These tools weren’t built to be clever or impressive.

They were built to encode decisions — so teams didn’t have to remember them.

• Reduced review and correction cycles
• Lower cognitive load for designers and engineers
• Consistent outcomes by default

Tooling became a form of governance: quiet, invisible, and effective.

Direction & Governance

A system without direction eventually fragments.

My role includes:

• Setting and communicating standards
• Reviewing changes for systemic impact
• Helping teams understand tradeoffs
• Evolving the system without breaking trust

The goal isn’t control. It’s shared understanding.

Impact

Well-run design systems change how teams work.

• Faster delivery with fewer regressions
• Higher consistency without enforcement
• Reduced design–engineering friction
• More confident decision-making

The biggest signal of success is when the system fades into the background — and the work gets better.

What Made This Good

• Systems built across design and code, not one or the other
• Tooling used to remove friction instead of adding process
• Clear ownership paired with shared responsibility
• Focus on outcomes, not artifacts

I don’t build design systems to look impressive.

I build them so teams can move faster — without losing quality.