There’s no better name for design systems
Design systems have grown exponentially since the mid-2000s. Initially, we built style guides and pattern libraries to mimic print-based brand guidelines, reshaping them for the web. Nowadays, a design system is often an umbrella term for a set of diverse resources: design tokens, component libraries, UI patterns, accessibility guidelines, governance processes, structured metadata for LLM consumption, and associated tooling. No design system is the same; their shapes vary depending on company size, design function maturity, or how well the initiative is funded. What’s in a design system today is vastly different from a decade ago.
For years the community defined a design system by the sum of its parts. As Nathan Curtis pointed out, that variability of composition inevitably kept causing confusion. How can you effectively discuss something that’s constantly shapeshifting? What I found over the years is that what’s inside a design system is irrelevant in most conversations. Specific resources are important to design system consumers and contributors—they are the people who have to understand the moving parts and how to work with them.
Specialised approaches are challenging to convey across disciplines, especially if people don’t know why they should care in the first place. The minute we start listing all the tools (Figma, Storybook, Supernova . . .) and resources (component library, tokens, icons . . .), attention dissipates. In most conversations I’ve had (outside the design system maintainer circles), stakeholders weren’t asking what the ingredients of a design system were, how they were built, and how they connected. It’s too close to the metal. What was critical was what the design system enabled. We keep looking for a better name for design systems when there isn’t one.
The unhelpful nomenclature purity Sarah Federman described, that focused on specific terms and rigid compositions, is very much alive (just yesterday I saw an article proclaiming that someone has a UI kit, not a design system). I’ve seen too many design systems grow unused and stale because they were treated as an optional nicety “only for designers” (it’s in the name!) rather than a vital operational framework. Despite the popularity of design systems, this isn’t an isolated scenario.
Inevitably, we need terms to translate across functions. We need fluidity in our language, tailored to our users (something the design function already does really well). I want to explain when a design system used, and what does it mean for individual roles and the organisation. If we can’t demonstrate the impact and leverage, securing funding for a design system as an ongoing initiative and meaningfully growing its adoption will be difficult. The challenge isn’t a design system rebranding, it’s a cross-functional translation.
When talking about design systems, we often reach for broader terms, such as product, methodology, and infrastructure. All have potential to bridge the gap for different audiences:
- Product: resonates with product-led audiences (managers, leaders) bringing useful concepts such as roadmaps, setting up feedback loops, understanding the user, and treating adoption as a success measure. However, products are optional: they can be deprioritised or not bought, leaving design systems in a constant sales-loop, looking for funding and attention.
- Methodology: enticing for designers, engineers, and delivery leads, as it describes a way of working and delivering software. However, methodologies are notoriously hard to quantify to leadership, making it challenging to describe the funding cost and potential return on investment.
- Infrastructure: speaks to cross-functional leadership and finance, implying shared investment, ongoing maintenance, reliability, and non-optionality. However, infrastructure can still be treated as a cost to cut, which brings back the same funding fight.
None of these is the right name. All of them answer a different question—how we build, how we run the system, and why we invest in it. I most often go with infrastructure, as it resonates most effectively across functions, and travels furthest. A few years ago, I read Deb Chachra’s “How Infrastructure Works” (excellent for anyone, but especially systems thinkers), which further solidified infrastructure as my default abstraction. Deb writes:
“Technology is more than just the physical systems. These are human systems, created by and for humans to serve particular needs and desires, and to meet them in particular ways. Technologies develop into infrastructural systems because of the evolving roles they play in our lives.”
Despite writing about literal infrastructure systems (sewers, pipes, cables, or bridges), Deb nails down the collectivism a system requires to become something more than a set of seldom used tools. She highlights how infrastructure is universal because everyone relies on it. And yes, as Sam Anderson outlined, infrastructure is boring—not due to the lack of complexity in the challenge, but because specialised, ongoing care going into its maintenance results in resilience (which Deb writes about at length).
Success isn’t an organisation finally understanding what a design system is. It’s every team knowing what it does for them, in terms that make sense, so it becomes the way things get built rather than something to continuously explain.