Design Systems That Scale
Build a design system that 40 teams actually use: tokens, components, releases and adoption.
- 4.9 (612 ratings)
- 4,900 learners
- Advanced
- 6h 5m total
- Updated August 2026
What you’ll learn
- Audit an interface and decide what the system should own
- Structure tokens in primitive, semantic and component tiers
- Theme light, dark, density and two brands without forking code
- Design component APIs that compose instead of growing props
- Ship releases with semver, changelogs and painless deprecations
- Run contribution, governance and adoption metrics at scale
Who it’s for
Most design systems fail quietly: a Figma library nobody trusts, a component package three versions behind, and forty shades of grey in production. This course teaches the parts that make a system survive contact with real teams: token architecture, component APIs, accessibility built into every state, versioned releases, and a governance model people accept.
You work on one system the whole way through: Northwind UI, which serves a dispatch web app and a marketing site for two brands. Your guide is Sofia Reyes, a principal product designer who has run a system used by forty teams. You write real CSS, real token files and real release plans, and you learn which decisions are expensive to undo.
- Who it’s for
- Designers and front-end developers who already ship UI and now need to build or run a shared design system.
- Before you start
- Comfortable with HTML and CSS (custom properties, selectors), basic JavaScript, and Figma components.
Hands-on practice
- Guided exercises: spot the bug, fill the command, order the steps.
- Edit HTML, CSS and JavaScript and see the result instantly.
Course content
5 sections · 19 lessons · 6h 5m total
- A Product, Not a Project12 min
- The Interface Inventory20 min
- Principles and Team Models18 min
- Section checkpoint5 questions
- Three Tiers: Primitive, Semantic, Component20 min
- Naming Tokens So They Survive18 min
- Themes and Modes22 min
- The DTCG Token Format20 min
- Token Pipelines: From JSON to Every Platform20 min
- Section checkpoint5 questions
- Component APIs: Props, Variants and Slots22 min
- Composition Over Configuration20 min
- States and Accessibility, Built In22 min
- Documentation People Actually Read18 min
- Section checkpoint5 questions
- Figma Variables and Libraries, in Sync with Code20 min
- Semver and Changelogs for a Design System20 min
- Deprecation Paths18 min
- Storybook, Visual Regression and Releases22 min
- Section checkpoint5 questions
- Contribution and Governance18 min
- Multi-Brand Theming at Scale17 min
- Measuring Adoption and Saying No18 min
- Section checkpoint5 questions
Your instructor
Sofia Reyes
Principal Product Designer · Northwind
- 4.8 instructor rating
- 25,900 learners
- 3 courses
Sofia trained as a graphic designer, taught herself CSS to stop arguing with engineers about pixels, and has worked on both sides of the handoff ever since. At Northwind she leads the design system behind 11 products, from the Figma library to the CSS tokens that ship in code.
What learners say
4.9
612 ratings
Grace Okonkwo
6 months ago
Naming tokens in three tiers, primitive to semantic to component, ended a two-month argument on my team. We shipped the new token set the following week.
Khaled Mansour
3 months ago
Most design-system content stops at the Figma library. This one covers versioning, deprecations and getting other teams to adopt the system, which is where systems actually fail.
Ingrid Solberg
2 weeks ago
The critiques of real component APIs are the best part. It assumes you already maintain a small library, though; as a solo designer I skimmed the governance material.