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.
Now that you are aware of what I do, let’s examine what you can find in this post:
*Please note that due to my NDA, I will limit using actual image samples in our working files.
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:
Your team should consider building a design system if it is experiencing the following issues:
On the other hand, if you only want to build a DS only because:
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:
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:
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:
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:
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:
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.
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
More from me
Từ UI Designer trở thành Product DesignerProject type
Behind the Scenes of be app RedesignProject type