Building Design Systems at Scale

Building a design system that serves multiple product teams is one of the most rewarding — and challenging — engineering projects you can take on. Here's what I learned leading the POS design system at Shopify.

Start with principles, not components

The temptation is to start building buttons and cards right away. Resist it. The most important work happens before you write a single line of component code.

We started by defining clear principles:

• Accessible by default — every component ships with proper ARIA attributes, focus management, and screen reader support
• Composable over configurable — prefer small, composable pieces over monolithic components with dozens of props
• Theme-aware — every component respects the active theme without requiring explicit theme props

The adoption challenge

Building components is the easy part. Getting teams to actually use them? That's where the real work begins.

We found that adoption comes down to three things:

1. Developer experience — if it's harder to use the design system than to build it yourself, nobody will use it
2. Documentation — interactive examples, copy-paste snippets, and clear guidelines
3. Migration tooling — codemods and lint rules that make adoption painless

Measuring success

We tracked adoption through several metrics:

• Component usage across product surfaces
• Time-to-ship for new features using system components vs. custom implementations
• Accessibility audit scores before and after system adoption
• Developer satisfaction surveys

What I'd do differently

If I were starting over, I'd invest more heavily in:

• Visual regression testing from day one
• A dedicated documentation site with search, versioning, and contribution guides
• Closer collaboration with the design team on component APIs before implementation

Design systems are never "done" — they're living products that require ongoing investment. But when done well, they're a force multiplier for every team that uses them.