AI Design System Creator: A new practice in the AI era with just one click

A well-functioning design system can provide reusable components and shared design guidelines, allowing developers and designers to quickly build new pages or features without having to start from scratch every time. This means that teams can design and develop products more rapidly while ensuring consistency in product quality and user experience. As more and more Internet companies launch their own design systems, a general agreement is that design systems are an advanced and helpful best practice for teams.

Naturally, we believe that such practices should be popularized among product design teams.

With this assumption, I began to research the real-world implementation of design systems among professional designers and their teams. I spent a month interviewing about 15 design teams, but the results were disappointing—many teams did not have a design system. Only design teams in two large “Internet Giants” said that they have had a well-functioning design system.

Although this is widely recognized as a best practice in the industry, its adoption rate is low. With questions in mind, we researched more teams and discovered two main reasons preventing them from building design systems:

• The team doesn't fully understand how important a design system is. When we suggest building a design system, we often face a challenge: convincing everyone to dedicate some effort to building it. Simply explaining the benefits of a design system isn't always enough to show the problems with our current design practices without one. This makes it hard to convince the team to decide to start building one right away. The person proposing the idea may also face tough questions, such as “Even though we don't have a design system now, everything seems to be fine,” or “Our current methods are working well, and the design experience seems consistent.”
• The cost of building a design system is high. Building a design system means going through all our prior design drafts and summarizing them into our team's design guidelines. Just collecting and organizing past design drafts is very time-consuming. For example, the teams we surveyed needed 2-3 designers to spend 2 days just to finish collecting the necessary elements.

A decision to leverage AI for design system creation

As Motiff has explored the use of AI to solve these problems in different design scenarios, we thought about if AI could solve the above two issues:

Regarding how to convince teams to start building a design system, Brad Frost, the author of Atomic Design, once proposed the concept of “Show, don’t tell”. This concept involves collecting the styles and components used in the current application, organizing them into an “interface inventory” to directly “expose” the inconsistencies, rather than just explaining the benefits of a design system.

At this point, it is natural for me to think that perhaps AI could help designers to organize interface inventory, since collecting and organizing are exactly what AI is good at.

The cost problem of building a design system can be broken down into two parts: collection and definition:

• Collection involves extracting elements from the current application that can be turned into styles and components. Like the answer to the first question, the collection is essentially creating an interface inventory. We believe AI can help people with this part of the work.
• Definition involves regroup and eliminate styles and components in the interface inventory, ultimately redefining the styles and components in the design system. This process requires an understanding of design scenarios and business requirements, and it might not be achievable by one person alone. It requires team discussion to reach an agreement. We believe that this part of work can only be finished by humans, AI cannot achieve it.

The interface inventory serves as both a “persuasive tool” for the advocators of the design system and an initial step in helping designers and teams to collect for creating the design system. Based on this analysis, we have set a milestone: Use AI to help designers compile an interface inventory.

How to help AI recognize interface inventory?

Categorization

As discussed earlier, the interface inventory involves organizing and grouping the styles and components found in the current application. To enable AI to compile this interface inventory, we first need to define the categories of styles and components and teach the machine how to categorize them. We draw inspiration not only from the categories outlined in Atomic Design but also from the component categorizations found in various design systems like HIG, Material Design, Fluent, Spectrum, and Ant Design, which include elements like colors, typography, buttons, labels, and more.

It's worth noting that we initially underestimated the difficulty of the categorization task. As we encountered various edge cases, we continuously updated and refined our categorization system.

Re-grouping

Once AI has learned how to categorize, we encountered a new challenge—AI tends to miss certain elements in its recognition attempts. After examining numerous instances of errors, we identified the problem.

Take the example below: in the design drafts, all lists include avatars. However, the recognition results don't always include avatars. The reason is that the avatars are not grouped within the layers of the current list. They are located in a very far place of the layer list. Consequently, AI often overlooks them during recognition. To tackle this issue, we decided to abandon the original layer relationships and first let AI perform the re-grouping process.

After completing the training for categorization and re-grouping, the recognition results provided by AI are mostly acceptable, but:

• In the design files, a significant amount of “redundant design” has been organized into the interface inventory.
• The display of various information in the recognition results is disordered and inefficient.

Even designers who are most familiar with this product cannot determine which components will be used in what scenarios.

Therefore, our next task is to “make the interface inventory more user-friendly”.

How to make the interface inventory more user-friendly?

In the process of developing new features, we continuously optimize the presentation of the interface inventory, hoping that AI can provide designers with more supplementary information to help them make better decisions.

In order to make the AI-generated interface inventory more convenient for designers to use, we started to think about what designers might do after receiving the interface inventory. Along this line of thought, we hope to find answers to two questions:

• How can we display the interface inventory in the most convenient and readable way for designers?
• Which information can best assist designers in making decisions?

The most efficient display

Deduplication

When we initially received the AI recognition results, there were so many of them that they were practically unusable. The issue stemmed from the presence of numerous components with subtle differences. AI would identify the same component as multiple similar candidates due to inconsistencies in text or graphics. But for humans, it's easy to understand that these are essentially the same components that only differ in their content.

To avoid showing ineffective information to designers, we developed a deduplication strategy, such as:

In the example below, AI identified the listed items as 2 separate components because of differences in avatars and text content.

In the figure below, AI identified the dialog boxes as two components by AI because the size of the popup window has changed due to the difference in text content.

Clustering and Layout

We also spent a considerable amount of time optimizing the clustering and layout of components in the interface inventory. Taking color as an example, you will notice many similar colors. Let’s take “red” as an example. It may only need one style in the design system, but 7 different shades of red are identified in reality. To help designers discover redundant design elements more intuitively, our goal in clustering and layout is to group and display similar styles and elements.

Similarity calculation: Initially, we used HSL and HSB color models to calculate the similarity between two colors, but the results were unsatisfactory, which shows significant discrepancies from what our eyes perceive. To address this issue, we began searching for color models that better align with human visual perception, until we met Google’s HCT, for which we are truly grateful.

Cluster quantity: We also encountered the question of “how many rows should the displayed colors be lined up”. It's clear that mechanically arranging them according to hue degrees is not what designers want. During this process, we thought about using the hierarchy cluster algorithm to recalculate the distances between each color, resulting in a clustering method that better aligns with the designers’ understanding.

Assist designers in decision-making

Usage counts

In addition to organizing components and styles into clusters and layouts to assist designers in viewing the interface inventory, we also take “usage counts” into consideration. We use usage counts to assist designers in making decisions.

We have observed that when facing a variety of similar font styles, analyzing their usage counts helps designers identify which styles are being misused since misused styles are not commonly agreed upon and tend to have lower usage counts

In the example below, you can see a significant difference in their usage counts.

Trace back to origins

After discovering that usage counts can help designers identify misused styles, we realized that this data could be combined with a new feature called “Tracing Applications”. Designers can now track where styles and components are being used based on their usage counts, facilitating the process of correcting errors and understanding usage scenarios.

Moreover, another advantage of this feature is when designers encounter a set of very similar buttons, they often find it difficult to determine which ones can be grouped. At this point, understanding the specific usage scenarios becomes a common practice for designers. To better assist designers in understanding usage scenarios, the “Trace back to origins” feature can help designers quickly understand where this element or component is used and can also directly jump to the original file to view the specific design drafts.

Challenges in creating AI design systems

We discussed some of the challenges we overcame while developing the AI Design System Creator feature. Now, let's talk about the issues we haven't solved yet and may be hard to solve in the future.

What is a Checkbox & Radio?

It's easy to distinguish between a Checkbox and a Radio button in a component. Simply put, a Checkbox is for multiple selections and usually has a checkmark when selected, while a Radio button is for single selections and usually has a dot when selected. If you look at the image above, you can quickly identify that the left side is a Checkbox and the right side is a Radio button.

However, in the image below, since they are both in an unselected state, it's hard to accurately determine whether the component will have a checkmark or a dot when selected.

Fortunately, these two components do not appear frequently, so we have decided to group and display them on the same page:

There are numerous examples of similar problems. Every time we are impressed with our seemingly perfect “solution”, we end up being proven wrong repeatedly. Nonetheless, we are still confident that these challenges will be resolved through advancements in datasets and algorithms.

Is the Design System Complete After Creation?

In the content above, I discussed how we optimized the interface inventory in the AI recognition results to help you identify the components or styles that need to be retained and can be reused based on the suggested components or styles.

However, I quickly realized a new problem—what about the remaining design elements? Should they be discarded directly? Should we modify the designs that deviate from the design guidelines?

To answer these questions, I started a new round of research and interviewed more than 10 design teams. During this process, I made an assumption: To ensure design consistency, past design drafts should be replaced.

The research conclusions confirmed my guesses. All teams agreed that the misused elements need to be replaced with the correct styles or components. Since most of the product updates reuse previous design files, if the earlier designs are not corrected, it is challenging for the subsequent designers to realize that the interface is incorrect. A new problem was discovered during the research. Although everyone agrees that replacements should be made, no team actually replaces past design files. The reason for this is quite apparent: it's too much trouble.

During the research, we found that some teams would use KPI requirements to force designers to spend time regularly maintaining elements used in past design files, but this is clearly not an optimal solution. To solve this problem, we designed the AI Replaces Component feature, which has been launched and is available for use.

Meanwhile, from the stakeholder perspective, creating design systems is not solely the responsibility of the design team. Its creation requires consensus with the downstream libraries for developers and participation from all design-related positions in the business team. Once the internal library of the design team is consistent and replaced with suitable styles and components, how should the front-end library for developers be adjusted? We are exploring how to build a bridge for synchronizing libraries between designers and developers, so stay tuned for our new features…

Summary

Returning to the essence of the problem, what we truly focus on is design consistency and efficiency. Throughout this process, we discovered that the design system is a way to achieve this. We firmly believe that the design system is a best practice.

But our goal is not merely to help small and medium-sized teams build a design system, as that alone is not enough. We aim to use AI to transform the design system into a collaborative model between machines and humans. We hope that more teams will be able to realize and improve the application of the design system through this new way of practice, thereby promoting the progress of the whole industry.