Skip to content

Portfolio

Monnie Hammill

Nike Design Systems · design engineer

Case study

Five years on Nike’s design systems

I've worked on Nike’s internal design systems for five years—shipping React + TypeScript components, documentation product teams rely on, motion tokens, Figma-to-code workflows, and the adoption work that keeps teams from reinventing the same UI.

The live platform is behind Nike login. This case study uses representative full-page captures, and I’ve been explicit about what I built versus what the docs illustrate.

  • React + TypeScript
  • Design systems
  • Accessibility
  • Motion tokens
  • Documentation UX
Role Senior Design System Engineer
Core stack React, TypeScript, CSS, tokens, Vitest
System areas Components, docs, Figma, motion, a11y
Highlights Status model, 220-token reference, motion docs

My role

What I shipped, what the platform is for, and what a screenshot can prove are three different things—I’ve kept them separate on purpose.

I built or contributed to

  • React + TypeScript primitives and interaction patterns used across product surfaces.
  • Documentation for tokens, motion, components, accessibility, and real usage—not just API lists.
  • Motion tokens and utility classes, including prefers-reduced-motion behavior.
  • Migration and adoption support across the legacy program and the successor platform.
  • Internal tooling that surfaced design system context for engineers, including our team’s first MCP server for AI-assisted workflows.

The platform is built to

  • Give Nike teams one documentation site—not a scatter of Storybook instances.
  • Show whether a component is ready in code, design, docs, and Figma before someone builds on it.
  • Make tokens searchable (220+ in the reference) instead of tribal knowledge in Slack.
  • Encode accessible defaults: semantics, focus, keyboard behavior, and reduced-motion guidance.

What the screenshots show

  • Status tables, live examples, variant guidance, and anatomy for components like Drawer and Banner.
  • Token and motion reference pages—with durations, easing, CSS examples, and utility-class APIs.
  • Component docs that spell out composition, ARIA, focus, and what consuming teams still own in their flows.
  • Accessibility foundations that set system defaults without pretending context doesn’t matter in production.

How I work

Four moves I kept coming back to over five years on the same problem.

  1. Step 1

    Align

    Align with design on tokens and component contracts before implementation starts—shared language saves rework later.

  2. Step 2

    Build

    React + TypeScript primitives, Vitest coverage, accessible defaults, and motion-aware behavior.

  3. Step 3

    Document

    Write docs with clear IA, live examples, and content that doesn’t rot the sprint after it ships.

  4. Step 4

    Adopt

    Help teams migrate, read status honestly, and reach for system context in their tools—so they ship with the system, not around it.

How I approach design systems

  1. Make the right path easy

    Defaults, scaffolding, and docs should steer teams toward consistent patterns without blocking reasonable exceptions.

  2. Treat documentation as product

    Clear information architecture, predictable examples, and maintainable content reduce slack pings and rework.

  3. Build accessible defaults

    Semantics, keyboard flows, focus, and motion preferences belong in the system—not as one-off fixes downstream.

  4. Close the gap between design intent and production UI

    Shared language around tokens, components, and motion keeps design tools and shipped interfaces aligned.

  5. Optimize for adoption, not admiration

    A system only works if teams can scan it quickly, trust the defaults, and understand when implementation context still matters.

Why it matters

Design system work pays off when the right thing is also the easy thing: clear APIs, accessible defaults, tokens teams actually use, docs they trust, design and code that stay aligned, and enough adoption support that product teams aren’t guessing in isolation.

Evidence preview

Image preview