Design Systems

Systems that scale
with the product.

Every design system I've built started inside a real product, not a Figma sandbox. They exist because a team needed to ship faster, stay consistent across platforms, and hand off without friction. Tokens, components, and documentation are only useful if they solve real problems at scale.

01

Build with, not before

Design systems are most useful when built alongside real products, not as standalone upfront deliverables. Components earn their place by solving actual problems.

02

Tokens are the foundation

Color, typography, spacing, and motion are defined as named tokens, not hardcoded values. This makes theming, dark mode, and cross-platform consistency tractable.

03

Accessibility is structural

Accessible patterns are built into components from the start: focus states, contrast ratios, screen reader semantics. Never retrofitted after the fact.

04

Documentation enables scale

A component without clear usage guidance, do/don't examples, and handoff notes will be misused. Documentation is part of the component, not an afterthought.

Why It Matters

Design systems aren't just component libraries. They change how teams work.

Brand consistency

Every component reflects brand identity across all touchpoints, without relying on individual judgment calls.

Faster development

Pre-built components eliminate repetitive work and let teams focus on solving unique problems.

Easier maintenance

Update once, deploy everywhere. Tokenized values and shared components make changes systematic, not scattered.

Better collaboration

A shared design language streamlines designer-developer handoffs and reduces ambiguity.

Scalability

Systems that grow with the product and team. New features build on existing patterns instead of starting from scratch.

Quality assurance

Built-in accessibility, tested patterns, and consistent behavior reduce bugs before they ship.

Time efficiency

A component library lets teams prototype faster and spend time on the hard problems, not the solved ones.

Systematic approach

Transform ad-hoc decisions into deliberate, repeatable patterns that compound over time.

Selected Systems

  • Fittra Wellness · 2024

    Fittra Design System

    2 Platforms

    Zero-to-one component library for a live iOS & Android app. Built alongside the product in Figma with tokenized color, typography, and spacing. Handed off to engineering via Storybook.

    • Figma
    • Tokens
    • Dark Mode
    • Storybook
    • Accessibility
    • iOS
    • Android

  • Central Ohio Counseling Association · 2024

    COCA Component Library

    1 Platform

    Accessible, warm component library for a responsive healthcare web directory. WCAG 2.1 AA throughout. Emphasis on approachable, non-clinical visual language.

    • Figma
    • WCAG 2.1 AA
    • Responsive
    • Healthcare
    • Responsive Web

  • Avance (Concept) · 2024

    Avance System

    3 Platforms

    Exploratory design system for an adaptive fitness platform. Focused on data visualization components, adaptive state patterns, and AI disclosure patterns.

    • Figma
    • Tokens
    • Data Viz
    • Dark Mode
    • AI Patterns
    • iOS
    • Android
    • Web

Token Architecture

How tokens are structured across my systems

Tier 1 · Primitive

Raw values: every color, size, and spacing value available in the system. These are never used directly in components.

  • color.blue.500 = #3B8BD4
  • color.neutral.900 = #191917
  • space.4 = 16px
  • font.size.base = 16px

Tier 2 · Semantic

Named by purpose, not value. Components use these rather than primitives. This is what makes theming and dark mode work.

  • color.text.primary → neutral.900
  • color.interactive.default → blue.500
  • space.component.gap → space.4
  • font.body.size → font.size.base

Tier 3 · Component

Scoped to specific components. Built from semantic tokens, not primitives. Makes component-level theming surgical.

  • button.bg.default → interactive.default
  • card.border → border.subtle
  • input.focus.ring → interactive.default
  • badge.text → text.secondary

Want to talk systems?

I'm always interested in how teams are approaching design system maturity, from token architecture to documentation strategy to the tricky question of governance. If you're working through any of that, I'd love to compare notes.

Get in Touch