Back to top
Back to top
Scroll down
X
App
X
Desktop
Saving over 1 million € in costs by setting up a design system (B2C & B2B)
In this case study I want to show you how I build a multi-brand white label design system from the ground up that consists 3 main design systems and around 16 OEM/client design systems. Together with design tokens and a stakeholder focussed filee structure was I able to decrease development costs, increase concistancy and enable automation within the DCS.
Scroll down
App
X
Desktop
Saving over 1 million € in costs by setting up a design system (B2C & B2B)
In this case study I want to show you how I build a multi-brand white label design system from the ground up that consists 3 main design systems and around 16 OEM/client design systems. Together with design tokens and a stakeholder focussed filee structure was I able to decrease development costs, increase concistancy and enable automation within the DCS.
Scroll down
X
App
X
Desktop
Saving over 1 million € in costs by setting up a design system (B2C & B2B)
In this case study I want to show you how I build a multi-brand white label design system from the ground up that consists 3 main design systems and around 16 OEM/client design systems. Together with design tokens and a stakeholder focussed filee structure was I able to decrease development costs, increase concistancy and enable automation within the DCS.
ROLE
Lead Product Designer
TIMEFRAME
January 2022 to today
Summary / Solution 🌱
My first steps when joining the DCS was to build up a design system that improves the collaboration with the QA teams as well as the development teams. For that, we completely switches to Figma, I created two main design systems for for our B2C and B2B product. Many designer changes generated inconstiancy between products and screens/flows that the centralized design system fixed.
Increase of stakeholder trust from QA & development.
Decrease of design revisions by at least 45%.
Automation of rollouts in the UX department by at least 80% to other OEMs
Decrease of front-ends bugs by around 18% from QA
Building 3 main and 16 OEM design systems within 1 year from the ground up
Copyright disclaimer: The copyright remains to the respective owners of this project!
ROLE
Lead Product Designer
TIMEFRAME
January 2022 to today
Summary / Solution 🌱
My first steps when joining the DCS was to build up a design system that improves the collaboration with the QA teams as well as the development teams. For that, we completely switches to Figma, I created two main design systems for for our B2C and B2B product. Many designer changes generated inconstiancy between products and screens/flows that the centralized design system fixed.
Increase of stakeholder trust from QA & development.
Decrease of design revisions by at least 45%.
Automation of rollouts in the UX department by at least 80% to other OEMs
Decrease of front-ends bugs by around 18% from QA
Building 3 main and 16 OEM design systems within 1 year from the ground up
Copyright disclaimer: The copyright remains to the respective owners of this project!
ROLE
Lead Product Designer
TIMEFRAME
January 2022 to today
Summary / Solution 🌱
My first steps when joining the DCS was to build up a design system that improves the collaboration with the QA teams as well as the development teams. For that, we completely switches to Figma, I created two main design systems for for our B2C and B2B product. Many designer changes generated inconstiancy between products and screens/flows that the centralized design system fixed.
Increase of stakeholder trust from QA & development.
Decrease of design revisions by at least 45%.
Automation of rollouts in the UX department by at least 80% to other OEMs
Decrease of front-ends bugs by around 18% from QA
Building 3 main and 16 OEM design systems within 1 year from the ground up
Copyright disclaimer: The copyright remains to the respective owners of this project!
The Problem
When I started working at the DCS, the design systems was more a rough pattern libary which specific components that were not reusable. The DEVs, QA and PM teams asked for a proper documentation about our products and for more concistancy. Also, was the production on high costs because due to too many revision and design bugs before and after implementation.
The Problem
When I started working at the DCS, the design systems was more a rough pattern libary which specific components that were not reusable. The DEVs, QA and PM teams asked for a proper documentation about our products and for more concistancy. Also, was the production on high costs because due to too many revision and design bugs before and after implementation.
The Problem
When I started working at the DCS, the design systems was more a rough pattern libary which specific components that were not reusable. The DEVs, QA and PM teams asked for a proper documentation about our products and for more concistancy. Also, was the production on high costs because due to too many revision and design bugs before and after implementation.
Design system of core challenges
When building a multi-brand design system, it is important to know the needs of stakeholders first before you start to build it in a way only for the UX team and yourself. Doing my first month at the DCS, I defined some core challenges from stakeholders that need to be full-filled to get a better adoption across the organisation.
Title goes in here
Title goes in here
The DCS had a huge lack of documentation of screens and flows
Title goes in here
Title goes in here
Missing collaboration between UX and DEV created to much costs
Title goes in here
Title goes in here
There was no consistancy across the products
Deep dive into the solutions
Starting with the basics
Before I started with just building of what is already in the products, I was thinking about the strategy on how to get buy-in efficiently. Many people say that tools don't matter, but for me are tools important to make work efficient in any way, in the own work and in collaboration. We are UX designers should be clear that UX of our business tools is as important as the software we make UX/UI for.
"Building a multi-brand white label design system normally takes 1.5 to 2 years, but we just have 6 month for the first version."
Using the right tool - the switch to Figma 🧰
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
File structure in the hidden king for buy-in 👑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
A definition of purpose and business goals ✨
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
Problems and steps back 🛑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
Refactoring starts by building backwards ⏪
CHARGE NOW and CHARGE NOW for Business as well as our other 15 brands where already established, therefore it was important to make a huge audit about what we already have in our design system and what was missing. I came quickly to the conclusion what we need to rebuild every single component again in Figma, afterwards was the plan for phase two to start with a proper refactoring of the design system into the IONs design system
Talking about the business side of a design system was an important factor
Most people seeing UX/UI always from the design side only, establishing a design system was important to improve concistency and decrease development costs by deleting complexity and reusablibity in components and screens. This is what I was always communicating to the other stakeholders and developers to make sure they understand the value of it.
Starting with the basics
Before I started with just building of what is already in the products, I was thinking about the strategy on how to get buy-in efficiently. Many people say that tools don't matter, but for me are tools important to make work efficient in any way, in the own work and in collaboration. We are UX designers should be clear that UX of our business tools is as important as the software we make UX/UI for.
"Building a multi-brand white label design system normally takes 1.5 to 2 years, but we just have 6 month for the first version."
Using the right tool - the switch to Figma 🧰
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
File structure in the hidden king for buy-in 👑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
A definition of purpose and business goals ✨
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
Problems and steps back 🛑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
Refactoring starts by building backwards ⏪
CHARGE NOW and CHARGE NOW for Business as well as our other 15 brands where already established, therefore it was important to make a huge audit about what we already have in our design system and what was missing. I came quickly to the conclusion what we need to rebuild every single component again in Figma, afterwards was the plan for phase two to start with a proper refactoring of the design system into the IONs design system
Talking about the business side of a design system was an important factor
Most people seeing UX/UI always from the design side only, establishing a design system was important to improve concistency and decrease development costs by deleting complexity and reusablibity in components and screens. This is what I was always communicating to the other stakeholders and developers to make sure they understand the value of it.
Starting with the basics
Before I started with just building of what is already in the products, I was thinking about the strategy on how to get buy-in efficiently. Many people say that tools don't matter, but for me are tools important to make work efficient in any way, in the own work and in collaboration. We are UX designers should be clear that UX of our business tools is as important as the software we make UX/UI for.
"Building a multi-brand white label design system normally takes 1.5 to 2 years, but we just have 6 month for the first version."
Using the right tool - the switch to Figma 🧰
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
File structure in the hidden king for buy-in 👑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
A definition of purpose and business goals ✨
Establishing a multi-brand design system is not only a huge project, it is also connected to huge costs on the company side, you have to do a lot of meetings, it can cause to development costs due to a mismatch, it also can end up in a big development project because you need to setup a code-base design system. To get better buy ins, I openly share my vision of goal of the design system, I planned several meetings and workshop to get a buy in from PMs and devs to make sure they know why we need it.
Problems and steps back 🛑
Not all works out the way we want it. I had sometimes a lot of push bak to bigger changes and issues. Therefore I broke down improvement and changes into different steps to make sure we have actionable items on design and UX side.
Refactoring starts by building backwards ⏪
CHARGE NOW and CHARGE NOW for Business as well as our other 15 brands where already established, therefore it was important to make a huge audit about what we already have in our design system and what was missing. I came quickly to the conclusion what we need to rebuild every single component again in Figma, afterwards was the plan for phase two to start with a proper refactoring of the design system into the IONs design system
Talking about the business side of a design system was an important factor
Most people seeing UX/UI always from the design side only, establishing a design system was important to improve concistency and decrease development costs by deleting complexity and reusablibity in components and screens. This is what I was always communicating to the other stakeholders and developers to make sure they understand the value of it.
IONs Atomic Design - The future of the DCS way of working
A long while ago, I found the Atomic Design framework that supports the design systems by creating the smallest most generic elements within a design system with later can be re-used by different componentns. This framework got updated around 3 years ago and I decided to use this framework to build the DCS design systems. Also directly when I came to the DCS, I also brought in Figma to the company.
Using the right tooling - Figma 🧰
When I started working at the DCS, I brought in Figma, Dovetail and Maze into the company. With Figma, I started to build the design system. Here I started to work backwords and analysed what is on PROD to slowly build the design system. It took me around 3 month of analysis, building and coordination of the external designers to build 3 main design systems doing that time. The design system were build doing full production.
Basic file structure is key for buy-ins and collaboration 👬
When you want to get buy in for a tool and new way of working, you need to consider "interal tooling UX" - this means that you need to make everything frictionless as possible so that the adoption rate of your tools increased within the company. Every file was structured based on the different cross-functional teams, this supports that stakeholders know where to look and where to go, so that they don't need to learn something new. This is very similar to UX for products and services, but only for internal tools.
Setting up of a design system process 🚦
The most important part was to keep the design systems updated as they now function as the ultimate source of truth at the DCS for PMs, DEVs and QAs. So a process was needed to update the components properly. Here I build a process so that we have less bottlenecks by defining specific branching rules for the designers, for example critical updates on the base design system need branching with reviews where the pages files where the final screens are stored don't need reviews and branching, this makes sure that the designers can update the screens quickly and only important component updates that affect several front ends need to be reviewed.
IONs Atomic Design - The future of the DCS way of working
A long while ago, I found the Atomic Design framework that supports the design systems by creating the smallest most generic elements within a design system with later can be re-used by different componentns. This framework got updated around 3 years ago and I decided to use this framework to build the DCS design systems. Also directly when I came to the DCS, I also brought in Figma to the company.
Using the right tooling - Figma 🧰
When I started working at the DCS, I brought in Figma, Dovetail and Maze into the company. With Figma, I started to build the design system. Here I started to work backwords and analysed what is on PROD to slowly build the design system. It took me around 3 month of analysis, building and coordination of the external designers to build 3 main design systems doing that time. The design system were build doing full production.
Basic file structure is key for buy-ins and collaboration 👬
When you want to get buy in for a tool and new way of working, you need to consider "interal tooling UX" - this means that you need to make everything frictionless as possible so that the adoption rate of your tools increased within the company. Every file was structured based on the different cross-functional teams, this supports that stakeholders know where to look and where to go, so that they don't need to learn something new. This is very similar to UX for products and services, but only for internal tools.
Setting up of a design system process 🚦
The most important part was to keep the design systems updated as they now function as the ultimate source of truth at the DCS for PMs, DEVs and QAs. So a process was needed to update the components properly. Here I build a process so that we have less bottlenecks by defining specific branching rules for the designers, for example critical updates on the base design system need branching with reviews where the pages files where the final screens are stored don't need reviews and branching, this makes sure that the designers can update the screens quickly and only important component updates that affect several front ends need to be reviewed.
IONs Atomic Design - The future of the DCS way of working
A long while ago, I found the Atomic Design framework that supports the design systems by creating the smallest most generic elements within a design system with later can be re-used by different componentns. This framework got updated around 3 years ago and I decided to use this framework to build the DCS design systems. Also directly when I came to the DCS, I also brought in Figma to the company.
Using the right tooling - Figma 🧰
When I started working at the DCS, I brought in Figma, Dovetail and Maze into the company. With Figma, I started to build the design system. Here I started to work backwords and analysed what is on PROD to slowly build the design system. It took me around 3 month of analysis, building and coordination of the external designers to build 3 main design systems doing that time. The design system were build doing full production.
Basic file structure is key for buy-ins and collaboration 👬
When you want to get buy in for a tool and new way of working, you need to consider "interal tooling UX" - this means that you need to make everything frictionless as possible so that the adoption rate of your tools increased within the company. Every file was structured based on the different cross-functional teams, this supports that stakeholders know where to look and where to go, so that they don't need to learn something new. This is very similar to UX for products and services, but only for internal tools.
Setting up of a design system process 🚦
The most important part was to keep the design systems updated as they now function as the ultimate source of truth at the DCS for PMs, DEVs and QAs. So a process was needed to update the components properly. Here I build a process so that we have less bottlenecks by defining specific branching rules for the designers, for example critical updates on the base design system need branching with reviews where the pages files where the final screens are stored don't need reviews and branching, this makes sure that the designers can update the screens quickly and only important component updates that affect several front ends need to be reviewed.
Lets build a sun system
When I started to set up the file structure of our tools at the DCS was it important for me to structure the files after 3 criterias. First, stakeholders who use the different files. Second, designer autonomy and third, platform based files also related to OEMs.
The logic behind file structures 🧮
The file structure is an extention of the IONs Atomic Design logic but intertrated to the file structure of the DCS. At the DCS we have several design systems for our platforms like web, iOS and AND as well as B2C and B2B business. Then we also have up to 16 different OEM white label design systems which are based on our main design systems. All files are based on their connection to each other and the stakeholder involved in every system file. The goal was to set up a structure that is on one hand efficient and scaleable and on the other hand good understandable for stakeholders like PMs, DEVs, QAs, Sales etc.
File structure strategy - stakeholder first 🙍♀️
When it comes to the enablement of UX in a company, stakeholders should easily understand what we are working on, how it impacts their work and decision in the company and therefore your need to have file structure that is suitable and easy to understand for the stakeholders. It is like creating a good User Experience for the company. That means you need to provide a structure that anyone is aware of and this is the company structure, I build our UX tools structure around the company structure and then started to teach the stakeholders how to use and find files.
200 out of 250 stakeholder using our UX Tools daily
Within the last 2 years, we had an adoption rate of our UX tools of nearly 85% in the company. Stakeholders, especially developers and the QA team seeing for example Figma as the ultimate source of truth.
Lets build a sun system
When I started to set up the file structure of our tools at the DCS was it important for me to structure the files after 3 criterias. First, stakeholders who use the different files. Second, designer autonomy and third, platform based files also related to OEMs.
The logic behind file structures 🧮
The file structure is an extention of the IONs Atomic Design logic but intertrated to the file structure of the DCS. At the DCS we have several design systems for our platforms like web, iOS and AND as well as B2C and B2B business. Then we also have up to 16 different OEM white label design systems which are based on our main design systems. All files are based on their connection to each other and the stakeholder involved in every system file. The goal was to set up a structure that is on one hand efficient and scaleable and on the other hand good understandable for stakeholders like PMs, DEVs, QAs, Sales etc.
File structure strategy - stakeholder first 🙍♀️
When it comes to the enablement of UX in a company, stakeholders should easily understand what we are working on, how it impacts their work and decision in the company and therefore your need to have file structure that is suitable and easy to understand for the stakeholders. It is like creating a good User Experience for the company. That means you need to provide a structure that anyone is aware of and this is the company structure, I build our UX tools structure around the company structure and then started to teach the stakeholders how to use and find files.
200 out of 250 stakeholder using our UX Tools daily
Within the last 2 years, we had an adoption rate of our UX tools of nearly 85% in the company. Stakeholders, especially developers and the QA team seeing for example Figma as the ultimate source of truth.
Lets build a sun system
When I started to set up the file structure of our tools at the DCS was it important for me to structure the files after 3 criterias. First, stakeholders who use the different files. Second, designer autonomy and third, platform based files also related to OEMs.
The logic behind file structures 🧮
The file structure is an extention of the IONs Atomic Design logic but intertrated to the file structure of the DCS. At the DCS we have several design systems for our platforms like web, iOS and AND as well as B2C and B2B business. Then we also have up to 16 different OEM white label design systems which are based on our main design systems. All files are based on their connection to each other and the stakeholder involved in every system file. The goal was to set up a structure that is on one hand efficient and scaleable and on the other hand good understandable for stakeholders like PMs, DEVs, QAs, Sales etc.
File structure strategy - stakeholder first 🙍♀️
When it comes to the enablement of UX in a company, stakeholders should easily understand what we are working on, how it impacts their work and decision in the company and therefore your need to have file structure that is suitable and easy to understand for the stakeholders. It is like creating a good User Experience for the company. That means you need to provide a structure that anyone is aware of and this is the company structure, I build our UX tools structure around the company structure and then started to teach the stakeholders how to use and find files.
200 out of 250 stakeholder using our UX Tools daily
Within the last 2 years, we had an adoption rate of our UX tools of nearly 85% in the company. Stakeholders, especially developers and the QA team seeing for example Figma as the ultimate source of truth.
Improvement of collbaoration with important stakeholdern - Hello "Feature Files" and Design Tokens
The born of "Feature Files" and their connection to the design system was an important step to increase trust and improve structure. Feature files supported QA to test features much better by displaying flows in the right area of the feature file. This supported the systematic testing of features.
Feature file basic structure for better UX within working files
Ziggo, the smart suitcase app that lets you control your luggage like a smart home! With Ziggo, you can easily lock and unlock your suitcase, check the battery level, and even receive notifications if your suitcase strays too far from you.
Decrease of UI rollouts by 80% with design tokens and automation
At the DCS, we use Jira as out main tool to plan out features and requirements as well as sprints. Always when someone creates an new EPIC in Jira that needs the UX team involved, then we create new feature files (in Figma, Dovetail and Maze) based on the name of the EPIC and also include the name and FE into the name. This supports users by using the search bar in our UX tools to find the file and screens that they are looking for.
Improvement of collbaoration with important stakeholdern - Hello "Feature Files" and Design Tokens
The born of "Feature Files" and their connection to the design system was an important step to increase trust and improve structure. Feature files supported QA to test features much better by displaying flows in the right area of the feature file. This supported the systematic testing of features.
Feature file basic structure for better UX within working files
Ziggo, the smart suitcase app that lets you control your luggage like a smart home! With Ziggo, you can easily lock and unlock your suitcase, check the battery level, and even receive notifications if your suitcase strays too far from you.
Decrease of UI rollouts by 80% with design tokens and automation
At the DCS, we use Jira as out main tool to plan out features and requirements as well as sprints. Always when someone creates an new EPIC in Jira that needs the UX team involved, then we create new feature files (in Figma, Dovetail and Maze) based on the name of the EPIC and also include the name and FE into the name. This supports users by using the search bar in our UX tools to find the file and screens that they are looking for.
Improvement of collbaoration with important stakeholdern - Hello "Feature Files" and Design Tokens
The born of "Feature Files" and their connection to the design system was an important step to increase trust and improve structure. Feature files supported QA to test features much better by displaying flows in the right area of the feature file. This supported the systematic testing of features.
Feature file basic structure for better UX within working files
Ziggo, the smart suitcase app that lets you control your luggage like a smart home! With Ziggo, you can easily lock and unlock your suitcase, check the battery level, and even receive notifications if your suitcase strays too far from you.
Decrease of UI rollouts by 80% with design tokens and automation
At the DCS, we use Jira as out main tool to plan out features and requirements as well as sprints. Always when someone creates an new EPIC in Jira that needs the UX team involved, then we create new feature files (in Figma, Dovetail and Maze) based on the name of the EPIC and also include the name and FE into the name. This supports users by using the search bar in our UX tools to find the file and screens that they are looking for.
RESPONSIBILITIES
Overall UX/UI strategy
UX/UI Vision & Mission
UX LTP Roadmap
Design System & Research Lead
UX Mentorship
Team
Florian Louis
Elvin Thang
Danielle
Roma
Loyd
Apoorva
Jasmine
Kelsey Smith