When I joined Northwind as a product designer, the dispatch app had 64 distinct greys in production, 11 button styles, and three date pickers that each formatted dates differently. Nobody had decided any of this. It accumulated: each team solved its problem on a deadline, and nobody was paid to notice the whole.
\nNorthwind had tried to fix it once. In 2021 a tiger team built a Figma library and a React package, launched them with a nice announcement, and moved on to other work. Eighteen months later, half the teams had copied the components into their own repos to fix bugs that nobody upstream would review. The system was finished, and that was exactly the problem.
\nA design system is the shared set of decisions that lets many teams build consistent interfaces without re-deciding everything. Those decisions live in layers:
\ncolor-action-bg instead of #1f5ae0.A component library is one layer. Teams that build only that layer get a box of parts and no instructions, and the parts go stale.
\nA project has a scope, a deadline and a launch party. A product has users, a backlog, a roadmap, and a team that stays after launch. Your design system is a product whose users are the product designers and engineers at your company. They have alternatives: build it themselves, copy a component, or pull in an open-source library. Every week they choose whether to use your system, and they choose it only when it saves them time.
\nThat framing changes daily decisions. You run user research with product teams. You keep a public backlog. You measure adoption the way a product team measures retention. And when someone asks when the system will be done, the answer is “never, like the app it serves”.
\n\nYou will rebuild Northwind UI with me. It serves two surfaces, the dispatch web app and the marketing site, and two brands: Northwind and Tidewater, a company Northwind acquired. Section by section you audit what exists, design the token architecture, build components with accessibility built in, set up versioned releases, and grow adoption until forty teams depend on it. Next, you start where every real system starts: counting what is already out there.
\n","toc":[{"id":"sec-1","text":"What a design system contains","level":2},{"id":"sec-2","text":"Product, not project","level":2},{"id":"sec-3","text":"How this course runs","level":2}],"takeaways":["A design system is tokens, components, patterns, documentation and the people and process that keep them current.","A project ends at launch; a product has users, a backlog and a team, which is what a design system needs to survive.","The customers of a design system are the product teams who build with it, so their time saved is the value you measure.","Most systems die from neglect after launch, not from bad components at launch."],"further":[{"title":"Design Systems 101 (Nielsen Norman Group)","url":"https://www.nngroup.com/articles/design-systems-101/"},{"title":"About the U.S. Web Design System","url":"https://designsystem.digital.gov/about/"}],"quiz":[{"q":"Northwind’s first design system shipped a polished Figma library and a React package in 2021, then the team was reassigned. By 2023, half the teams had forked the components. What was the root cause?
","options":[{"text":"The components were built in React instead of Web Components.","why":"Framework choice can limit reach, but it doesn’t explain why teams that used React also forked the package."},{"text":"It was run as a project with an end date, so nobody kept it current.","why":"Correct. Without an owning team, bugs went unfixed and requests went unanswered, so teams patched their own copies."},{"text":"The Figma library had too few components at launch.","why":"A small, well-maintained system outlives a large, abandoned one; scope wasn’t the failure here."},{"text":"Teams were not trained on how to install the package.","why":"Training helps adoption, but teams had installed it; they left because it stopped meeting their needs."}],"answer":1},{"q":"Which of these is a design system’s real customer?
","options":[{"text":"The end users of the products built with it.","why":"They benefit indirectly, but they never touch the system; the people who choose to use it or not are product teams."},{"text":"The design system team’s own designers.","why":"A system built for its makers’ taste tends to ignore the constraints product teams actually face."},{"text":"The product designers and engineers who build with it.","why":"Correct. They adopt it, ignore it, or fork it, so their needs drive the roadmap."}],"answer":2},{"q":"A director asks, “When will the design system be done?” What is the most accurate answer?
","options":[{"text":"When every screen in the product uses system components.","why":"Full coverage is a milestone, not an end; products keep changing, so the system must too."},{"text":"When the Figma library and code package reach version 1.0.","why":"1.0 marks a stable API, not the end of the work; maintenance and evolution start there."},{"text":"After the documentation site is published.","why":"Documentation is one part of the system and needs upkeep like everything else."},{"text":"Never, in the same way the main product is never done; it gets funded like a product.","why":"Correct. A system that stops evolving drifts away from the products it serves and gets abandoned."}],"answer":3}],"exercise":{"kind":"choice","multiple":true,"options":["forks","greys","one-app","requests","launch"],"correct":["forks","greys","requests"],"title":"Make the case for a product team","prompt":"Northwind’s VP of Product will fund a permanent design system team only if you show evidence that the company needs one. Which of these findings support funding the system as a product with a standing team? Select every one that applies.
\n","hints":["Look for evidence of ongoing, repeated cost, not a one-time problem.","Ask of each finding: would a one-quarter cleanup project fix it for good?"],"explanation":"Forked components, 64 greys and a steady stream of requests are all symptoms of a shared need with no owner. A one-off project would fix them once and then watch them return. A single app with a single team, or a launch announcement, is not evidence of a cross-team need.
\n","checkLabels":{},"optionText":{"forks":{"text":"Six teams have copied the 2021 Button into their own repos to fix bugs locally.","why":"Correct. Forks prove teams need shared components but have nobody upstream to fix them, which is an ownership problem."},"greys":{"text":"The audit found 64 distinct grey values across the dispatch app and marketing site.","why":"Correct. Drift at this scale comes from many teams making the same decision independently, again and again."},"one-app":{"text":"The dispatch app’s own team wants to rename its CSS classes.","why":"That’s one team’s internal refactor; it doesn’t need a shared system or a dedicated team."},"requests":{"text":"Every month, about five teams ask in Slack whether a date picker or data table already exists.","why":"Correct. Recurring demand from many teams is exactly the user base a product team serves."},"launch":{"text":"Leadership wants a design system announcement for the company all-hands next month.","why":"A launch date is a project milestone; it says nothing about the ongoing need that justifies a permanent team."}}},"words":510,"readMinutes":3}