Portfolio
Nike Design Systems · design engineer
Case study · internal platform evidence
Five years of design-system engineering at Nike across React + TypeScript components, accessibility, motion tokens and utilities, Figma-to-code workflows, documentation UX, migration/adoption support, and AI-assisted tooling.
Because the live systems sit behind Nike authentication, this page uses representative full-page captures and careful language: what I directly built or contributed to, what the platform demonstrates, and what each screenshot shows.
This section keeps the evidence honest: direct contribution, platform-level scope, and screenshot-backed proof are related, but they are not the same claim.
I built or contributed to
prefers-reduced-motion behavior.The platform demonstrates
The screenshots evidence
Defaults, scaffolding, and docs should steer teams toward consistent patterns without blocking reasonable exceptions.
Clear information architecture, predictable examples, and maintainable content reduce slack pings and rework.
Semantics, keyboard flows, focus, and motion preferences belong in the system—not as one-off fixes downstream.
Shared language around tokens, components, and motion keeps design tools and shipped interfaces aligned.
A system only works if teams can scan it quickly, trust the defaults, and understand when implementation context still matters.
Design-system work succeeds when it makes the right thing easier to ship: clear APIs, accessible defaults, tokenized decisions, trustworthy documentation, Figma/code alignment, and adoption support that reduces one-off interpretation across product teams.
Each thumbnail represents one internal documentation page. Scan the set for scope, then open any item for a full-page review with the evidence caption alongside it.
This screenshot shows the design-system platform as a connected source of truth for components, patterns, code, guidance, resources, and team adoption—not a one-off component library.
This screenshot shows a searchable component catalog with code, design, docs, and Figma status. That status model helps teams understand adoption readiness before they build.
This screenshot shows a searchable, filterable token reference with 220 results across color, radius, shadow, spacing, ratio, breakpoint, and motion tokens.
This screenshot shows motion as reusable infrastructure: duration, delay, and easing tokens with CSS custom-property examples for consistent, performant transitions.
This screenshot shows state-based animation utility classes for fade, slide, zoom, accordion, spin, and pulse, including guidance for when to use utilities versus built-in component motion.
This screenshot shows a complex overlay documented as composable parts: trigger, content, header, title, description, body, footer, close, controlled state, responsive width, focus behavior, and keyboard dismissal.
This screenshot shows a binary control documented through labels, state, keyboard support, focus indicators, disabled/hidden-label variants, and controlled usage patterns.
This screenshot shows accessibility as a shared responsibility model: system defaults for semantics, focus, ARIA, contrast, and reduced motion, plus consumer responsibility for labels, alt text, content hierarchy, and real flows.
This screenshot shows the earlier enterprise design-system documentation page that supported internal teams before the successor platform consolidated and expanded the model.
This screenshot shows the legacy component overview pattern: component discovery, usage pathways, and documentation structure for teams consuming the enterprise system.
This screenshot shows the earlier token documentation page, useful context for the migration from legacy design-system guidance toward richer token and motion references.