A mode too far. Problems using Figma variable modes for multiple brands.

Firstly, I really like Figma as a tool. I don’t need to explain the impact it’s had or how dominant it’s become. You already know that.

With the popularity, the expectations on Figma are absolutely huge, I do not envy them one bit.

I can’t speak for the jobbing product designer but from a Design System perspective, the role of producer and consumer feel like they have somewhat reversed lately. We used to see Figma drops and think about what possibilities they could open up for us. Now we are so often just waiting and hoping for what we see as essential features and fixes – we’re the ones at the back shouting for “more boring stuff please”. We have such high expectations of features we need, we are often left underwhelmed when they actually arrive.

The Design System team I work with test everything out. The days after a feature is released we jump into Figma and see what we can do with it — is it going to solve that problem we’ve had for the last year…or not?

While lots of teams run with everything straight away, and I do envy that a little bit, 80% of the time we choose to do nothing. Are we just stuck in our ways? Are we the luddites in this scenario? Am I the Gareth Southgate of Design System Library Management? Maybe, but more often than not it’s because the release we’ve been waiting for hasn’t materialised in the way we’d hoped.

Our Design System consumers require a certain amount of stability and predictability to be confident in us, we are not willing to risk this to use the latest features if we don’t believe they work how they should.

Figma variables were obviously the most highly desired feature of systems teams for such a long time that this expectation was absolutely through the roof. Arguably the variables solution we got works very well for people doing product design work, it is arguably not quite there for enterprise scale library maintenance.

While we’ve had quite a few issues with variables and modes (we use them but we still don’t directly publish them to consumers because of these concerns) the focus of this blog is why we haven’t used variable modes to create a single multi-brand library. I know it’s totally possible, but it is it actually practical?

Overview

The key areas of concern were:

• Design System change management process and quality assurance
• The inability to control the release of NDA projects, such as acquisitions
• The inability to work on and control the release of rebrands

I’m going to focus on these key areas of concern, but the secondary concerns were:

• Scope of existing components may need to change to reduce performance issues of larger single brand libraries
• Performance impact of multi-mode in prototypes
• Complexity. The libraries are not just for visual designers or UI experts
• All existing “evergreen” Figma projects would need to be rebuilt from scratch
• Per-brand analytics reports are not possible
• Some components (usually ones with branded assets) require multiple brand variants anyway

Design System Management

Figma recommended a multi-library approach for different layers of a system. For example, creating separate libraries for:

• Variables
• Assets
• Styles
• Components
• Patterns

Each library has a very specific remit, and each consuming library has a dependency on one or more of the libraries below it.

Simply put, a change to a foundational element such as a variable or style will need to cascade up through all consuming libraries.

It’s unclear if this is still the recommendation, but it would appear that having variables in their own file(s) is considered good practice.

Staging a style change

The only way to ensure we can roll out a style change in a stable fashion is to stage that change in the consuming libraries before it’s released.

This is good practice to ensure you don’t release a change that doesn’t work as expected or causes design system libraries to be out of sync with each other. Not to mention there’s sometimes actual changes that need to be made because of the style update that can’t be done in the gap between releasing libraries.

This QA process has proved to be essential. In the entire time our teams Figma Libraries have existed, we have not had a single issue reported regarding issues from library updates and we’re proud of that.

The staging process

How we manage this currently is based on the practical limitations of Figma and the relationship between related libraries. It is far from ideal but it works.

Staging a style change looks something like this:

• Make a change in Styles (Branch)
• Duplicate the Styles (Branch) as a new file and publish to the team only
• Swap library in Components (Branch) to the Styles (Branch) copy
• Duplicate Components (Branch) with swapped library as a new file and publish to the team
• Create Patterns (Branch) and swap library to the Components (Branch) and Style (Branch) copies

Releasing that change looks like this:

• Merge Styles (Branch) into Styles (Main)
• Release Styles (Main)
• Swap library in Components (Branch) from copy to (Main) and accept changes
• Merge Components (Branch) into Components (Main)
• Release Components (Main)
• Swap Patterns (Branch) back to Components (Main) and Styles (Main) and accept changes
• Merge Patterns (Branch) into main
• Delete Styles (Branch) copy and Components (Branch) copy

Sounds fun huh? This is the “easy version”, in reality you need to loop over this many times.

If only there was a way to publish branches to team while keeping main public. Or the idea of grouping libraries as a dependent set that can all be staged for release together.

Using variables in this staging process

Variables, whether in (Branch) or a (New mode) cannot be tested in Styles (Main), Components (Main) or Patterns (Main) because:

• Figma does not allow you to swap variables
• We are not confident in third party Swap Variables plugins after reviewing their documentation. We felt those we reviewed may be too dangerous to introduce into our libraries — after all libraries are major assets of design infrastructure in an organisation
• Variables created in a new mode will be published to any user of the system — they can only be tested “in the open”
• Variable modes cannot be independently published (e.g. Mode A to all, Mode B to team), wow that would probably solve everything!

Simply put, we cannot have any confidence in how variable changes would affect consuming libraries because we cannot test any changes to variables before they are released to everyone. The first time we see them in components is after they’ve been published.

In our opinion, this approach cannot meet our internal standards for quality assurance of the system.

The inability to control the release of NDA projects and brand changes

Because of the practical limitations outlined above, all of the below would need to happen “in the open” and be available to anyone with access to the Figma libraries:

• Any rebrands or UI changes to existing brands
• Any modes being created for unannounced acquisitions
• Any additional modes (e.g. dark mode, high contrast, low contrast)

We would not be able to release a new brand on a specific date or stop people within the organisation being aware of the rebrand as it’s happening.

This is not about being overly protective of the changes, this is about not releasing in-progress, confusing or contradictory work when it’s not ready to be consumed.

The only way to handle these changes in private would be to create an entire duplicate set of libraries. When they’re done we’d either ask all users to switch all of their files when it was ready or remake all the changes manually in the main file.

This has some serious practical challenges for users of the system. Historically, it’s only something we do for major brand changes and only for the individual brand that’s been changed. The solution for everything cannot be to make a new library.

Manually re-creating the changes in the main library after designing and testing in a duplicate set will always be prone to errors. The actual release candidate will have never been tested. It’s likely that fatigue, memory and pace will introduce issues in the released version that didn’t exist in the duplicate.

Because a single library approach covers all brands, a major change to any one brand will be a major change to every brand.

In summary, with a multi-library set, it is almost impossible to test out new variables before you release them. This is simply not good enough for us to be confident in the quality of the libraries that are being released.

Last week, Figma released what I thought would be a bit of a silver bullet for some of this, the ability to copy and paste variables between files. I’ve had this blog in my drafts for almost a year and I thought I was going to be able to delete parts of it. That release however does not solve this problem, hence why you’re reading this now. EDIT: This issue was resolved the same day as posting this. Yes!

I don’t want to pile on to Figma for stuff like this, I know that library maintainers are not actually their primary audience and they’ve got a lot of features to ship. Almost all of us work on or have worked on products where we know important features are not prioritised. It’s just the way digital products work.

But when you do become the only possible tool to use for this type of work in a large organisation, and that organisation depends on libraries, this link in the chain is incredibly important.

So what about using modes for single brand libraries?

Having modes for contextual and theme adjustments for one brand seems a lot less problematic.

Things like:

• Dark mode
• Breakpoints
• Alternate layout contexts
• Regional or Language differences
• Sub theme e.g. minor audience based modification of the brand

When I think about what Figma released modes for, I think it was for this stuff.

While using and releasing modes still has all the practical workflow problems, working in a single brand library means there will be more privacy for rebrands and less impact for consumers of existing single brand libraries.

A change to one brand, is not a change to all. Nobody sees anything they shouldn’t see. Nobody uses anything before it’s ready to be used. It is still near impossible to quality assure the output — but there is simply a lot less at stake.

Maybe the idea of adding multi-brand into the mix was perhaps, a mode too far? Or is it simply that the tooling is just not quite ready for it?

Acknowledgements

I am painfully aware that Figma modes for multi-brand is a closer representation of theming in code.

Different organisation shapes and sizes will have a different view of what is or isn’t acceptable. For some, the positives may outweigh the negatives.

Using modes is no doubt quicker and less maintenance for a library team–The counter to that is that the burden should be on us, not our consumers.

I’m not suggesting modes won’t be the way to go for this in the future, I just don’t think it’s ready right now.