One design system for multiple brands
GMO Pepabo, Inc. is a Japanese company offering various services with different brands for each. We’re developing our own design system which aims to put effort more on meaningful design rather than trivial works. To support multiple brands with a single design system, we fully utilize the concept of design tokens, overriding common components with brand specific styles. Figma is the key tool to realize this concept and in this session, we will be sharing our experience with you.
This is a transcription of my presentation at #Config2022 .
Are you having trouble with a design system for multiple brands?
Is your company having trouble with a mixture of different brand design systems? My company was very troubled by this problem…
GMO Pepabo have about 400 employees and provide services under a total of 8 brands, including Suzuri, Minne, Lolipop!
This is a service called Suzuri that I am in charge of.
Suzuri is an online marketplace for print-on-demand products.
The touch points, which represent Suzuri brand, are to stimulate creativity of individual creators.
For example, this is a landing pages introducing Suzuri’s items.
The poster and acrylic block page gives a transparent and geometric impression.
The coach jacket page has a cool, street-conscious look.
In this way, the same brand has several pages with different tastes for different products.
Also, this is Suzuri’s YouTube advertising.
This pop animation features manga artist and illustrator Keiichi Arai, who uses Suzuri.
On the other hand, this is another service we offer, Minne.
Minne is a handmade marketplace where you can sell and buy handmade works online.
The touchpoints, which represent the Minne brand, express the warmth of handmade products.
For example, this is an event held by Minne.
The use of wood in the venue decor and also the visuals are very organic.
Also, this is a TV advetising for Minne.
In contrast to Suzuri’s pop animation, this advertising uses live action. This is designed to evoke a realistic image of handmade works in daily life.
Finally, this is the corporate brand of GMO Pepabo, Inc. itself.
Our Corporate Philosophy is Make it more playful and our Mission is Using the Internet to deliver new possibilities.
While it has a certain pop impression, it has a firm impression because of the many touch points for shareholders and investors.
For example, this is an IR.
A geometric pattern combining the logo, logotype, and visual pattern is used.
The corporate brand is also reflected in internal applications and portal sites.
In addition, our services are available on a wide variety of platforms including iOS, Android, and the Web.
It is not supported now, but perhaps VR and TV will be supported in the future. And there may be more and more platforms that are unknown now.
When you hear it this way, you may think that this session is not relevant to you because you do not have multiple brands.
However, that is not true.
Have you ever had a requirement for a single brand to change color, shape, etc. for a project or campaign?
In addition, adaptations to user-set environments, such as dark modes and dark themes, are already beginning to become popular.
There is a need for more aggressive personalization, such as Material You, which Google announced last year.
Even for those who do not have multiple brands in this regard, dealing with multiple themes is no stranger.
We were faced with the challenge of how to efficiently create design value in these situations.
Design system? What does Design system mean to us?
Once again, Design system? What does it mean to us?
We define a design system as not only a component library, but also includes the following
- Esthetic Patterns
- Functional Patterns
- Design Principles
- Style Guide
- Design Tokens
Design tokens are the smallest unit of color, typography, and other design systems. It is used to create a consistent style that is available in all environments.
Design tokens is the most key to dealing with a multi-brand design system.
Design tokens represent the brand and are replaceable.
What is the relationship between a brand and a design system?
We believe that a design system is one way to implement a brand. A brand has an experience that fits its worldview. Branding is about sharing that with users and potential customers. The design system is the means to realize this through the product.
Comparison of multiple vs. single design system operations
I would like to remind you again that our company has 8 brands. We were wondering whether we should create multiple design systems for each brand or a single design system for multiple brands. We’ve listed the pros and cons.
First, we present the pros and cons of operating multiple design systems.
Pros
- Fully optimizable to suite with each brand
- Can be edited at any time
- Can be started on small scale
Cons
- Take cost per brands
- Lack of common understanding
The following are the pros and cons of operating a single design system.
Pros
- Can consolidate costs
- Fixes and improves applied at once
- Common understanding
Cons
- No enough room of brand optimization
- Need to be applied and deployed to each services
- Presize synchronization is required
As this comparison shows, the pros and cons of each are inversely related. No absolute choice.
Which one to choose depends on the number of brands you handle and the balance of design resources you can spend on them. We have 8 brands and only 40 designers, so the number of people we can spend on each brand is 5.
If this seems sufficient, you could operate multiple design systems. But if design resources don’t satisfy each brands, you may chose single design system way.
We decided to operate a single foundational design system
We decided that the number of brands we were handling did not balance well with the design resources we could spend on them, so we decided to operate a single foundational design system.
GMO Pepabo Inc. calls this single foundational design system “Inhouse”.
The common infrastructure design system is a generalization of the principles and guidelines that each brand considers individually and duplicates in the assets it had implemented, so that they can be used by all services.
We do not have a rule against making anything that does not follow the design system. By generalizing what is duplicated and already has an optimal solution, we can focus our efforts on more meaningful design.
As I mentioned earlier, we use design tokens for multiple brands to use our design system.
Design tokens that can be overridden by different brands, such as colors and shapes, are grouped into variables, and design tokens can be replaced to create a design suitable for the brand.
In addition, in order to make it easy to override the design tokens of various brands, the Inhouse itself is not unique, and the principle is to create a plain, ordinary prototype.
Based on this concept, we first created a prototype of the component.
We will then brush up the structure so that this prototype can be deployed for multiple brands.
At this time, key and value are simultaneously extracted from the visual design to construct the design token. Now we have a set of components based on design tokens.
How we build our process to realize the concept
How we build our process to realize the concept? Figma was the best tool to achieve this.
Figma has these good points.
- Easy to share with multiple teams
- Easy to update components
- Good plug-in architecture
- API is available and easy to use from code
With this in mind, we decided to use Figma to design our design system.
We also recommend using the Figma Tokens plugin to handle design tokens in Figma.
You can easily override design token. Also, since you can sync with GitHub, tokens are easier to handle from your code.
In addition, we use the Style Dictionary to bridge design tokens to each platform.
Style Dictionary formats design tokens defined in JSON or YAML for easy use on various platforms.
Here is our build system using these tools.
This is the kind of build system configuration that is often seen with Figma as the starting point.
First, based on the components designed in Figma, the design tokens can be overridden by the Figma Tokens plug-in. Next, from Figma Tokens, design tokens are exported and formatted for ease of use on each platform with the Style Dictionary. Finally, formatted design tokens are made available for each platform, including Sass, SwiftUI, Jetpack Compose, and Flutter.
This configuration is often designed with the idea that the visual created by the UI designer in Figma is completely synchronized with the code.
However, our build system is structured a little differently, with meaning as the starting point.
First, we prepare a YAML file describing the design tokens for each brand. It is not important that this be in YAML, but rather that the meaning be defined at the beginning. Next, the prepared YAML file is formatted for ease of use on each platform using the Style Dictionary. Finally, the design tokens are formatted for ease of use in Sass, SwiftUI, Jetpack Compose, Flutter, and Figma.
Why meanings should come first?
What we valued in the composition of this build system was was to bring meaning first. Why meanings should come first?
For example, suppose we have buttons with these roles. Button A has a positive meaning, and button B has a negative meaning.
For example, if all the buttons were colored black in a cool brand representation, these buttons could look exactly the same.
If a UI designer creates a visual first based on appearance without correctly designing semantic keys and values, the output code will be the same. However, you will want to treat them as semantically different buttons.
If you are aware of the meaning first and design the keys and values correctly, you are less likely to worry about components being used with the wrong intentions.
For this reason, we consciously take the step of first designing the meaning correctly and then creating the visuals.
Demo
Many of you may be wondering how we actually operate here, so we will show you a demonstration using an actual Figma project.
Our Figma project is organized like this. Within the GMO Pepabo Inc. project, there is a group of files called Inhouse, each of which is divided into separate files for each component.
We used to manage all components in a single file, but as the number of components grew, we began to experience performance problems, so we split the files into separate files for each component. Also, the user can import only the components that are necessary, so there is no need to load unnecessary components. In addition, the split components are easier to access from the code.
Let’s take a look at the actual file. The page is divided into two main sections: Cover and Components. As you know, the Cover manages the images that are displayed as thumbnails when files are listed. A common cover component, prepared separately as Style Guide Assets, is used here. This cover component is also used in other component files.
The cover shows the name of the component and also indicates whether the component is currently available or in the process of being edited. And because it is difficult to recognize which component is which if only textual information is displayed in the thumbnail, a preview is displayed on the left side to show the appearance of the component.
Next is Components. Components are defined here with various variations. In this case, we have prepared a simple Button component for demonstration purposes. The background color of the Button is different for Neutral, Negative, and Interactive. Neutral is a button for general use, Negative is a button for negative actions such as deletion, and Interactive is a button for interactive actions such as linking. These color variations are determined by design tokens, which refer to tokens defined in the code using Figma Tokens.
Now let’s look at the design token defined on the code side. The YAML value that defines the color of this Button contains a reference to a semantic color such as Neutral as an alias.
In addition, the YAML file for the semantic color contains a reference to an atomic color such as blue as an alias.
The YAML file containing the tokens of a color such as gray contains the actual color values in rgba.
In this way, the color tokens have a three-level hierarchical structure: gray and other colors, semantic colors with defined meanings such as Neutral, and component colors.
Suppose I want to make a stylish UI as a brand requirement, so I don’t use a lot of colors, and I want to change the Interactive semantic colors to gray. So I change all Interactive semantic colors to gray.
I commit the change and push it to GitHub.
Now back to Figma. Sync the changes you just pushed to GitHub with Figma Tokens. Then, when I update, the changes I just made are applied to the components of Figma.
As you can see, Neutral and Interactive have the same appearance but are interpreted as different meanings because the meaning is first defined in the code.
Summary
Once again, here is a summary of this session.
There are many things that need variation, not just brands, such as campaigns, dark mode and Material You.
The meaning is defined not only by looking at or creating the resulting surface layer, but also by understanding its structure. In other words, correctly defining the keys and values of a design token is the essence of design.
As Paul Rand said, “Design is a relationship between form and content.”.
Each of our brands may look disparate, but in fact, they all have a common underlying thought. By using the common types in one design system, the expression may look different, but it always delivers the same thought.
Thank you for watching!
