Figma Variables at Vodafone UK: how we structured taxonomy for a complex multi-brand design system
Published by Alex Dyulgerova and Robyn Layton
When we started working on this project leading up to the Variables launch at Config 2023, we came across lots of insightful information albeit no ready-made solution for our use case, nor the discovery process that led to other frameworks’ informed decisions. Therefore, we hope documenting our journey may provide some inspiration for anyone else starting to apply Variables to their design system.
Problem statement
Source Web is Vodafone’s design system, built to serve 500+ designers, developers and other internal employees across 6+ markets, with a focus on the UK specifically.
Vodafone UK is made up of three main customer-facing brands:
- Vodafone — its parent, which sells a vast catalogue of products and provides network coverage for all its sub-brands
- VOXI — its youth offering
- Talkmobile — simple SIM Only deals
The brands within Vodafone essentially sell the same products, yet have been designed in silos and treated by the business as entirely distinct entities.
Source Web was always set up with the intention to support a variety of brands, languages, seasonal campaigns, themes, sub-themes and inverse components. Whilst we work towards a business-approved solution between designers and developers, our engineers have been proactively implementing various code patches to enable a level of theming.
Our current multi-brand method in Figma involves duplicating components into a sub-brand library and applying styling overrides. These components keep a connection to the parent library, but there is an understandable concern about accepting library updates as they can often erase any local theming. Bloated outdated files exacerbate designers’ primary concern about memory issues, while developers lack a single source of truth.
It goes without saying, the effort required to build and maintain multiple design systems for each of these brands isn’t time/cost-effective or scalable.
Goal
We needed a future-proof taxonomy structure to provide uniformity and empower reuse appropriate for a multi-brand approach.
Led by the culture of innovation at Vodafone, we are pioneering efforts to identify commonalities among our systems, a challenge yet to be resolved.
Research
Our research began before the release of Variables. Tokens weren’t a new concept but were still relatively abstract without an industry-standard format. Exploring existing frameworks played a key role in shaping Vodafone’s unique taxonomy and we recommend covering these resources in your own discovery.
We started with established design systems such as Material Design, Adobe’s Spectrum, IBM’s Carbon, NewsKit, Sainsbury’s Luna, Microsoft’s Fluent 2 and Atlassian to get an understanding of how tokens are being applied and documented out in the wild already.
Next, we thoroughly investigated articles and presentations from some key voices including James and Louis’ intro to design tokens file format from Schema 2022, Brad Frost’s post on theming design systems, and Nate Baldwin’s take on flexible token taxonomy.
The real turning point for us came from Nathan Curtis’ exploration of Naming Tokens in Design Systems, his in-depth insights provided a great framework for us to start breaking down the anatomy and categorisation of a design token, and how to apply this at the scale we required.
Taxonomy
As per Nathan Curtis’ article, we started with the basics by reviewing atoms and choosing a Button to trial token naming conventions on. This progressed to more complex elements, which were trickier to untangle but helped to identify common structures across our most-used components, that otherwise might not have been immediately clear.
Testing
Upon the introduction of Variables in June 2023, we tested our initial mapping structure, split into:
- Primitives Collection, hosting non-colour values (spacing, radius, etc)
- Colour Collection, handling all digital brand HEX codes
Both used modes to separate the brands — however, it quickly became apparent that one Collection cannot all host brands, themes and sub-themes effectively. Additionally, colours between brands often don’t map exactly, where some values aren’t required, leaving gaps in the taxonomy. This led us to divide the Colour Collection into Brand Collections, using modes for themes and sub-themes.
A discovery from working with Vodafone’s brand designers revealed that identity palettes tend to be heavily print and above-the-line focused, supplied with brand-specific names that are later adapted for digital applications. For instance:
- Vodafone Red (brand colour) becomes Primary1 (digital colour)
- Aubergine (brand colour) becomes Secondary1 (digital colour)
- Fresh Orange (brand colour) becomes Warn (digital colour)
Creating individual Brand Collections enables respective brand teams to own and control rebrands/adjustments without disrupting aliased Variables. Retaining the connection with the core brand terminology also promotes better cross-team collaboration, as it’s easier for the teams to speak the same language.
These Brand Collections would then feed this information into their related Primitives Collection, converting branded values into agnostic digital tokens. This connection is important for revealing any missing colour tokens for themes, accessibility and digital interactions that might not have been considered by the brand palette.
During our exploration, we took guidance from Luis and Jacob’s Deep Dive which highlighted a missing element in our structure, the Semantic Collection. Here is where we connect the brands using Modes and give intent and purpose to the Primitives’ agnostic raw values. These Semantic tokens are applied directly to the components, which is how they inherit their styling and logic for mapping between brands. Applied in this way enables designers to simply switch between the brands in their files.
We moved from testing Variables on the component level to the context of an entire page. What wasn’t immediately obvious before doing this, was the importance of separating breakpoint-related tokens from Semantics into its own Page Collection.
Currently, all of our components have variants for three breakpoints to work correctly. With the new Page Collection, we would be able to significantly reduce the library’s size by two-thirds, as we would no longer require these variants. This layer of control will dramatically improve the usability of Source Web — making it leaner, smarter and more user-friendly by allowing consuming teams to switch entire files according to the breakpoint they’re working on.
Another key takeaway we identified from the last iteration, was Variables gave us space to create a white-label brand (Brand Zero) at no extra cost or effort. Acting as a universal wireframe system, it strips any associated brand styling from our components, helping consumers of Source Web envision the design system as a themeable product and encouraging best practice design driven by purpose and intent over aesthetics.
Results
This proof-of-concept effectively emphasised the practical advantages of Variables and that there’s no need to reinvent the wheel to cater to sub-brands. Our proposed framework intends to solve existing pain points and ensure a future-proof multi-brand structure:
- Theming: theming and sub-theming within brands are made easy without the need to fork the library to support sub-brands and seasonal campaigns
- Brands colour mapping: all brands will have individually tailored Brand and Primitive Collections that simplify colour mapping in the components, highlight missing tokens, and empower collaboration
- Memory efficiency: Component size can be reduced by two-thirds with Page Collection
- Mental blocker for adoption: white label Brand Zero will promote components’ functionality over visual treatment
- Consistency: Variables will help to identify patterns that can be overlooked
- Buy-in: showcasing Variables’ versatility and time-efficiency will help to sell the idea of adopting tokens as part of the Design System sooner, justifying the allocated time and budget needed to do so
This project has shaped Vodafone UK’s taxonomy map, inspired by Nathan Curtis’ categorisation. You can download a copy for further details using our community file.
Next steps
As of writing this article, Figma Variables are in open beta, meaning that not all required Variables are available yet. We eagerly anticipate more functionality in future releases that would allow us to fully integrate this work into our library. In the meantime, we plan to work with our developers to align on taxonomy naming and plan how to roll Variables out to our teams in the least disruptive way.
Acknowledgements
We would like to thank our design lead M Smith for trusting us with the opportunity to find the best solution for this complex challenge, and to Figma for inviting us to share and present our journey to the wider UX community at their open coffee mornings.
