Two days, built for engineers.

Design Systems That Explain Themselves

Szymon Chudy

You don't know a design system until you have to change it. The components are the easy part. What gets you is everything they assume you already know: the API that looks consistent until you extend it, the token whose name only makes sense if someone explains its history. Hawkins, Netflix's design system, runs across thousands of applications and is used by 2k+ engineers. A major new version ships this year. At that scale, preparing a release is mostly archaeology. Before you change anything, you have to uncover what the system does, why it does it, and which assumptions have accumulated over a decade. AI raises the price of that gap. An agent reading your system can't walk over and ask a teammate. Whatever the code and docs leave unsaid, it has to guess. And more documentation alone won't save you. Consistent APIs, token names that carry their meaning, accessibility built into the primitives - that's what lets a system explain itself. I'll use the Hawkins redesign throughout: evolving a ten-year-old system without breaking the applications standing on it. You'll leave knowing how to find where your own system depends on knowledge nobody wrote down, and how to turn that knowledge into constraints, conventions, components, tokens, and documentation that both humans and agents can understand.