Skip to main content
Question

Multibrand design system and inverse component variants

  • August 20, 2026
  • 3 replies
  • 37 views

KatK

Hi there!

We have a large multibrand system with 17 brands which i’ve inherited. 

Each brand has 2 primitive collections (standard + colours), and then the semantic collection which houses each brand as a mode.

There was no planning for inverse/knockout variants of components, so those needing an on-dark or a flexible background colour (and corresponding text colours) which of course we now need for some brands.

In the case of our footer, i had created knockout tokens to sit in the existing eg: font/colour/interactive/text button group and then created a new variant of the footer to map them too and added a boolean switch between the default and inverse themes.

 

But is there another way (without refactoring all of our tokens)

3 replies

Jaycee Lewis
Figmate

Hey hey ​@KatK 👋 Great question! Inheriting a large multi-brand system is never a small thing.

I think your knockout tokens are in a good place, we just need to change how components consume them.

If i’m understanding your challenge, the main issue is: Each collection has its own mode axis, and axes stack. Yours has spent its one axis on brand, so inverse has nowhere to live. This is why you chose to use the boolean. But inverse is orthogonal to brand.

Have you considered giving Inverse its own collection?

  • Add a collection above semantic — Theme, or Surface — with two modes, Default and Inverse
  • Put only the tokens that actually flip in it (text, icon, border, interactive-on-surface)
  • Each one is an alias: Default → your normal token, Inverse → your existing knockout token
  • Rebind the components that need to invert so they consume Theme
  • Your 17 brand modes stay untouched

Context: objects are set to Auto by default and inherit their parent container's mode. So you set Inverse once on the footer frame and everything nested follows. To my eye, no boolean, no inverse variant, no threading a property through nested instances.

One question: is inversion always whole-surface (footer, hero, banner), or do you need inverse elements on default backgrounds in the same view? Whole-surface suits the mode cascade. Mixed genuinely wants explicit on-inverse tokens, in which case what you built is right and you'd just drop the boolean. 

 

Talk soon! — Jaycee


KatK
  • Author
  • New Member
  • August 21, 2026

Oh thank you SO much for answering!!

I was starting to play around with this idea, because some of our teasers will also need flexible bg colours, so was thinking of expanding the them modes in this seperate collection with brand, inverse, tertiary, secondary etc..

To the footer, the bg is controlled by 1 set token, so that doesnt need to flip, as well as decoration line (yet).. But the inversion should flip the text, text links, icons. 
 

Best wishes

Kat


Jaycee Lewis
Figmate

Hey ​@KatK 🤩 Thank YOU for asking a great question.  I think your instincts are right.

Two things to consider while it's cheap:

  • Put the background token in that collection too. It doesn't flip today, but keeping bg and on-bg together means picking a mode always gives you a matching pair
  • Add the decoration line now with the same value in every mode. Costs nothing, saves work later

One thought: inverse describes contrast, secondary and tertiary sound like emphasis. If every mode answers "what surface is this sitting on?", designers can pick correctly without a doc.

One note: the cost isn't tokens, it's contrast checking. Each new mode is more validation across 17 brands

Have an amazing weekend! — Jaycee