The invisible work of design systems

Design systems are sold as a solution. You'll hear the pitch: one source of truth, consistent components, faster delivery. And those things are true. But what gets left out of the pitch is everything else , the invisible work that makes or breaks a design system at scale.

The documentation nobody reads

Every design system has documentation. Most of it goes unread. The components get used, the tokens get referenced, but the why , the decision rationale, the usage context, the edge cases , that stays locked in the heads of whoever built it.

I've seen this play out at both SAP and Motive. Teams adopt the system, then deviate from it, not because they're being difficult, but because the system didn't communicate its intent. The component exists; the context doesn't.

The human system beneath the design system

Here's what I've learned: a design system isn't a library. It's a set of agreements. And agreements require relationships, communication, and trust.

The most durable systems I've worked on had one thing in common: someone was held responsible for them. Not just technically , they were the advocates, the people who understood both the product needs and the system's constraints, and could translate between them.

What "scalable" actually means

Scalable doesn't mean works for 500 components. It means works when the team building it changes. It means the decisions are so well-documented that a new designer can understand not just what to do, but why.

That's a different kind of work. It's slower, less visible, and rarely celebrated. But it's the difference between a design system that lasts and one that gets rebuilt every 18 months.

The question I always ask first

Before any decision about tokens, component APIs, or tooling, I ask: who owns the relationship with the teams that will use this?

If the answer is "the system itself," it will fail. Systems need people. Not just to build them, but to tend to them , to answer the questions, to handle the exceptions, to explain the thinking behind the rule.

That's the invisible work. That's what makes a design system work at scale.