How we build Design System for a multi-service app

This post is dedicated to my design team @be, whose members have always been resourceful, inspiring, and funny colleagues to me. 

Here, I simply want to reflect on my personal experience in building and maintaining the 2nd version of our Design System. But before we dive into the details, let’s take a look at what kind of job I did at be. These specific little things will help you understand how they influence the way I led my team to build the system.

  • I was a Product Designer at be, a company that aims to provide multiple on-demand services such as ride-hailing, logistics, food delivery, and payment...
  • All of these services exist within 1 single mobile app so they shared many design elements and user flows;
  • be Design Team has 6 designers, each of them in charge of a product vertical. However, all of them came together to assist me in building our DS, to which I am eternally grateful.

Now that you are aware of what I do, let’s examine what you can find in this post:

  • What is a Design System?
  • When is a Design System necessary?
  • How to build a Design System? 
  • How do we measure the success of a Design System?

*Please note that due to my NDA, I will limit using actual image samples in our working files. 

What is a Design System?

Simply put, a Design System contains all design elements and basic components that designers use regularly throughout the product design process and specifies the guidelines for using them.

In order to understand a DS deeper, I often compare them to a Core Team of a company:

  • There are many different departments in a company and each of them has its own key members, who make up the company’s Core Team. 
    -> Similarly, among all design elements, there will be some with a higher level of reusability. As they serve as the foundation to build other elements or components, they are created and maintained in a Design System.

  • A Core Team’s members come from many different teams in a company. They are often managers or key members of their associated team. Their mission in a Core Team is to learn about the vision, direction, and long-term strategy of the company, and communicate this information back to other team members. This helps make sure everyone is on the same page so that they can work towards a common goal.
    -> In a DS, core design elements come from the design of many different product verticals. However, they need to carry the basic features of the overall product to keep the design language of the app consistent as well as streamline the design and development process;
  • A Core Team often has a periodical meeting to update every member on the company’s new direction and conduct performance reviews.
    -> A Design System will also need periodical reviews so that all design team members can assess its quality and impact, and update it regularly based on new product changes. A designer will need to evaluate which component to keep and which component to remove to ensure that the DS successfully adapts to the product’s constantly changing requirements.

When should we build a Design System?

Your team should consider building a design system if it is experiencing the following issues:

  • Too many design debts: One-off solutions built only to serve one use case cannot serve many different scenarios that occur when users interact with your product. In those cases, new solutions are born, which makes it hard to maintain a consistent design language and organized UI structure;
  • Too many designers in a team and each one of them sticks with his or her style. This leads to the inconsistency between design elements and patterns, even when they are built to support common features;
  • The developer teams are at a loss of what to follow in the design files. They are unaware of how to utilize the design specs, colors, text styles, spacing because no guide is provided.
  • ...

On the other hand, if you only want to build a DS only because:

  • Everyone is doing the same thing ;
  • This scope of works sounds fancy so that it will look good on your resume;
  • You hear from the grapevine that fellow designers from other companies are working on their own DS and want to jump on the same thing;

Then it’s a NO. Building and maintaining a DS requires much time, effort, and lots of human resources. Maintaining is even more difficult than building. Take it seriously or else you will fail from the get-go.

How to build a Design System?

1. Decide on key criteria

Before starting on crafting our DS, the team had a meeting to align with each other on what criteria a DS should follow:

  • Consistent
  • Scalable
  • Reusable
  • Base elements only


This is pretty self-explanatory, so I won’t deep dive into it much. A DS is born to help maintain a cohesive system of visual and behavioral patterns for a product. It should serve as a single source of truth for members across different teams so that they can speak a shared design language. 


The DS you build today is not a temporary project that gets stuck in the present. If it is strong enough, it can last for the next several years or even longer. Even when you don’t know how your product will change in the future, you will still need to take into accounts how the components may change in the near future, or which new elements will show up so that you can reserve some spaces for them. This is why it’s essential to consult other teams, especially those with deep involvements in the product development process (PM, PO, Developers). They can provide you with product roadmaps, missions, and visions so that you can start planning ahead with your DS.


Before creating a new component, you should explore some readily available elements upon which you can use. With this careful research, you don’t have to waste your efforts in building things anew, which saves you and developers a great deal of time.

Base elements only

New members in a Core Team need to meet certain criteria determined by a company’s high-level executives. Similarly, when putting a new element into a Design System, our team decided that it would need to meet some basic criteria. This is significant as it keeps your DS from being fragmented and messy, especially when it is built by different members in a team.
Here is an example of ours:

  • The design element has been used repeatedly on at least 2 services, and 2-3 times on each service. These are the numbers that we set ourselves but they are not fixed. With #be products, elements with these characteristics are repeated frequently;
  • For elements that do not meet the above criteria, the PIC Designer for each project will need to input them as Local Components on each Figma file. 

2. Communicate your DS with cross-functional teams

Our team hosted a kick-off meeting that invited other designers, developers, product managers, product owners, and the QA team, to talk about our plan. Here’s why:

  • Developers are those directly responsible to translate your DS into an actual product so they need to stay informed of the whole project;
  • PM and PO are those who manage the development process and control its final output’s quality. Building a DS requires much resource and time so they will need to be aware of its scope for proper planning;
  • QA are those who test and evaluate a product’s quality before launch so they also need to know about the design guidelines and updates.

In some big companies that provided large-scale and established products, building a DS will be quite an investment in both time and human resources. Thus, sometimes you will need to report to executive levels (CTO, CEO) about what you are going to do. It is recommended that you host a kickoff meeting in which you can explain the necessity and benefit of a DS, and propose a tentative development timeline for it.

When you start building your DS, most designers in your team should get involved. As each of them is in charge of a service within your product, they can help you create components that have high reusability. After you have successfully built it, maintaining a DS requires fewer designers.

Tips: Too many designers in a single DS project will make your outcome a mess. Only involve a necessary number of designers as you deem fit, and explain the scope of work for each of them clearly. 

3. Let’s get on it!

When building the DS, my team members were working on other projects simultaneously. Thus, in order to enhance their focus and commitment to this project, we decided to schedule one or two 2-hour co-creating sessions per week so that we could sit down together and contribute to our library. This process worked perfectly for us.

Each session often went like this: First, each design would inspect their own design work to add elements or components that had been recycled many times to a shared Figma document called “Design Inspection.” This step helped us recognize repeated patterns in our work and assess which elements would be the most valuable when being added to our DS. It also provided us with a comprehensive look into our design across different services, which was extremely beneficial to building our DS.


In the article Design System by Mr. Viet Anh, currently a Staff Design Engineer at Uber and a respected figure in the Vietnamese product and UX design community, he mentioned a story that impressed me a lot

In the article Design System by Mr. Viet Anh, currently a Staff Design Engineer at Uber and a respected figure in the Vietnamese product and UX design community, he mentioned a story that impressed me a lot:

Once upon a day, a startup employs an excellent lead designer. Every project has to pass through her in order to have its design reviewed based on strict standards. One day, while she was walking on the road, she was too busy looking at her phone when a bus hit her. She had to be hospitalized for three months. When she came back to work, she was shocked that while she was away, everyone claimed to be her disciple and thought his or her designs were the right ones. All product designs in the company turned into a mess, which was the danger of keeping all knowledge inside one’s head. The moral of the story: Every lesson must be put into words. 

I wholeheartedly agree with this statement. Almost everybody finds documentation a daunting task, and so do I. However, my intensive experience in working with a DS has taught me that it is a must-do thing that can solve these burning questions:

  • How would designers who are responsible for the DS transfer their work to new designers in case they quit the project?
  • How would the developers and other parties in the organization know the usage and impact of each component?

My team tried to document our guide and explanation as much as we could. We often use Material Design for our main source of reference and document directly on our Figma files (We had used Confluence for documentation before, but we simply didn’t find it working that well for DS). For each component, my team tried to specify the following factors:

  • What: What is this component?
  • Why: Why do we need it?
  • How: How should we use it?
  • Specs

An example of how we set up the guidelines and rules for each component. There were a lot more, but these examples should be enough for you to get the gist.

Measuring a Design System’s impact and success 

Whenever you create a product, you need to know how it can make impacts and how to improve it. Try sending out a mini-survey that aims to ask other designers and developers for their opinions after using your Design System for a while. Building and maintaining a Design System is an endless progress (unless your product is no longer available - brutal as it sounds) that requires you to keep an eye on constant changes, updates, and innovations.

Hanoi, Jan 31st, 2020