Jul 1, 2022 13 min read Design System

Why do we need a Design System？

The designers are no longer fixated on relatively concrete issues like how to set standards or how to write documentation. Instead, they are thinking more deeply from perspectives such as design engineering, business value, and cross-team collaboration.

In October 2018, I published my first article about design systems in my Chinese column. It was my first quarter I establishing the Design Center department at Alibaba Group. As one of the three major directions of the department, we had already supported almost all the Internal and External Management System within the group (except Ant Financial) with Fusion Design.

In the summer of 2019, I conducted a workshop on design systems at Alibaba UCAN (now renamed U Design Week). I chatted with designers from different companies for over 3 hours. At that time, some of them had already started to consider how to leverage the design systems for design delivery.

At that stage, most were still in the exploratory phase of theory and practice, primarily focusing on experience consistency when thinking about building design systems.

Fast forward nearly 4 years, the environment has changed, and our understanding of design has evolved. It's time to upgrade the "reference guide." A recent survey in our reader group revealed significant shifts in companies' attention and investment in design systems.

Nearly 70% of designers' teams have completed or are building a design system, with 40% of teams involving both designers and front-end engineers.Over 90% of companies hope to enhance the overall design and development efficiency through design systems.

After leaving Alibaba, I no longer wish to continue the routine life of working for another company. I hope to have more leisure time to experience different aspects of life. The writing seems to be the most suitable activity for my current state. It also allows me to share my experiences and reflections from my years at Alibaba. The "Construction and Application of Design Systems" is one of the essential topics among them.

How to start？

I left an open-ended question in the survey, wanting to find out what people are most concerned about regarding the topic of design systems. The results are thought-provoking.

What does a complete design system look like?
How do you define a design system for specific industries or businesses?
To what extent should a design system be developed? How much business volume should it cover to be considered sufficient?
What size of team requires a design system? Are there differences in how different types of companies approach design systems?
How do you view the constraints of a design system versus the demand for innovation?
How do you achieve design consensus across teams?
How do you measure the value of a design system?
With so many open-source design systems available in the market, what are their differences?
How do you ensure the implementation of a design system? Are there specific processes and methods?
There are many ideas and approaches before starting a design system, but there are also many discrepancies during the construction process. What techniques and strategies can be referenced?
How do you validate that the system you've designed and built is currently the most effective approach?
......

You'll find the designers are no longer fixated on relatively concrete issues like how to set standards or how to write documentation. Instead, they are thinking more deeply from perspectives such as design engineering, business value, and cross-team collaboration. These are also the areas where I've felt the most profound insights in recent years while implementing various business projects within the group.

Therefore, in the reboot of this design system column, I will first spend some time sharing stories of building design systems at Alibaba, discussing the underlying thoughts and decision-making logic. Let's first align our understanding on this "fundamental groundwork," so our subsequent discussions will flow more smoothly.

In this first article, we will start with "Why" and discuss the reasons for establishing a design system.

The Current State of Design Systems in China

Before diving into the "Why," I'd like to first review the current state of design systems in the internet product design field with everyone. Just like in the previous UCAN workshop, we'll categorize design systems into three levels: System-level, Industry-level, and Product-level.

System-level

As the name suggests, it refers to design systems at the operating system level. The main ones we encounter in our daily lives are provided by Apple, Google, and Microsoft.

In fact, we can "simplify" this concept. Comparing them to mini-programs on platforms like Alipay or WeChat. After years of operation, Alipay and WeChat have accumulated a massive user base and traffic. As a result, many businesses (or developers) hope to join these platforms to provide services to users and reap corresponding benefits.

To offer users consistent and high-quality services and user experiences, Alipay and WeChat provide businesses (or developers) with a comprehensive set of design guidelines and development frameworks. This also aids in enhancing the development efficiency of mini-programs and reducing the implementation costs of products. In return, businesses (or developers) strive to adhere to these rules to gain better business support and collaboration.

Due to their system-level positioning, they need to serve products with a vast range of types. Therefore, the definitions of these design systems are more "fundamental" and place greater emphasis on defining a design worldview. This is also why they tend to simulate and replicate the real world more extensively.

Compared to the other two categories, there aren't many at the system level. After all, their emergence is based on a few major mainstream operating systems, and most of the design systems we participate in are built upon these giants. Given the current market landscape, the chances of a sudden emergence of another major player are slim. Therefore, as designers, we only need to maintain our focus on the aforementioned three companies.

Industry-level

Compared to the system-level, industry-level design systems are more focused on general scenarios specific to a certain industry. For example, IBM's Carbon Design, Alibaba's Fusion Design, Ant Financial's Ant Design, ByteDance's Semi Design and Arco Design, and Tencent's TDesign. Btw, most of these design systems are open-source.

PC 官网 - 首页

Fusion Design is an enterprise-level solution for building web products by improving designer-developer collaboration, product experience consistency, and development efficiency.

首页

If you are familiar with the names mentioned above, you'll notice that they primarily target enterprise-level application scenarios, or what we often refer to as Internal and External Management System scenarios.

The reason for this clustering phenomenon is that those scenarios are currently the most suitable for abstraction and achieving consensus between the product and user sides.

By "consensus" here, I don't mean that it's simple or that the design requirements are low. Instead, in enterprise-level scenarios, efficiency, consistency, and simplicity are the core design principles of every design system. The goal is to allow users to complete their current tasks more effectively and effortlessly. The value of design systems can be well validated and reflected in this context.

Some of you might remember the Christmas controversy of Ant Design at the end of 2018. It caused quite a stir on the internet both domestically and internationally, and some even lost their jobs over it. This incident shows how many users and products the small team behind Ant Design has silently served.

Why are most industry-level scenarios enterprise-level scenarios? Can't other scenarios be developed?

Frankly speaking, in theory, it's definitely feasible. However, in practice, there are significant challenges at present. Over a year ago, in our design committee, we proposed an initiative to establish a comprehensive Alibaba design language. The aim was to articulate Alibaba's design clearly and, based on that, extend it to design systems for various sectors like e-commerce, logistics, transportation, finance, entertainment, and enterprise-level applications.

After spending more than half a year, we completed the foundational design language for Alibaba. However, when we reached the domain level, we paused. We realized that, apart from enterprise-level applications, it's challenging to reach a genuine consensus in other domains at the moment. Regardless of the domain, the business attributes currently far outweigh the domain attributes. Therefore, at this time, these domains are more likely to exist in the form of business-level design systems, serving their respective businesses.

Product-level

The product-level is aimed at serving a specific product or business. Examples from the industry include well-known systems like Lighting Design and Fiori Design, as well as the design systems many of you are currently working on within your companies.

SAP Design – SAP User Experience Community

SAP User Experience Community

https://www.lightningdesignsystem.com

These types of design systems have one thing in common: they are essentially defined based on secondary processing of system-level or industry-level design systems. The scope of such design systems is very broad. What needs to be done is to define based on the characteristics of this domain, combined with business features, to help enterprises quickly conduct business and provide services within the corresponding ecosystem.

For example, in 2016, I devoted the entire team's energy to the design system of AliExpress. We defined AliExpress's design system based on the system-level specifications of iOS and Android. The most time-consuming part was finding a balance, adhering to system-level standards while defining the unique design philosophy and approach specific to the e-commerce domain for this product.

Although we seemingly effortlessly received the Google Editors' Choice in the end, the extensive communication and time spent with Google's design and development teams behind the scenes might be beyond what most can imagine. Indeed, a genuine business-level design system is often straightforward because its primary premise is to address actual business problems.

What problems should a design system solve?

Let's briefly review these three types of design systems here.

Reflections on the Evolution of Design System Thinking.

The changes in thinking we're discussing here aren't just from the perspective of designers, but more from the company's viewpoint on how they perceive design systems and the value they offer.

In the past, when we talked about design systems, it was often designers and front-end developers exploring more advanced business production models based on their understanding and interests. Many company managers understood it as ensuring design consistency and enhancing design experience. However, in terms of cost reduction and efficiency improvement, especially on the engineering side, we didn't see particularly significant value outcomes.

Shift in Business Perspective
In recent years, with the gradual fading of the internet dividend and the impact of the Covid-19, both costs and returns have faced significant challenges. Even major internet companies no longer allow endless "trial and error."

Over a year ago, Alibaba also gradually began to implement a business responsibility system for each team, forcing everyone to seriously consider each resource investment.

While many have complaints, I believe, from a macro perspective, that this is the right move. It also pushes team managers to operate their teams through more scientific and efficient work modes, eliminating waste.

At this moment, due to the nature of the business, some enterprise-level products, from stakeholders to managers, began to re-examine the value that design systems can bring. Those who have a clear understanding have started early and have already seen significant benefits.

The logic behind this isn't complicated. Let me give you an example: The core delivery of a certain business unit's CTO line is various mid-tier systems, which can be calculated in terms of the number of pages from a macro perspective.

Cost per page = Average hourly wage x Delivery time for a single page.

Here, two variables affecting cost are provided: either reduce the hourly wage or reduce the delivery time for a single page. But for enterprises, especially during challenging times, they often need to tackle both. The average hourly wage is not within our control, but the delivery time for a single page offers a lot that designers and developers can work on.

The investment and output value of a design system can be clearly calculated. As long as the plan is reasonably formulated, there's a high probability that the ROI will meet expectations.

Shift in the Product Development Perspective

Returning to the previous discussion about the design system survey, you'll notice the emergence of product managers. The design system is no longer just a task for designers and developers; product managers also need to participate and help set the rules.

16% of the respondents indicated that the participants in the team's design system include designers, front-end developers, and product managers.

Why should product managers be involved? From the perspective of the design system, designers and front-end developers define the interface interaction mode to solve a certain type of problem. In contrast, the daily work of a product manager is to create instances to address specific business process issues.

Imagine a scenario where a product manager is writing a PRD like this:

This is a new product registration system.

Module 1: Registration and LoginModule 2: Registration FormSubmodule 1: User Identity VerificationSubmodule 2: Merchant Qualification VerificationSubmodule 3: ...Module 3: Registration ManagementModule 4: Product Management

Behind each module and submodule, besides defining the interaction patterns, there's a need for defining the business logic from a product perspective.

A good product-level design system should allow product managers to focus on the business process itself without worrying about specific buttons or pop-ups. As the creator of the design system, you also don't need to get entangled in the business details all the time; instead, focus on abstracting and defining business patterns.

We once attempted this in a business targeting merchants, but it failed... We can discuss this case in detail in the future.

Of course, creating such patterns is not an easy task. It first requires consensus among designers, front-end engineers, and product managers:

We need more than just guidelines; we need more deterministic "constraints" that encapsulate the consensus for use.
Unless necessary, we should fearlessly pursue "design innovation" with a priority to effectively solve problems.
If changes are needed for established rules, don't modify instances. Submit requirements to the encapsulated modules.

Why do we need a Design System

After discussing all of this, let's summarize why design systems are essential:

Boosting Business Productivity: In today's digital landscape with diminishing internet dividends, business production models need to change to help companies maintain profits.
Returning to Business Essence: Gradually abstract and encapsulate business modules, allowing products to focus on the essence of business logic.
Unified "Business Language": Establish a shared business language encompassing business, product, design, and technology to enhance team communication efficiency.
Enhancing Consistency of Experience: Let the design system team concentrate on the system itself, optimizing and unifying the user experience, reducing user usage costs.
Advanced Collaboration Models: Introducing a design system to optimize production collaboration models in the business production process.
Enhancing Team Combat Capability: Help new members or ecosystem partners integrate more quickly, enhancing overall productivity.

The demands of the design system for talent

I manage a design center department with only three full-time designers dedicated to design system work. Alibaba has hundreds of design teams and thousands of designers supporting various businesses, but dedicated teams for this work have been scarce. However, in recent years, several design teams have established teams or groups related to design systems, but finding such talent remains challenging. It took me three years to recruit a design system architect from IBM's Carbon Design team, and most other relevant designers on our team learned while working on it.

In the period before I prepared to leave, a headhunter approached me and mentioned that ByteDance's Feishu (Lark) was opening a high-end position for a design system and planning to invest heavily in it, with a team that had already grown to over 10 people. Recently, Tencent's TDesign and ByteDance's TikTok have also opened positions related to design systems, but the headhunters still complain about the difficulty of finding suitable candidates.

Indeed, design systems are still a relatively niche topic in the design field. Even among those who have been paying attention to design systems, it's a very small part of the millions of designers in China. However, the environment is always changing, especially in the internet industry. The evolution of roles in user experience design (such as experience architects and product designers) has been gradually emerging over the past three years. It's gratifying to see that design systems are becoming more and more important in everyone's teams and companies, and those who are already involved will enter the next important stage earlier than others.

Let's stay motivated! 💪🏻

If you are interesting in Design System, maybe you can take a look at this article. I'll talk about the use of design systems in ai design.