Creating multi-brand design systems | Figma Blog
Design systems should provide consistency and speed without becoming rigid constraints. Shopify, Condé Nast, and Harry’s emphasize flexible architectures, brand-specific tokens, continuous iteration, and strong connections between design and code. The most effective system is one that adapts to changing needs while remaining simple enough for teams to use. ## Flexibility Over Rigidity - Overly prescriptive rules can limit creativity and push designers outside the system. - Harry’s uses layered architecture: - Base components offer simple, low-complexity solutions. - More advanced layers, such as starter kits, support custom work. - This approach makes the standard path efficient while preserving room for exploration. - Condé Nast uses modular components and design tokens to support brands such as *Vogue*, *The New Yorker*, and *Bon Appétit*. - A token can represent the same purpose while holding different values—for example, “prominent text” can map to a different font for each brand. ## Design Systems Must Evolve - Building a system is only the beginning; teams must observe how it performs in real use. - Analytics and usage data help identify which libraries and components are being used and where changes are needed. - Shopify aims to create systems that “bend but not break,” rather than polished artifacts that teams are afraid to modify. - Teams should watch how the system fails—including how it affects end users—in order to improve and reinvent it. ## Connecting Design to Code - Translating design components into code improves efficiency and reduces friction between designers and engineers. - Condé Nast stores its token system in JSON and uses a custom plugin to import and export token changes. - This setup helps the company launch new markets quickly while maintaining a smooth design-to-development handoff. - Even teams without multiple brands can start by associating a purpose with each value, such as naming a color or typography style by its intended use. - Purpose-based naming exposes unnecessary complexity and makes systems easier to evaluate. ## A System Designed for the Team - There is no universal design-system model. - The right structure depends on a team’s size, organization, technical environment, and priorities. - Systems should establish useful foundations while leaving enough flexibility for different products, brands, and future requirements. Teams should begin with simple, reusable foundations, connect design decisions to code where practical, and continually revise the system based on actual usage rather than treating it as a finished artifact.
Read original(opens in new tab)