Improved rebranding for a white-label using a tokenised design system
Youtap Technology
Timeframe
Dec '23 - Mar '24
My Role
Team
Overview
When I joined Youtap in 2023, they already had an established design system. As a white-label company, efficient rebranding was essential for onboarding clients.
Current reskin time was too consuming and, due to the size of the design team, there was a growing lack of time allocation to manage and maintain the system.
Goal
To address the growing inconsistencies and maintain design quality, we aimed to focus on improving its scalability.
This involved optimising our style-guide and establishing clear guidelines for future rebranding efforts.
The impacts made
99.95%
Faster rebranding time
From 2 weeks of manual reskin, to 10 minutes, improving client onboarding time.
1000+
UI components
Increasing our UI component system resulting in faster designing and workflow.
Better communication for designers and devs
A common language between designers and developers, improving communication.
Comprehensive documentation for alignment
Keeping track to ensure consistent design over all components and behaviours.
Introduction
What is a white-label product?
White-labels products are a blank template for customers to rebrand as their own, with full customisation to their liking. A Youtap app won't be on the market, but you may see copies of the same product in different colours.
Why do we need a design system?
The biggest challenge with designing large scale products is consistency. By establishing reusable components and design guidelines early on, we can ensure cohesive brand identity across the board.
Not only can we streamline our design workflow, but as a white-label, it's cost effective for rebranding for clients.
Example screens with client branding
The challenges
A small team against a big design system
As two designers alone with other responsibilities on our plate, the gap for maintaining our design system began to grow. For this to become manageable for us, we split the problems to focus on one at a time.
Addressing inconsistencies in our current design style-guide file
Our current design system dated back to 2022, with instances and components linked to other existing files, it could no longer be used as our core asset library.
Improving our own manual rebranding workflow to save on time and resources
Rebranding is one of the unique selling points of white-label, and the ability to onboard clients faster would open up space for us to prioritise other work.
Improving the communication lines with developers
Design systems are not just for designers, developers rely on us to provide them with the visuals needed for their own workflow. If we are inconsistent in our own work, then the team falls out of alignment.
Research
Starting from the beginning with desk research
As this was our team's first attempt at design tokens and complete overhaul of the style-guide, we utilised online resources to understand guidelines and best practices.
We also looked at larger companies with well established tokenised systems, such as Atlassian, Uber and Wise.
Collection of resources used
System overhaul
Creating a clean slate for our core design system to function
The last time the style-guide was updated was in 2022, leading to a lot of consistencies with component changes and client rebranding. This would cause issues with variables if not addressed, as styles applied would not convert in reskins.
To get the file in top shape we used a variety of plugins to remove old linked styles and locate remote components.
Previous setup
After
Tokenisation
Breaking down the components to atomic level would allow us to assign more specific colours based on state and scenario
As we were dealing with a white-label, we had to consider all possibilities that a client may want reskinned. This would require designers and developers to spend manual time changing individual components to a client's desired colour.
By breaking down the components from atomic form to a larger scale, we were able to establish how our tokens behaved in different scenarios.
This allowed us to create a flexible design system that could adapt to various branding requirements and specific features throughout the app.
Repeating the process with tokens to assign them to parts of the component
Much like the UI components, tokens needed to be broken down to understand the nature of where a token should be applied.
Base tokens
The "atomic" level token. These were made up of colours and values only.
Container tokens
The "molecule". This consisted of a specific naming layout applied to a component, which would assign the base token.
Theme modes
The "organism". A collection of tokens under one theme, allowing quick theme switches with the same assigned functional tokens, but different base tokens.
Reaching a common ground with developers to form a shared language
Once we had our component anatomy down, we moved on to building our tokenisation naming system. This was a crucial time to collaborate with developers, as we both had to have an equal understanding of the naming foundation.
The result of these workshops lead us to collectively agreeing on a naming system that suited both parties.
"text - list - description - default"
Figma variables
Utilising Figma's new variable system and reducing our manual rebrand time
Using Figma's variable system we were able to transition from manual rebranding whole library styles to easily switching between themes, by only changing our base tokens,
Here it is in action!
Documentation
A well-documented design system is essential for consistency, efficiency, and future development.
Lastly, we used Confluence for our design documentation, making it accessible to anyone in our company to understand and refer to for best practices.
We also found it particularly helpful to include areas such as behaviour, interaction, and even component size in different values (such as pt and rem) which allowed us to view any gaps and future proof the system further.
Relection
My first take on design systems
As a designer, I learned design systems are not just for designers.
They serves as a comprehensive resource for all team members, enabling them to understand and apply brand guidelines effectively. By documenting the system thoroughly, we empowered our team to make informed design decisions.
Although this project started off as a way to improve how us designers work, actively initiating conversations with developers to understand their perspective was a key to making this project a success.
Not only did we improve our workflow, but also the consistency of our products. Building from an established style-guide felt like putting together a puzzle.
In the future I would be keen to map how our components are built, which could serve as another resource when adding new components.