Design systems aren’t supposed to be straitjackets. But that’s exactly what many multi-product design systems become.
When teams try to scale their single-product design system across multiple products, different markets, even different brands…things get…ugly. Frustrated designers, franken-components awaken, and products that look uniform on the surface but feel awkward to their users.
Here’s the thing: multi-product design systems require a fundamentally different approach than single-product ones. It’s tempting to take what worked for one product and try to force it everywhere else. But, it’s like trying to use house blueprints to build an entire city.
But there’s a better way. And it comes from understanding what makes great cities work in the first place.
The Pattern Language Approach
In 1977, architect Christopher Alexander published “A Pattern Language,” a revolutionary approach to design that changed how we think about creating environments that work for people. Alexander argued that great design emerges from interconnected patterns that work at different scales. A region influences towns, towns influence neighborhoods, neighborhoods influence buildings, and buildings influence rooms. Each level provides support for the level below without dictating exact solutions.
The genius of Alexander’s approach is that it creates coherence without uniformity. Every building in a well-designed city doesn’t (and shouldn’t) look identical, but they all follow patterns that make the city work as a whole. The patterns are flexible guidelines that respond to context, not rigid rules that force compliance.
Alexander understood something profound: living systems can’t be designed through top-down control. They emerge from patterns that enable appropriate responses to local conditions. A great city provides infrastructure, zoning principles, and shared utilities. But it doesn’t mandate that every building serve the same purpose or follow identical blueprints.
This is exactly what multi-product design systems need to do.
The Seductive Dream of Universal Components
There’s something incredibly appealing about the idea of “one system to rule them all.” Build it once, use it everywhere. Maximum efficiency. Perfect consistency. It’s an amazing dream.
Except it’s a dream. It’s not real when you wake up to reality.
Teams spend months building the “perfect” component that can handle every possible use case across every product. The result? A franken-component with endless configuration options that serve no specific interface challenge particularly well. It’s like designing a vehicle that’s simultaneously a sports car, a pickup truck, and amphibious transport. Sure, it might technically work, but it won’t work well for any of those jobs.
The fundamental problem is that different products serve different users with different mental models, different workflows, and different purposes. Your internal account review tool and your customer sign up flow don’t just look different by accident. They should look different. They should behave differently. They’re solving completely different problems.
When we force uniformity across products that have legitimately different needs, we’re not creating consistency. We’re forcing compromise. And compromise, when it comes to user experience, usually means mediocrity.
As Christopher Alexander reminds us, we need to allow the spaces to be built with the system, not allow the system to force spaces into artificially awkward forms. Because users won’t enjoy using it, increasing dissatisfaction until customers eventually leave the product.
One big difference between Alexander’s “A Pattern Language” and a design system is this: Alexander’s work identifies a library of ideas you can pull from, but design systems are more than ideas…they are function pieces that require maintenance and support. It’s one thing to have a list of ideas and concept. It’s a very different thing to be required to support and maintain the functional pieces in a library.
The Foundation vs. Finished Product Mindset
Here’s where teams can go wrong: they confuse foundations with finished products.
A multi-product design system should work more like city infrastructure than a housing development. The city provides utilities, roads, zoning laws, and building codes. But it doesn’t dictate that every building must be identical. Instead, it creates the structural framework that allows different types of buildings to coexist and thrive.
Your design system foundations should provide the structural patterns needed to build with, not dictate the structure itself.
What does this look like in practice? Instead of creating a token system that assumes “two brand colors,” build a token architecture that can accommodate two colors for one product, six for another, and maybe a completely different color philosophy for a third product that serves a different market.
Instead of overly complex components that try to solve every layout challenge, create simpler components that work more like basic HTML elements. They are the most common, core-to-digital experiences pieces. By doing this, you give teams the building blocks and systems of patterns, not the finished interfaces.
Product Kits: Autonomy Within Structure
So what could this practically look like? Build a flexible foundation, then create product-specific kits on top of it.
Think of your foundation as providing the basic grammatical structure of a language with a place for you to define your alphabet. Your product kits use the grammar and its own letters to construct the words that make sense to your culture, and the words to create sentences that communicate meaning.
In our approach, each product gets its own kit that sits on top of the shared language foundation. Just like language, these kits can borrow “words” from each other, but they’re not forced to speak the same way. They only share when it makes sense. An analytics product might have a robust charting kit, but not the marketing website. An admin product might have a comprehensive forms kit, but not the customer-facing status product. A customer-facing product might have a beautiful, spacious presentation kit, but not the back-office management app.
The key is that all these kits speak a language, but they aren’t forced to use the same language. The difference is between speaking the same language with regional accents and colloquialisms, vs the freedom to have entirely different languages with unique syntax and words. They are both languages, with their own alphabet and words, but they aren’t forced to “speak the same language”. OK, I admit this analogy isn’t perfect, but hopefully it gets the basic idea across.
Multi-product design systems use the same token architecture (but not the same tokens), the same rudimentary elements (but their own implementation of them), and the same code connections (but not the same front-end framework). But they’re free to create purpose-built kits that focus on serving their own internal needs and end-users well. Essentially, it eliminates as much compromise as possible to maximize freedom while also still providing cascading architectures and structures to still gain the benefits of a design system.
This approach provides the freedom to solve edge cases elegantly and consistently within product kits. Instead of forcing every edge case into the central system (decreasing usability) or making components adapt to additional, infrequent functionality (creating bloat and debt), teams can extend their product kit to handle their own specific needs without interrupting or interfering with other products in the system. If another product needs similar functionality, they can borrow it and gain that advantage. If not, the blast radius stays contained.
Over the past few years, I’ve seen this work beautifully. One team needed a simplified set of components for an entirely new app, serving a very specific user type. Instead of forcing them to adopt the patterns and display components that existed for our core product, they were able to focus on how to best display the information and build their own new components freely, then adopt (or copy and import) existing components when it made sense. Meanwhile, another team working on a different app had a strong need and desire to adopt the components and patterns from an existing product kit. Then, as needed, they developed a few components to extend functionality within their own local product kit. Providing a common foundation enabled the teams to build in the same system without negatively impacting each other.
The beauty is that both teams created only what they needed, eliminating extraneous technical and experience debt while gaining the incredible efficiency of the design system. Their design and development environments aren’t bloated with extraneous items that don’t exist in their system. It’s focused exactly on their needs. But, all the product kits are still running on the same foundational system, giving them the downstream benefits and efficiencies of design systems.
Building Your Supportive Infrastructure
I’ll admit, it’s a little bit of a mind bender at first. But making this transition has provided a huge improvement for the teams I’ve worked with. It required a big shift in how I thought about design systems. Instead of building a consistency enforcer, you’re building a supportive infrastructure that enables both systematic advantage with appropriate variety.
This starts with being ruthless about what belongs in your foundation versus what belongs in product kits. Ask yourself: Does this element enable building, or is this a finished structure? Does this need to work identically across all products, or does it need to work appropriately for different contexts? Does this element require a specific pattern around it, or can it support a variety of use cases?
Drawing the line between foundation system and the product kit can feel a bit subjective. While it might feel a little risky, it also provides a lot of needed freedom for multi-product support. The risk is that you build too little and your foundation isn’t supportive enough, or that you overbuild and end up with experience and tech debt in your foundation. However, the freedom is that you can tailor your systems and product kits to fit your exact need. So, it requires solid relationships to help you determine what’s truly needed at a multi-product level.
The organizational shift is just as important as the technical one. You need to move from “central control” to “intelligent governance.” Your design system team maintains the core infrastructure and synthesizes the standards that emerge, but they trust individual teams to build appropriately for their unique context.
This means different success metrics too. Instead of measuring how consistently components are used across products, measure how effectively the foundation enables teams to build great experiences for their specific users. And whether product kits have what they need to flourish.
The companies that get this right don’t just have “better design systems”. They have better products, because when you enable teams to build appropriately for their own context instead of forcing artificial uniformity, you get solutions that actually serve users instead of serving the system.
Christopher Alexander understood that great experiences come from patterns that enable life, not rules that constrain it. His patterns create life because they are flexible and diverse. They are invoked to serve the context and intended use. They create coherence without killing necessary flexibility and autonomy.
Your multi-product design system should work the same way. It should be a living language of foundational elements that enable teams to create great experiences for their specific contexts. If teams are constantly fighting your system or requesting endless modifications, you’re not building a life-giving system…you’re building systematic friction.
For the teams I work with, the path forward isn’t more control and rigidity. It’s foundational support, and guidance on when to be flexible and when to be consistent. It’s enablement instead of enforcement. It’s supplying the necessary resources to flex without breaking, which lets your products thrive in their appropriate diversity. That’s how you create a design system that works like a great city.