Considerations
When selecting the right setup for your organization, consider the following key questions:
🔹How many brands, products, or platforms do you need to support?
Larger organizations with multiple independent product lines may benefit from separate design systems, while smaller teams may prefer a single system with structured brand layers.
🔹Will your teams require separate governance and permissions?
If different teams or departments need distinct access levels, independent design systems might offer more flexibility in managing permissions.
🔹Do you need a shared documentation site, or do different audiences require separate ones?
A single design system allows for a unified documentation hub, while multiple design systems provide separate, dedicated websites for different product areas or brands.
🔹How frequently will different brands or platforms be updated, and do they need independent versioning?
Teams operating on different release cycles may require separate design systems to manage updates independently.
🔹What level of autonomy do your teams need in managing their design systems?
A centralized system streamlines collaboration, while separate design systems allow teams to work independently with their own governance structures.
🔹What is the size of the team working on the system?
A smaller team might find it easier to maintain a single design system, whereas larger teams with multiple contributors may need separate systems for better governance.
🔹Who will be consuming the system?
Are external vendors, brand designers, or contractors part of a different section? Are they contributing, or do they only need limited access to specific areas of the system?
Comparison Table
To help you decide which setup best fits your organization, here’s a quick comparison of the key differences between the two multi-brand design system approaches in Supernova:
| Setup 1: Single Design System | Setup 2: Separate Design Systems | |
|---|---|---|
| Number of Design Systems in Supernova | One design system housing multiple brands within a shared structure | Multiple independent design systems, each dedicated to a specific brand, product, or platform |
| Documentation Website | One unified documentation site for all brands | Each design system has its own separate documentation website |
| Brand Differentiation | Managed using the Brand feature and Themes to separate data sources and override token values | Each brand/product/platform has its own independent design system with no shared documentation |
| Code Automation | Centralized code automation pipelines, but can be configured to export brand-specific tokens and assets | Separate code automation pipelines for each design system, allowing independent governance and updates |
| Collaboration and Roles | All contributors share access to a single design system, without granular role separation | Teams can have different roles in different design systems, with more controlled access and visibility settings |
| Use Cases | Best for teams needing a shared foundation across multiple brands while keeping documentation and data sources in one place | Ideal for organizations requiring completely independent governance, separate teams, and distinct product areas |
💡 Pro Tip:
Your setup isn’t set in stone—many teams start with a single system and transition to multiple design systems as their needs evolve. You can begin with a core foundational Design System and scale into a multiple Design System approach as your organization grows.
➡ What’s Next?
By now, you should have a clearer vision of how to structure your multi-brand design system and which setup best fits your use case.
Now, let’s dive into the setup you’ve chosen and walk through how to get everything up and running!
[
Setup 1
Single Design System
Learn how to structure your Design System using Brand layers, manage Design Data efficiently, and keep all documentation in one centralized hub.
Setup 2
Separate Design Systems
Discover how to manage separate Design Systems, create independent documentation sites, and structure your workflow for scalability.