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.

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.

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

Consistent

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. 

Scalable

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.

Reusable

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.