Overview
During my time as the UX/UI Designer for Wealth Wizards, my role involved overseeing three platforms across 2 brands: Brand A was for "myEva", and Brand B was for "Turo Digital"
As the only UX/UI Designer in the organisation, I treated this as a a side-project which I worked on during down times, between June 2019 to September 2020.
Two of the company's products, with the same UI framework but different brands.
The Problem
Before I was hired for the role, the organisation had only ever outsourced UX designers. This meant there was no track-record of any UI design for the products, nor a design to developer handoff process between the teams.
"Each time a new design was developed in one brand, I had to re-do the design in the second brand"
In June 2019, around 8 months into my role, it was becoming increasingly difficult to manage the designs for three platforms and brands as a team of one. Each time a new design was developed in one brand, I had to re-do the design in the second brand which was inefficient and time-consuming.
For the handoff process, the developers and I relied heavily on the Invision inspect function. As time went on however, more and more issues became apparent. Visual inconsistencies and UI fragmentation became noticeable - both in the live product and in my own design files. Design debt was also accumulating at a fast rate.
Relying on the inspect function was not the answer. I had to find a more efficient way to design.
The Goal
The goal for the design system was three-fold:
1. Establish a better design to dev handoff by creating a "source of truth" that was not the high-fid wireframes.
2. Establish a more efficient design process for myself, so I can do more and be productive in my role.
3. Roll out the design system to the rest of the organisation, as the centre for visual language and digital experiences for of the company's products.
Research & Explore
I had never built a design system before, having only heard about its existence through online design communities. In order to see whether design systems were an answer to the problems, I needed to research and evaluate more into what a design system is and does.
Atomic Design
After reading up on countless design system handbooks, articles, videos, as well as attending webinars to hear from industry experts, I had a rough idea of how to build a design system.
I also familiarised myself with the work of Brad Frost - the pioneer of Atomic Design, so I could get a deeper, theoretical understanding of how to approach design systems, and what digital products are really made of.
Example of all the different text styles (atoms), defined as symbols in Sketch.
Step 1: Design Audit
With Atomic Design fresh in my mind, I spent 1-2 days auditing everything from what was live in the products, to my own design files. I compiled a list of different types of atoms and components, until I covered the majority of all existing UI components across the three platforms.
I then went through the list and removed any outdated, duplicated or unsuitable components - eventually narrowing the list down until there was only one design per component.
Step 2: Build The System
I then got to work, building the design system from scratch.
Utilising Symbols in Sketch, I was able to start building each of the individual components and create a master version for each. Focusing on Brand A, I began defining the smallest level of atoms such as font sizes, text styles and colours, before combining them into molecules and components, such as buttons, input fields, cards, etc.
I then worked iteratively, expanding on the documentation to include more detail, like button states, mobile responsive guidelines, interaction patterns, etc. until I was happy with the level of information.
I then duplicated the documentation so I could create one for Brand B.
"I went ahead and published the documentation for Brand A and Brand B in two separate design systems."
As I was already using Sketch as my primary design tool, it was an easy decision to use Invison's Design System Manager as the place for the design system. In addition to it being free, I could also create more than one design system, and host it publicly so anyone from my organisation can access it.
I went ahead and published the documentation for Brand A and Brand B in two separate design systems.
Example of the type of the type of visual guidelines I defined for each of the components/patterns.
Step 3: Trial & Error
My first mistake was creating one design system per brand. At the time, it seemed like the right thing to do, as I could refer to the respective design system for each brand. After a few months of using the two design systems however, I realised it was becoming extremely cumbersome to maintain both systems (on-top of my daily responsibilities as a designer).
"There was an imbalance between the level of detail and documentation across the brands."
I had the time to update one system but not the other, which meant that there was an imbalance between the level of quality and correct information across the brands. This caused confusion when I passed designs off to the developers or QA, but the "source of truth" were mismatched.
Step 4: Revisions
I considered the possibility of combining the design systems - but was afraid it would become too big to maintain. How would I present two brands in one design system without the documentation getting messy? It was important that the design system wasn't a jumble of rules, but clearly laid out guides that anyone in the organisation can follow.
There wasn't much resource on multi-brand design systems, but fortunately, after coming across an interesting webinar from Figma about creating multi-brand design systems, it gave me an idea on how to go about combining the design systems into one.
Variables
The basis was to always have a "base" or blank version of the component, then switch and apply the brands using variables. With confidence, I went ahead and combined the two systems.
Example of defining colours using variables. This makes it easier to swap and apply stylesheets per brand.
Step 5. Combine Systems
The next step was to combine all my components into one file. During this process, I also had to think about naming conventions as I couldn't have two symbols with the same name.
As Brand B was the white-label version of the products, it felt right to have Brand B as the base component, and any other brands would build on-top of this base. So for all Brand A (MyEva) symbols and components, I simply added an (M) suffix at the end of each symbol name.
This meant I could easily search up the name of a component when designing, and add an M to my search if I wanted to look for the component in Brand A.
Example of using the (M) suffix to distinguish the components for different brands.
Step 6: Multi-Brand Documentation
The final challenge was to decide how best to present the documentation in a way that made sense. The design system had also grown twice in size. I had two options:
1. Present the symbols by Brand, then separate by component.
2. Present the symbols by component, then separate by Brand
After some sketching and thinking, I realised I would fall into the same mistake I did before if I went with the first option. I decided to following the same framework of defining the "base" component before applying and separating by brand.
Step 7: The Launch
The multi-brand design system was launched in September 2020, and currently stands as a visual design system for now (no code integration). The system has matured a lot since its conception, and has evolved into a hub for QA's to refer to for visual tests.
"I was able to reduce [rebranding] time to just under an hour."
I also created a master file, which not only contains the symbols and text styles, but web and mobile templates as well - and is the only file that syncs with the Invision Design System. The master file is hosted on our organisation's Confluence Design space.
My goal to make design more efficient was achieved. The average time it took for me to re-brand a 4-5 screen design was around 1.5 to 2 hours. After setting up the master file and templates to work from, I was able to reduce this time to just under an hour. I could swap the entire design of a component with one click.
A glimpse of the live design system, with components defined first then brand.
A peek into the master component file, with both brands defined.
It's Just The Beginning
The design system is still very new, with lots of potential to grow.
Ideally, the next step would be to dedicate time with the developers to build out the code for the components in Storybook. The design system already has buy-in from the engineering and product teams, however the next challenge will be to get the whole organisation on board.
Due to resource constraint, the system currently exists as a visual reference only, but the hope is for it to be able to integrate seamlessly with Storybook one day, and eventually become an entity in itself where we can phase out the need to rely on third party services - to allow the whole organisation to take ownership of it.
