Making a multi-brand design system makes a lot of sense. It saves each brand re-inventing the wheel, creating a nth Button component when every other brand already has one. It's effectively the design system benefits at scale. Not only does each team within an org get the [[benefits of a design system]], each organisation gets the benefits of the shared system.
Anecdotally, most multi-brand design systems that I've seen start with an agnostic base. A foundation that does not cater to a single brand, but rather caters to every brand. This assumes that each brand wants a distinct style, but can act within the scope of a brand. This does create a [[coupling]], however. As always there's nuance here, and individual systems will have leniency on how much things can be stretched. Variations exist that may cater to certain brands more than others, but code is still made with sharing in mind. A future brand may also use a more tailored variation. [[20221202114400-design-system-consistency]]
This greatly increases the time required for the first brand. In theory, you save that time going forward, as each brand added is minimal effort. It also makes creating a new brand quicker, as you've already got a headstart. That time is also saved if you need to update the base - all brands gain the benefits. The hard part is making the agnostic base that supports everything.
There's also effort in making each brand use the same spec. Since the shared system often acts as a superset - it needs to encompass everything that every brand needs. Each brand needs to be talking the same language, adjusting as needed for its brand. For example, the behaviour of all components is probably shared across brands. Something like colours though, probably differs per-brand. However each brand needs to be interoperable. If brand A requires 9 shades for every brand colour, then brand B may need to increase their colour palette to better support the new agnostic base.
A lot of this work then becomes people problems rather than technical problems. A single design system across brands means that design system needs to support everyone, and appropriately weigh up the requests of one brand to another. If your brands have subtly different goals, this can get even more difficult. When can you find the time to make a component that is only used on a subset of brands? Something like [[20220704011551-tiered-design-systems]] can help here.
Theming two different different design systems to be interoperable is difficult, and maybe not even possible. Often not all components have a 1:1 replacement, meaning you're using different APIs, conventions, layout, abstractions, etc. Ideally, most things are achieved through [[designtokens]]. But depending on the flexibility between brands, that may or may not be possible. Once you get outside the realm of tokens (think, functionality), the complexity grows quickly.
A somewhat similar approach is to make your components brandless, and each brand can compose them into something that fits their brand. This approach probably relies on each brand bringing more to the table, as many components won't exist in the base. https://www.designsystems.com/the-forge-harrys-approach-to-multi-brand-design-systems/
Alternatively, align on a visual language, with separate codebases. Akin to Material Design which has different implementations, this allows you some wiggle room while still achieving cohesion across different brands. It becomes blurry on if this is one design system or multiple, but there's wiggle room as needed.
https://saleena.design/portfolio/project-5/ https://medium.com/bts-design-team/building-a-multi-brand-design-system-79469d425bf3 https://uxdesign.cc/challenges-of-multi-brand-design-systems-42d7e7b1d18c https://www.youtube.com/watch?v=u1mi0VJOuZ8
[[20220822094537-themeable-design-systems]] [[202310041150420-design-system-themes-brands-modes]]