Field note 03
Design Systems as Product Infrastructure
A design system is the difference between building a product and assembling one. With one in place, a new screen is mostly a matter of choosing parts that already exist, already match, and already work. In one controlled study, the same form took a team about four hours to build from scratch and about two with a design system in hand, and the design-system version came out more consistent. That gap compounds across a whole product.
So I think of a design system less as a style guide and more as infrastructure: components, states, tokens, and documentation the product is built on, not decoration applied afterward. The payoff is consistency, speed, and a shared language: the same button behaves the same way everywhere, and nobody re-litigates it each time. Which makes the real question not whether to have one, but how to get one. There are three honest options, and most teams end up blending them.
Adopt one off the shelf
The fastest start is to not build it yourself. Mature open libraries hand you an accessible, well-considered system on day one. shadcn/ui has become many teams' default precisely because it inverts the usual model: instead of installing a black-box package, you copy the components into your own repo and own the code, yours to restyle and extend. Underneath, headless primitives like Radix (and its newer successor Base UI, built by veterans of Radix, MUI, and Floating UI) give you behaviour and accessibility without imposing a look. If you want batteries included, Material UI, Mantine, Chakra, or Ant Design carry whole suites; Tailwind Plus sells polished sets if you already live in Tailwind.
What changed recently is distribution. shadcn turned a design system into something you can publish as a registry and install by command, and exposed it to AI agents over MCP, so a model pulls the right component from your own library instead of inventing one. The off-the-shelf system stops being a fixed dependency and becomes a starting point you keep editing.
The best system is often one you adopt and adapt, not one you write from scratch.
Generate one with AI
The second option barely existed a year or two ago: have a model build the system with you. Anthropic's Claude Design (a research preview as I write this) does something pointed here. During setup it reads your codebase and design files and assembles a design system from them, then reuses your real colours, type, and components on everything it makes. That's the inversion worth noticing: the AI adopts your system instead of imposing a generic one.
More broadly, tools like v0, Figma Make, and Lovable turn a prompt into working, componentised UI you can keep. Used carelessly they produce throwaway screens; pointed at your own tokens and components, they're a fast way to draft and pressure-test a system before you commit. I treat their output as a starting sketch, not a deliverable.
Export one from Figma
If the system already lives in Figma, the job is getting it out without it drifting from the code. Dev Mode turns designs into inspectable, copyable values; Code Connect maps Figma components to your real ones, so what a developer (or an AI) sees is your actual code, not a fresh guess. Figma variables map to design tokens, which you can export toward the emerging W3C token standard or manage with Tokens Studio, so a colour or spacing decision has one source of truth across design and code. The newer Dev Mode MCP server pipes that context straight into coding tools, and plugins like Anima or Locofy will emit components outright, with the usual caveat that generated code needs a careful human pass.
None of these paths are exclusive. Most real systems are a blend: an off-the-shelf base, tokens exported from Figma, AI filling the gaps. What matters is that the system exists and stays close to the code, because the moment design and build drift apart, you're back to translating intent by hand.
Treat the system as infrastructure (examined and shipped alongside the product, not maintained on the side), and everything downstream gets faster.
Back to field notes