A Product, Not a Project

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.

Northwind 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.

What a design system contains

A design system is the shared set of decisions that lets many teams build consistent interfaces without re-deciding everything. Those decisions live in layers:

• Tokens are named design decisions: color-action-bg instead of #1f5ae0.
• Components are the reusable building blocks, in design tools and in code, built from tokens.
• Patterns are recipes for combining components to solve recurring problems, such as how Northwind shows a failed shipment sync.
• Documentation tells people when to use each piece, and when not to.
• People and process keep all of the above true over time: who fixes bugs, who approves new components, how releases ship.

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.

Product, not project

A 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.

That 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”.

How this course runs

You 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.