How to create a design system for white label apps
For the past two years, I have been working on a design system for Brightloom’s white label app business. Unlike most of design systems, it also needs to be highly rebrandable, scaleable, and accessible.
Challenges
A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build a variety of applications. As a design system for restaurant white-label apps, it needs to be highly rebrandable, accessible, and flexible.
Rebrandable
Restaurants should be able to bring their own branding to the system instead of compromising to fit within the system.
Accessible
To support consumer-facing apps, the design system is compliant with WCAG AA standards before and after rollouts.
Flexible
The design system can support different restuarants’ menu structures and customization models through configuration rather than re-engineering.
Framework
Instead of jumping into identifying every component in our current apps, I decided to take a step back to think about the entire framework and figure out a way to build a robust and scalable system.
Following the atomic design methodology, I decided to break the system down into three levels: Elements, Components, and Patterns.
Separating the system into 3 layers helped me isolate each restaurants’ unique branding from other concerns. This way, I won’t have to start from scratch every time a new restaurant buys our apps, nor will I produce individual components that are too rigid and compromise restaurants’ branding.
Elements
Elements lay the foundation for the entire design system. This layer includes colors, typefaces, grids, and spacing.
Using a title as an example, its color, font size, font weight, line height and spacing come from the elements system. This way, I can prevent inconsistencies in final designs.
Color system, not palette
Colors not only define the look and feel of the entire interface but also communicate visual affordance to users. I wanted to create a color system that allows every restaurant to apply their own color palette instead of just one or two colors.
To achieve that, I decided to created two-level color system: primary color palette and neutral color palette. The primary color palette is made of colors with clear and actionable meanings.
Because I’m designing white-label apps, I shouldn’t and can’t assign specific colors to the primary color palette. Restaurants’ branding colors will be applied to the primary color palette during rollouts.
However, most restaurants’ branding style guides have colors that express the branding in marketing materials but aren’t intended to be used for UI elements. I set up a color contrast test to make sure the rebranded app will be WCAG AA compliant.
If branding colors don’t meet the requirement, I will tweak the hue, saturation, and brightness to come up with a new color which has a better contrast ratio but is still in the same family as the old one.
As opposed to the primary color palette, secondary colors are not associated with a specific purpose. Secondary colors are largely used as background color for pages, cards or sections. To support the increasing demand for both light and dark mode apps, I created two default secondary color palettes: “light” and “dark”.
Every color in the white theme has its corresponding paired color in the dark theme. For example, Light 100 is the background color for light theme. When switching from to the dark theme, simply replace Light 100 with Dark 100.
Components
Components are made of elements and perform a well-defined function in the application.
In my definition, a component can be a button, page title, etc. For example, when a primary CTA button shows up on the screen, it guides users to the desired action.
Using buttons as an example
Buttons allow users to make choices and take actions with a single tap. Depending on the use case, there could be multiple actionable targets in one screen, like a list of salad bowls. There could also be multiple actions users can take per actionable target, like customize a salad or add it as-is to the cart.
Instead of using one button system throughout the entire app, I wanted to create a two-tier button system to serve varying use cases.
When there is only one preferred actionable target on the page, use the primary button system. If there are multiple actionable targets, using primary buttons can be confusing and overwhelming.
Secondary buttons are used when there is more than one actionable target on the screen, such as an item list view showing 2+ items and the interface cannot predict which item is the most common choice.
Unlike other components, buttons have more rebranding concerns. For example, some restaurants want rounded corners and some prefer the modern feeling of sharp corners. I made sure our system could be configured to support the most common needs.
Patterns
Patterns are well-assembled components to support certain features, which promotes logic and consistency across all the products.
Patterns or modules are an especially userful concept for a white-label app. When facing different restaurant menus and customization models, instead of redesigning the entire item detail interface from scratch, we can just change some configuration and keep the rest of the app the same.
In this way, the design system can not only support a more agile product development process for designers but also support more rapid restaurant onboarding for engineers.
