Multi-brand design system: sharing infrastructure without standardizing every identity

A multi-brand design system organizes foundations, components and rules that can be shared across the brands of a group. The goal is to reuse what should be consistent and allow variation where there is a strategic difference. Sharing a form component does not require every brand to have the same expression.

For companies with many digital products, duplication tends to be hidden. Different teams solve the same error states, navigation patterns and accessibility problems. At the same time, excessive standardization can erase the attributes that justify each brand's existence.

Separate structure, behavior and expression

Structure defines how components are organized. Behavior covers interaction, focus, validation and states. Expression brings together typography, colors, shapes, motion and language. This separation lets you discuss what can really be shared, instead of just applying different colors over a single interface.

Semantic tokens should communicate function: primary text, primary action or elevated surface. Each brand can assign its own values to those roles. Exceptions need to be documented so the implementation does not depend on local adjustments that cannot be maintained.

Start with the flows that cost the most to repeat

Map journeys and frequency of use before cataloging components. Forms, search, navigation and product identification can be priorities when they appear across many properties. A vast gallery of rarely used components is not a sign of maturity.

• Identify two products from different brands and a common flow.
• Compare the real needs, including error states and assistive technologies.
• Build a shared version with separate themes.
• Test adoption by the teams before expanding the catalog.

The library needs a maintenance model

Define who accepts contributions, publishes versions and communicates breaking changes. The GOV.UK Design System contribution criteria offer a public reference for evaluating shared patterns. The group should adapt that process to its own brands and products.

In a hypothetical scenario, three units might share the behavior of a sign-up form but use different language, typography and composition. If one unit requires an additional step for business reasons, that should be a planned capability or an explicit exception, not a permanent copy of the component.

How to evaluate the return

Observe adoption in active products, implementation time, recurring defects and maintenance effort. Compare similar journeys, accounting for complexity. A reduction in design files does not by itself mean a reduction in cost. The gain has to show up in the teams' work and in people's experience.

Include accessibility in the acceptance criteria. WCAG 2.2 offers testable criteria; using a library does not guarantee that each final page meets them. Content, composition and integrations also need to be verified.

Is a design system just a library in Figma?

No. The system has to connect design decisions, implementation, documentation and maintenance. The library is one of its interfaces.

Who should fund the system?

The investment should reflect the shared benefit and have defined owners. The Studio practice can work alongside the Website practice to turn identity into a usable foundation. See also how to organize multi-brand website architecture.