UX Case Study: Building a white label design system for the world's leading insurance company 🇨ðŸ‡
BACKGROUND
My client is one of the world’s leading providers of insurance and reinsurance (insurance for insurance companies) based in Switzerland.
One of their core product offerings was to offer other insurance companies a personalized and customizable digital workflow that they could share with their customers to apply for insurance. This process has a lot of underwriting, business rules, and geographical constraints that had to be adhered to so that a standard product offering can be launched.
When I joined the company in late 2021, they had already developed a basic workflow that was being tested by their parent company. However, the goal was to scale this solution to serve 20+ partners within the next quarter.
Objective
Based on the existing workflow, create a flexible, scalable, and brandable white-label product using a comprehensive design system that could adapt to varying brand identities and operational scales.
Core Team
- 1 designer
- 12 developers
- 1 business analyst
- 1 product manager
Time
4 months, full-time engagement
My Role:
As the project lead, I was responsible for strategic oversight and hands-on implementation of the design system, facilitating collaboration between stakeholders, guiding developers, and documenting the design process.
Tools
Figma, Storybook, ZeroHeight, Confluence.
What is a white-label product?
White labeling is the process of rebranding a single product or service for multiple companies to sell as their own. White labeling benefits the manufacturer and the reseller.
The manufacturer can focus on production and not worry about marketing and selling, while the reseller can outsource production and focus on selling products through its sales and distribution networks.
What is a design system?
A collection of reusable components and standards (colors, typography, UI elements) that ensure consistency and efficiency across a product’s interface.
Why do we need a design system for a white-label product?
White-label design is a popular strategy for building SaaS products. Instead of manually changing the same element in multiple files (also prone to human error), a design system allows for automatic updates throughout the application by just changing a single instance.
Challenges and Solutions
Creating a design system based on an existing workflow that did not use standard controls.
Using standard components in Figma, I recreated the existing workflow that was initially designed by developers. Through this standardization process, I identified a list of must-haves and good-to-have components that would form a complete and comprehensive design system.
Supporting localization for 8+ languages and dynamic content.
The existing translation schema was migrated to a Crowdin-powered CMS for the manual translation of keys. During the onboarding process, each partner was initially responsible for translating the app.
One designer working on day-to-day tasks along with this new added responsibility may take years to perfect a design system.
In an effort to accelerate the process, I began by duplicating the vanilla material design system, utilizing standard specifications and pre-built components, and then added personalized touches to achieve a unique appearance.
Understanding what key differences are possible in the journey for different partners without talking to them.
As our product was not yet publicly available, we were unable to discuss potential partner customization needs. Instead, we analyzed their offline processes and had our business analysts speak with their sales teams. Once we had secured partners, we confirmed our hypotheses. Although it was initially a risky guessing game, it ultimately proved successful.
Research
The material design was my preferred choice as it was created to be easily customized, along with Shopify’s Polaris, Atlassian, Microsoft Fluent, Ant.design, and others. Additionally, numerous articles, blogs, podcasts, and YouTube videos offered extensive insight into various aspects of the design system.
Framework
Rather than immediately diving into identifying each component within our current apps, I chose to take a step back and consider the entire framework. My aim was to construct a robust and scalable system.
I followed the atomic design methodology, which involves breaking the system down into four tiers: Elements, Components, Patterns, and Themes.
1. Elements
Elements lay the foundation for the entire design system. This layer includes colors, typefaces, grids, and spacing.
1.1 Typography
We had a bunch of variants available as the workflow demanded a lot of explainer texts, tooltips, disclaimers, and nested components.
Configurations:
- Font family
- Font size (in px for Figma and rem for dev)
- Font weight
- Line height (generally 1.5x font)
1.2 Spacing
I followed an 8pt linear scale for elements with a 4pt half step for spacing icons or small text blocks. I prefer a 4pt baseline grid for my typography which means the line heights of my font choices will always be divisible by 4. This system is meant to reduce confusion but also be easy to implement.
Configurations: None
1.3 Colors
Color is a crucial aspect to consider, especially when dealing with a white-label product that aims to partner with multiple companies with distinct branding.
Although changing the color values might seem like a small task, it is not an easy process when it comes to rebranding an app. This approach can lead to several instances where it breaks down, resulting in developers and designers spending hours on manual overrides for new clients.
Therefore, we needed a granular approach to control colors on our UI. Over several months, we introduced and tested dozens of new color tokens that gave us full control over accessibility and the final outcome when applied to specific UI elements. These tokens included:
1.3.1 Brand color tokens
Primary and secondary colors are provided by the partner based on their branding.
1.3.2 Base color tokens:
The base shades of grey, black, and white are usually left unchanged, but it’s useful to have the option to configure them in case a brand’s primary and secondary colors match the Pantone.
1.3.3 Role color tokens
We defined component roles, such as button background color, text color, and secondary button border color, while inheriting the branding colors. This allowed us to have complete control over the UI library and even invert the theme for some partners from light to dark if needed.
Additionally, we built the capability to add new colors, such as those for links, tooltips, and disclaimers, in case the brand colors were insufficient.
2. Components
Standard components were built using the ATOMIC structure. Some examples:
3. Patterns
Components are made of elements and perform a well-defined function in the application.
Patterns or modules are a valuable concept for a white-label app since they enable us to modify specific configurations while maintaining the remainder of the app’s design.
This allows the design system to facilitate an agile product development process for both designers and developers.
4. Themes
Now comes the fun customization part. We put together a designer's playbook that outlined the following steps to onboard a new partner:
- Replicate the theme foundations file with the naming convention: Theme-Partner
- Replicate the base workflow file with the naming convention: IWL-Partner
- Replace the logo
- Adapt the font family
- Apapt the brand colors
- Define the base colors
- Define the role colors
- Ensure accessibility with A11y — Color Contrast Checker
- Publish the theme file
- Apply the new theme to the workflow file
- Replace the partner's name in the workflow
- Publish the workflow file
- Share the standard journey with stakeholders
- Customize the journey based on inputs
- Once approved, make the same changes to the mobile version.
- Check for any prototyping glitches and do a walkthrough with a fellow developer.
Although the original theme file is more comprehensive, below is an example of how the theme was implemented for three partners, which represents only 40% of the original configuration.
Final Mockups
Impact In numbers
500+ interconnected components
12 partners onboarded successfully
500% faster to onboard a new partner
20+ hours saved by the design team
80+ hours saved by the development team
100% consistency with customizability
Documentation — The cornerstone that holds it together.
Documentation is a crucial element that holds the design system together. To promote the correct use of styles and best practices, we documented them and made them easily accessible to the whole team.
For this purpose, we utilized Zeroheight for design documentation, while developers used Storybook. Apart from documenting styles, we also documented the reasoning behind the system, which helped other team members to understand why certain decisions were made. By doing so, we were able to identify gaps in our reasoning and evolve the design system accordingly.
Additionally, we documented workflows, including those for creating components and styles, and for onboarding a new client in our design system.
About the author
Atishay is a seasoned product designer known for his strategic approach to design and implementation. His work focuses on aligning user needs with business objectives to create impactful digital solutions.
