Problem Statement
Pepper's cross-platform B2C product relies on three different systems: web, Android, and iOS. Each framework is built on top of the baseline framework.
These are parts of the Pepper Design System, a collection of artifacts such as UI kits, code snippets, and documentation consumed by cross-functional product teams to build new features and shape the experience of 25 million Pepper community members worldwide.
The Pepper Design System has evolved over the years thanks to the significant and continuous efforts of many developers and designers. However, we are at a point in design history where design systems have gained the spotlight. We want to think meaningfully about the impact of our choices (both code-wise and design-wise) and adopt a more holistic approach to building and maintaining digital products.
The following case study is an example of a design system project, and it doesn´t reflect exactly the Pepper workflow I was part of during my past experience. I intentionally omitted some details that should not reduce your ability to evaluate my skills in the matter of Design System Design.
The challenge
Tokens are the smallest unit of design systems. They store design decisions that are consumed by components. Each platform of the Pepper Design System relies on a different system of tokens connected to the baseline frameworks.
Working with each platform requires a different understanding of color tokens and how they function. Unfortunately, this lengthens the learning curve for new joiners and slows down communication between designers and developers. Designers need to work separately with each dedicated team of developers assigned as the referent for their own platform.
We wish to speed up the onboarding process and allow the product teams to work more independently in creating new components, while keeping the design team review mandatory.
All images of case study are for illustrative purpose
My Role
• Audit the current state of the design library tokens and documentthem.
• Compare the repository with the design library tokens.
• Draft an initial token structure with the Design System manager.
• Share the new token structure.
One to rule them all
I researched and took references from the web relevant to my job. Resources such as MD3, Figma variants, and articles by Oppermann and Curtis helped me determine the structure for organizing the current Pepper Design System tokens.
I also studied the token structures of some of the most famous design systems: IBM Carbon, Adobe Spectrum, Atlassian, and Salesforce Lightning.
The Design System manager and I reviewed my draft together and agreed on the first version to present to the product designers and developers in charge of each platform. This will allow us to collect their feedback and address any unforeseen issues.
1lv - Core Tokens:
These are the base colors of our system, serving as the primitive values used to generate the color palette consumed by other token levels. Whenever we need to introduce a new color to the system, we choose the value that ensures the highest range of accessibility for the entire interface.
2lv - Global Tokens:
The color palette is not intended for use by designers and developers. Instead, they should rely solely on semantic tokens when creating or refactoring components.
3lv - Semantic Tokens:
Before implementing these, we created a glossary that allows everyone using the semantic tokens to deeply understand their meaning. Designers and developers work mainly with this kind of token when maintaining and creating components. They are divided into:
Theme Tokens:
These allow us to easily switch between the three Pepper themes used to build the Pepper platform worldwide. Examples of components consuming this type of token are CTAs that highlight the main action of the component or screen. What distinguishes this token type from the other categories is that the HEX code generally doesn’t change, and their purpose is to safeguard the brand.
Component Tokens:
hese are assigned specifically to the rest of the interface. They can be identified as parts of the rest of the UI, such as background and dividers.
4lv - Platform Tokens:
These are specific to their platform. Since they differ by the type of baseline framework, manipulating some specific tokens can become awkward. Therefore, we place them on a separate level, especially since the different modes exist on apps but not on the web.
5lv States:
Not all tokens are eligible for this level, but we see it as a necessary addition, specifically for all interactive elements of the interfaces.
The result
The proposal underwent several rounds of feedback and changes before the gradual implementation began. Like almost every design system project, it was planned with a different time frame for the full release to fit the product team's pipeline. However, developers and designers can work quickly thanks to the new color token structure.
Learnings
Semantic Tokens for Consistency
Utilizing semantic tokens ensures consistency and clarity across multi-brand, cross-platform systems, simplifying the creation and maintenance of components by providing a uniform understanding of design elements.
Platform and State-Specific Tokens
Differentiating tokens by platform and state addresses unique requirements and behaviors, enabling a tailored approach that ensures responsive and dynamic user experiences while maintaining overall design integrity.
