When I started working with Missouri Star Quilt Company, my scope was relatively straightforward: support its primary e-commerce experience and continue developing the design system around it. Missouri Star is a family-owned company that grew from a small quilting business into a major online retailer of quilting fabric, precuts, patterns, tools, and supplies, with a substantial educational presence.
Over time, my work expanded across related brands in the broader portfolio, including LoveCrafts and Yarn.com. Each has its own audience, visual identity, content, and business needs. At first, the obvious solution seems simple: give every brand its own design system. But at portfolio scale, that creates another problem.
The problem wasn’t three brands. It was three versions of the same decisions.
If every brand is treated as a completely independent system, much of the underlying work gets repeated: color architecture, typography, components, responsive behavior, interaction states, documentation, QA, and maintenance. The visual output may differ, but many of the decisions underneath are the same.
The cost is not only additional design time. It becomes duplicated decisions, duplicated maintenance, and duplicated complexity.
That led me to a different question: What actually needs to be unique to a brand, and what can be shared underneath it?
That question became the foundation of the multi-brand design-system architecture I am building today.
One global foundation, multiple local systems
The model begins with a Global Design System, but I do not think of it as one enormous library containing every finished component for every brand. Its role is more fundamental: establish a shared language that local brand systems can build on.
At the foundation are primitives for color, sizing, and typography. Above them sits the semantic layer, where raw values acquire meaning. Instead of creating a different semantic token for every brand, the semantic meaning stays stable while its value changes through brand modes.
A role such as Brand / Surface Primary can mean the same thing across LoveCrafts and Yarn.com while resolving to completely different values for each brand.
Today, LoveCrafts and Yarn.com are connected through this shared global architecture, while their local systems continue to contain the mappings, assets, components, patterns, and behaviors that are specific to each brand. Missouri Star is the next brand to connect to the same foundation.
The Global DS becomes more like a shared contract than a finished product.
One semantic language does not mean one visual language
A multi-brand system is only useful if it creates reuse without erasing brand identity.
LoveCrafts and Yarn.com should not look alike, and they do not. Their audiences, visual personalities, typography, colors, content, and overall experiences are different. Yet the same semantic roles can exist across both while each brand resolves them in its own way.
The system standardizes meaning, not appearance. Modes separate system intent from brand expression, allowing different brands to share the same underlying architecture without becoming visual variations of the same website.
The result is visible in the final experience: two clearly different brands, supported by the same system underneath.
Shared components do not mean universal components
The same principle applies to components.
If every brand is built directly into component variants, a simple component can start multiplying across brands, sizes, states, themes, and exceptions. A more scalable approach is to keep shared component logic where it genuinely belongs while semantic tokens and modes determine the brand expression.
But shared does not mean universal. The global component layer should contain patterns that are genuinely reusable. Each local brand system can still have components created specifically for that brand’s needs, interactions, or content.
The goal is not to force LoveCrafts and Yarn.com into the same component set. It is to avoid rebuilding common logic when the underlying behavior is already shared.
LoveCrafts proved the model at production scale
A design-system architecture can look convincing while it is small. The more meaningful test is what happens when it becomes large. LoveCrafts gave me that proof.
Its ecosystem now includes 68 components, 2,527 component variants, 1,208 icons, and 28 production email templates. At that scale, this is no longer a theoretical framework. It is production infrastructure.
The email templates are particularly important because they show that the system does not have to stop at website UI. Once a brand has structured tokens, assets, components, templates, and rules, the same foundation can support operational design: repeatable branded work such as email, campaign assets, and other recurring outputs.
Yarn.com proved the architecture can travel
A system built around one brand can always become optimized for that one environment. The more meaningful test is whether the architecture still works when a second, visually different brand joins it.
Yarn.com provided that test.
Its visual identity and experience are different from LoveCrafts, but much of the underlying architecture can remain shared: semantic structure, foundational logic, and reusable system patterns.
This is the difference between reusing a design and reusing an architecture.
The goal is not to make Yarn.com look like LoveCrafts. The goal is to let both brands share infrastructure without sacrificing what makes either one distinct.
Missouri Star should not have to start from zero
This is where the model becomes especially useful.
Connecting Missouri Star to the global foundation does not make the brand automatic. There is still real design work: mapping its identity, evaluating shared components, creating unique patterns, resolving exceptions, testing, refinement, and governance.
But the common infrastructure does not need to be reinvented.
Instead of beginning with “How should we build another design system?”, we can start further ahead:
What is actually unique about Missouri Star?
Less effort goes into recreating foundational logic. More effort goes into the decisions that actually differentiate the brand.
The real value is operational
Design systems are often discussed in terms of consistency. Consistency matters, but I think that undersells their value. The larger opportunity is operational.
Solve a common problem once and reuse it. Change shared logic and reduce parallel maintenance. Connect another brand by mapping and adapting instead of rebuilding the foundation. Shared semantics mean fewer basic decisions to repeat.
This is where operational design becomes important to me. It is not about replacing creative work or brand thinking. It is about creating systems that make recurring design work faster, more consistent, and easier to scale across teams and brands.
A design system becomes business infrastructure when it reduces the cost of the next decision.
Structured systems also change what AI can do
AI works better when it has structure.
Without a system, it may generate something visually plausible without understanding which rules matter, what components already exist, or how a specific brand should behave. A mature design system gives AI context: tokens provide values, semantics provide meaning, components provide reusable structures, brand modes provide context, and skills or rules describe how those pieces should be used.
That creates a different workflow from simply asking AI to “design a page.” A product or e-commerce team could describe what it needs. An email team could request a branded template foundation. AI could use the relevant system rules to generate a structured starting point in Figma, after which a designer reviews, corrects, refines, and approves the result.
This is where operational design and AI intersect. AI can help generate more of the repeatable first-pass work, while the designer continues to own architecture, brand judgment, exceptions, quality, and governance.
AI can accelerate production, but it cannot own design judgment.
From website design to portfolio infrastructure
What started for me as work around one e-commerce website gradually became a different type of design problem. The question is no longer only, “How should this page look?” Increasingly, it is, “What system will allow this page, this brand, and the next brand to be designed more effectively?”
The goal is not one universal system that makes every brand look the same. It is a shared framework that lets each brand remain distinct while avoiding unnecessary duplication underneath: one semantic language, multiple brand expressions, shared infrastructure, and local flexibility.
For me, this also points to a new role for the designer. A designer can define and govern the infrastructure that allows an entire portfolio to work more efficiently, and make that infrastructure usable by both people and AI.
I see multi-brand design systems as a real capability designers can offer companies with multiple brands or products. As AI takes on more repetitive production work, the designer’s value moves upward: toward architecture, semantics, brand rules, reusable systems, creative direction, and judgment.
AI does not make the design system less important. It makes a well-designed system more valuable.
I believe this is one way designers can stay relevant and become more influential in the AI era: not by competing with AI on production speed, but by designing the systems and rules that AI works within.
That, to me, is the real opportunity of a multi-brand design system.