Building a white-label design system to scale across branded web and mobile apps
As a Saas product in the digital healthcare industry, LifePlan addresses patient success in various therapeutic areas, such as chronic kidney disease, multiple sclerosis, and maternal health.
When I joined Ayogo in January 2021, one of the biggest challenges was to create a white-label product that appeals to a broad demographic and can adapt to any brand's style guide.
Overview
COMPANY
MY ROLE
-
Planning & implementation
-
UX & UI Design
-
Accessibility & Usability
-
Documentation
TIMELINE
-
January - March 2021
First launch -
Mar 2021 - present
Maintenance and updates
TOOLS
Figma
Notion
Jira
Outcomes
450+ Interactive & connected components
1500+ Component variables
150+ High-fi screens
20+ Interactive prototypes
Impacts
Higher level of consistency for designs.
Increase velocity and quality for the Design team.
Minimized design and development overhead.
CONTEXT
What is a white-label healthcare product?
Usually, a digital healthcare product focuses on the end-users -- patients and healthcare professionals in a specific therapeutic area. But a white-label healthcare product must consider two groups of users, the end-users and the company buying the product.
Ayogo works with healthcare companies that are experts in various therapeutic areas. Each client's product shares the LifePlan design components but is developed with unique branding, content, and feature set. LifePlan is designed to be re-branded so that each product speaks to the client's distinct end-user groups.
In order to be re-brandable without compromising the client brand's identity, LifePlan needs a flexible design system that can adapt to different "skins".
This is how an education page looks in different client apps.
White-Labeled ➡️ Renal ➡️ Maternal
GOAL
Implement a design system with scalable UI libraries
To quickly prototype and produce consistent designs, the design team needed reusable and standardized UI components. In addition, we need to efficiently launch, update and maintain the UI library as we scale up with rebranded UI components for new clients.
CHALLENGE
Is Figma the right tool?
The design team had just moved from Sketch to Figma, so I started by investigating the relevant Figma functionalities. Figma's published library and interactive components are great for creating reusable components and reflecting updates instantly. It also offers ample space for annotation & documentation.
CHALLENGE
How to manage conflicting priorities?
I was one of the 3 designers, 2 researchers, and 10 developers working on the LifePlan product team. The deadlines were tight and I had to work on the design system alongside product feature designs.
To deliver on time, I prioritized an essential set of components to create, test, and implement. As new feature designs took place, additional components were tested and added to the design system.
I use Notion to track and plan priorities.
RESEARCH
What is a good design system for LifePlan?
Gather internal requirements
"Component updates or additions should be simple so that designers and developers get the latest without much wait."
"Easy-to-use for designers."
"A source of truth for designers and developers."
Establish guiding principles
Scalability
Support different structures across mobile and desktop; customization with minimum configuration and code change.
Accessibility
Inclusivity
Comply with WCAG AAA standards.
Usable for diverse user groups.
Study industry examples
I did extensive research and learned from industry leaders, like Shopify's Polaris, Alibaba's Ant Design, Spotify's in-depth articles. I followed Material Design closely since it's designed to be white-label and based design on the PrimeVue UI library to minimize development effort.
PLANNING
Set hierarchy using the Atomic Design System
Where it succeeded: happy designers
The famous Atomic Design Methodology was very helpful when I initially started thinking about the framework -- it offers a way to group components, creating a clean separation between structure and content.
I structured the system into 6 levels: Atoms, Molecules, Organisms, Templates, Pages, and Snowflakes ❄️. This sets the foundation for a scalable and robust white-label design system.
This is what the library looked like initially:
Where it failed: confused developers
When I showed the initial layout to developers, I found out that designers and developers have different ideas about what could be a molecule and what could be an organism. Simply grouping them following Atomic Design can lead to confusing communication and hinder implementation.
Instead, I grouped the white-label components by design patterns in one Figma file. Each page is named to reflect its components, and the pages are sorted alphabetically.
This is what the library looks like now:
Figma UI Library - Style guide
Figma UI Library - Buttons
Figma UI Library - Style guide
CHALLENGES
Building interconnected UI Libraries
One challenge was to keep every branded component connected to the white-label components in the core library and allow customization based on the client's brand styleguide.
Each library has a set of defined styles (Text Styles, Color Styles, Effect Styles) and UI components named following a consistent & universal naming convention, making it easy to bulk edit when needed.
This setup allows the design team to access components from any Figma file, and keep the feature-based UI designs as their own files.
In addition, universal changes can be made easily with one click when a design is updated.
CHALLENGES
Documentation
A key part of the Design System is documentation - this is what enables it to become a single source of truth.
The challenging question was: what needs to be documented and where is the best place to keep documentation?
In Figma, I keep documentation of patterns & usage available in the same place as the components. This provides an immediate reference for developers and designers, as Figma is the primary workplace for them.
In Notion, I keep other documentation including Content Guides and Style Guides. This allows access by a broader audience, such as the marketing team.
Next Step
Maintaining & improving
As I look back from this point, I realized one thing is missing. Since I've been the sole designer maintaining the LifePlan Design System and the process is always evolving, I overlooked the need to document the process of maintaining the design system. As our design system matures and the team grows, a clearly defined process would provide guidance in my absence.
To make the Design System a true source of truth, this process of maintaining and documenting need more developer input. As a next step, I would engage the development team in accessing the usability of documentation tools such as Storybook and Zeroheight.