Get weekly design system tips and tricks, directly to your inbox.
Look up “design systems foundations” and you’ll usually find these usual suspects: color, typography, spacing, motion, and a few other related areas. In other words, properties that translate well to design tokens.
I’ve previously registered my disdain for the idea that design tokens are design system foundations. In short:
Foundations are load-bearing. I’ve seen and made design systems without design tokens. It’s fine.
Foundations are preliminary. Design tokens can be added after the fact. They’re software. Software can always be added to and edited at any level and at any time. (It’s called refactoring and is a part of any healthy software development process.)
Foundations are permanent. Colors, typography, and spacing change over time as the needs of products and features evolve. That’s a good thing. Design systems prove their value most at the points of change. Trying to prevent that creates an unhelpful and unnecessary constraint.
Not one to throw the baby out with the bathwater, I started to think about what else might be a truer foundation of a design system. Is there anything in a design system ecosystem and culture that truly is—and needs to be—load-bearing, preliminary, and permanent?
A design system’s true foundation is the community upon which the design system depends.
At every organization, there is a group of people without which the design system falls apart. It often includes:
At least one designer and one engineer, the smallest cross-disciplinary team of practitioners who make or will make the tools and assets of the design system
A stakeholder sponsor, a director or VP who will advocate for the design system. This person usually has power and/or influence within the organization to create and clear paths for design system work to succeed.
A critical mass of willing parties (feature teams, etc) who will and can adopt some temporary inefficiency and redundancy as an investment in the success of an organization-wide design system
Without any one of these parts, design systems often fail. If the designer or engineer leading the charge gets reassigned or leaves the company, design system efforts usually wane. If the primary stakeholder sponsor loses trust or gets laid off, design system progress generally stalls. If no willing parties surface, design system implementation and adoption never gets off the ground.
I’m fond of Donella Meadows’ definition of systems in her book Thinking in Systems:
A system is a set of things—people, cells, molecules, or whatever—interconnected in such a way that they produce their own pattern of behavior over time.
Systems are connected; that’s what makes it a system. The first system to create when doing design system work is connecting the people to become a community. That’s the foundation that underlies everything else, the bedrock you can build upon. The stronger it is, the more you can build. The shakier it is, the more brittle the design system.
It’s trite but true: the real foundation is the friends we made along the way.
