Token-First Design
System Exploration.

Token-First Design
System Exploration

This project is a self-initiated case study based on Good Maven's existing website. Rather than presenting work under NDA or fabricating a fictional brand, I chose to analyze a real product and propose a scalable design system foundation as a demonstration of how I approach systems thinking.

The system was intentionally limited in scope to focus on structure, semantic clarity, and future extensibility — not visual exhaustiveness. Rather than building a complete component library, the goal was to establish the architectural decisions that make a design system actually scalable: naming conventions, token hierarchy, and the relationship between primitives and semantics.

This is not a critique of the current site — it's an exploration of how I would approach foundational systems work for a growing product.

Three things this
system had to do.

• 01
  Establish a scalable foundation — Use semantic tokens rather than hard-coded values, so the system can evolve without breaking what's already built.
• 02
  Enable future expansion — Structure primitives and semantics in a way that allows new colors, components, and modes to be added without refactoring existing work.
• 03
  Align design and engineering — Create token definitions that translate directly to code, reducing ambiguity and speeding up handoff.

Spacing & Radius

Spacing follows an 8pt-based scale to ensure rhythm and predictability across layouts. Border radius tokens are intentionally constrained — not every component needs five radius options.

Restraint here isn't a limitation. It's a design decision that reduces cognitive load for both designers and engineers, and keeps the UI feeling cohesive as it grows.

Typography

The type system balances editorial clarity with UI readability. A deliberately limited scale reduces inconsistency across surfaces while remaining responsive-friendly.

Type tokens reference size, weight, and line-height as a single unit — preventing the mix-and-match styling that slowly erodes visual cohesion over time.

Color System

Primitive colors are defined on numeric ramps (50–900) to allow future expansion without breaking existing references. Semantic tokens abstract intent — text, background, border, interactive states — from raw values, enabling safe evolution of the palette over time.

This separation means a brand refresh, dark mode, or new product vertical wouldn't require touching individual components. You change the semantic mapping once; everything downstream updates.

Buttons —
Why buttons first?

The system currently includes primary, secondary, and inverse button variants — each with default, hover, and disabled states.

Buttons were selected as the initial component due to their frequency, state complexity, and cross-platform relevance. They touch every layer of the system — color, typography, spacing, radius, and interaction states — making them an ideal stress test for the token architecture.

If the tokens work for buttons, they work for everything.

Additional components would layer on top of this same foundation as product needs evolve. The system doesn't need 40 components to prove it works; it needs one component that proves the structure works.

Scalability isn't achieved
by building more.

Scalability isn't achieved by building more — it's achieved by structuring well.

This system can grow in two directions:

Tokens follow W3C Design Tokens conventions, allowing direct engineering consumption via tools like Style Dictionary or Tokens Studio. This isn't a Figma-only system — it's built for real handoff, real codebases, and real collaboration between design and engineering.

The goal isn't a pretty Figma file. It's a shared language that both disciplines can trust.

How a System
Like This Evolves

With a foundation in place, natural next steps would typically include:

• 01
  Expanding component coverage (inputs, cards, navigation)
• 02
  Adding interaction tokens (motion, easing, duration)
• 03
  Documenting usage guidelines for edge cases

The point of this exploration wasn't to build a complete system — it was to demonstrate how I think through foundational decisions, prioritize scope, and structure work that others can build on.

If you'd like to discuss this work or how I approach systems thinking, I'd love to connect.