Reseller Central Design System

Reseller Central had no unified design language. Teams across the platform were rebuilding the same patterns inconsistently. Decisions weren’t travelling between projects. Visual quality varied wildly between adjacent surfaces.

Amazon needed a complete design system. Interaction patterns, visual language, reusable components, and a delivery mechanism that would actually drive adoption instead of sitting in a static spec document nobody opens.

Component-first design. Define each pattern at the atomic level (tokens, then components, then composed templates) and let teams compose up from there. Standard design-systems methodology with one twist: I partnered with a front-end engineer and we shipped the system as a live online repository instead of a documentation page.

The repository included usage examples, component downloads, and ready-to-paste code snippets. Designers and engineers could browse a pattern, see it in context, and pull working code into their projects in the same flow.

The system covered the visual language, interaction patterns, component library, and the documentation tooling itself. Each component had a written rationale, a usage spec, accessibility notes, and code samples. Each one rendered live so you could see it before you used it.

The repository decision was the one that made the system stick. A static design-systems doc is a museum. A working repository is a workshop. Teams adopted faster because adoption took fewer steps.

Design systems are tooling, not documentation. The first design system I shipped that achieved meaningful adoption was the one where I treated the delivery mechanism with the same rigour as the components themselves. Documentation describes. Tooling propagates.

Role. Creative Director. Sole designer.

Team. One front-end engineer who built the repository tooling alongside the system.

Output. Component library, interaction pattern documentation, design tokens, live online repository with code-snippet generation.