Building Rapido’s Design System-Part1

Implementing a consistent UX pattern across an app to which multiple teams are contributing is a challenge. That’s where design systems are our best friends, and the best design system starts small and grows with the project. In this article, we will walk you through our journey in building a Design system at Rapido

Why do we need a Design System?

Let’s take the above example of buttons in Rapido’s current system.

Do you see what's wrong with the above design:

• The design is not consistent across the app
• Designing multiple buttons across a variety of styles would be more time-consuming.
• Not scalable, as a small change in the buttons would require a modification in all the buttons

Let’s See How We Can Solve These Problems

Consistency: UI components will be created in the design system and used throughout the app, which maintains design consistency.

Time-Saving: On average, we saw that our developer productivity went up by 40%. The biggest advantage is that the developers don’t have to worry about styling the components anymore. They can use it and be assured that it will match the design's specifications.

Scalable: Let’s face it, your designs are going to change irrespective of whether you like it or not🙈.
Having a design system makes our lives easy. Take an example where we want to change the color of all the buttons across the app, this now becomes a single-line change in the design system and all components reflect the new color 😎.

Testing: Wouldn’t it be great if you could verify the UI components independently and have confidence that they would work perfectly fine across the app. You can test the components once at a design system level and everything else would work seamlessly.

Design Tokens

Let’s say we have a dark yellow color #FFCA20 that we use throughout the app for different components like brand-color = #FFCA20, button-primary = #FFCA20, border-primary= #FFCA20, etc,

If the design team comes back and asks to tweak this yellow color to a slightly lighter shade of yellow #FFD966 across the app🤔

We now have to go to all the places where we have used the original dark yellow color and change its value to the newer lighter shade of yellow. Hence making it more tedious and time-consuming work.

That’s where the Design Tokens play an important role in building a Design System.

Design tokens are kind of Nicknames to be used in place of actual values. As you can see in the above image yellow color is nicknamed rapido-brand.

Alright, we assigned a nickname to the brand color, but how does It help us?

Now if the designers want to change the brand-color, we just have to make a single change in our Design system and it reflects across the app😎.

Types Of Tokens

Tokens are mainly classified as,

Global/Core tokens: Global tokens are the primitive values in our design language, represented by context-agnostic names. The color palette, animation, typography, and dimension values are all recorded as global tokens. These can be directly used, and are inherited by all other token types.

Alias/Semantic tokens: Alias tokens relate to a specific context or abstraction. Aliases help communicate the intended purpose of a token and are effective when a value with a single intent will appear in multiple places.

Component tokens: Component-specific tokens are an exhaustive representation of every value associated with a component. They often inherit from alias tokens but are named in a way that allows engineering teams to be as specific as possible in applying tokens in component development.

Naming Convention For Tokens

As the design system is a single source of truth for designers, engineers, product managers, etc, each team might name the tokens differently which will cause ambiguity. So it is very important to define a naming convention for the tokens before you start.

Design tokens do not have a standard principle for naming, so everyone can define it as per their needs. Let us take a look at a few examples of how some well-known organizations name their design tokens,

References are taken from Bloomberg, Salesforce, Orbit, Morningstar, Infor, and Adobe

At Rapido, we wanted to have a naming convention that is more readable, flexible, and could easily evolve and support all types of tokens.

After referring to multiple naming conventions, we ended up creating the below naming convention which supports our requirements.

System -> Component -> Context ->  Type ->  Sub-type  -> State -> Property

System: System refers to the brand name or the organization name, such as mds(Morningstar), spectrum(Adobe), rds(Rapido), etc.

Component: Button, List, Text-field, List, Radiobutton, Checkbox, Card, Switch, etc.

Context: This is rarely used, but exists when a particular set of elements on a business/user critical screen exist with different attributes. Example, login, home, fair estimate, support, payment, etc

Type: Outlined, Filled, Compact, Standard, etc

Sub-type: Warning, Positive, Negative, etc

State: Active, In-Active, Hover, Focused, Disabled, Clickable, etc

Property: Typography, Color, Spacing, Border, etc

Now, Let’s define our Button tokens using this naming convention,

Consider the two types of buttons above, Primary and Secondary. Each button has active and disabled states in addition to properties such as typography, borderWidth, border-radius, borderColor, backgroundColor, iconColor, and labelColor.

Designers and engineers together decide the tokens required for the buttons as per the usage and define them in the Figma Tokens plugin. This Figma token plugin generates the JSON for the specified tokens, as shown below,

"RdsButton":{
  "primary": {
    "active": {
      "label": {
        "typography": "RdsTextType.BodySmall",
        "color": "RdsColors.Palette.gray900"
      },
      "background": {
        "color": "RdsColors.Palette.yellow400"
      },
      "border": {
        "color": "RdsColors.Palette.transparent",
        "borderWidth": "RdsBorderWidth.1dp",
        "borderRadius": "RdsBorderRadius.full"
      }
    },
    "disabled": {
      "label": {
        "typography": "RdsTextType.BodySmall",
        "color": "RdsColors.Palette.gray400"
      },
      "background": {
        "color": "RdsColors.Palette.gray100"
      },
      "border": {
        "color": "RdsColors.Palette.transparent",
        "borderWidth": "RdsBorderWidth.1dp",
        "borderRadius": "RdsBorderRadius.full"
      }
    }
  },
  "secondary": {
    "active": {
      
    },
    "disabled": {
      
    }
   }
  }
}

Now, we have a format that we can export and use directly in our code to build design system components, which we will cover in the next part of this article.

Do you use Design System at your work? How has your experience been?
Let us know in the comments below.

Acknowledgements

This couldn’t have been possible without the help and support of Gandharva Kumar, Puneet Setia, Adnan A M and Jai Dev.
Huge thanks to the incredible folks of the Android team and Design team at Rapido