In brief: A multi-brand design system works when teams share the decisions that should remain consistent—accessibility, interaction behavior and component contracts—while giving each brand a controlled way to express itself through semantic tokens, content and visual assets.
The mistake is choosing between one identity and total independence
A portfolio of products can have a common owner without looking like one product. A news publication, a marketplace and a design service may need different moods, language and commercial expectations. Making every screen use the same colors and type would erase those differences. Rebuilding every button and form from scratch would duplicate behavior that ought to stay dependable. The useful question is which rules are shared, at which layer, and who can change them.
IBM offers a helpful reference, though it is not a prescription for every small team. Its Design Language covers the brand across products, communications, events and digital touchpoints. The same IBM ecosystem links Carbon for product interfaces and separate guidance for IBM.com and other contexts. That separation shows how a recognizable parent language can coexist with implementations tailored to a particular surface.
Build the system in three layers
The first layer is a shared interaction contract: form validation, focus states, keyboard navigation, loading behavior, error recovery and the semantics of actions. These rules should rarely vary simply because a logo changes. The second layer is a set of semantic design tokens: surface, text, border, accent, spacing and type roles. A component asks for an accent color, not a brand-specific hex value. The third layer is the brand package: typography choices, imagery, motion, voice, logo rules and the mapping of semantic roles to visible values.
This structure prevents a common failure. If the brand is encoded directly into each component, a new brand requires dozens of overrides. If the component API exposes too many cosmetic switches, each team assembles its own unofficial system. A small set of deliberate variants and tokens makes differentiation possible without losing governance.
Keep brand recognition where users actually notice it
Not every difference belongs in a token. A marketplace may need provenance cues, seller identity and product photography. An editorial publication needs bylines, dates, source links and clear sponsored disclosures. A service studio needs a persuasive offer and an unmistakable contact path. These are content and information-architecture differences, not palette swaps. Brand teams should list the moments users remember, then decide which are represented by shared primitives and which deserve their own composition.
Shopify's Polaris update makes another distinction visible: common APIs can serve different surfaces while presentation changes with the context. Its published explanation says Admin, Checkout and Customer Account components use familiar properties and values while relying on different design systems when needed. That is evidence for a shared contract across surfaces, rather than evidence that every surface must look identical.
A practical governance test
Put three real pages from separate brands next to each other: an onboarding form, a transactional confirmation and an editorial story. Mark each rule as shared, configurable or unique. Shared rules should come with automated checks for accessibility and behavior. Configurable rules need named tokens and ownership. Unique rules should remain in the brand application until repetition justifies promotion into the shared system.
Then measure the cost of change. If a required focus fix needs three repositories and three separate design reviews, a shared contract is missing. If a change to one brand accidentally alters another, the boundary between shared behavior and brand expression is too loose. Those two failure modes give a more honest signal than counting how many components are in the library.
The decision for a small brand network
Start with a written map of common patterns and a few semantic tokens. Publish brand-specific examples beside each shared primitive so contributors see both the rule and the permitted range. Add a new shared component only when two brands need the same behavior. The goal is a system that helps teams make aligned decisions, not an impressive library of unused abstractions.
This is an editorial synthesis of the cited public systems. IBM and Shopify did not endorse this three-layer framework. It is a working model for teams that need both clear family resemblance and enough freedom for each product to do its own job.