How to Build a Design System with Business Characteristics
Introduction Universality and business customization seem to be a contradiction in the process of building the design…
Universality and business customization seem to be a contradiction in the process of building the design system. Ideal design system is a sustainable design system that can be mutually beneficial and win-win according to the development of business.
When talking about design systems, what comes to your mind? components? Methodology? Or a page template?
In the book Design System by Alla Kholmatova, the author defines a design system as follows:
A design system is a set of interconnected patterns and shared practices coherently organized to serve the purpose of a digital product. Patterns are the repeating elements that we combine to create an interface: things like user flows, interactions, buttons, text fields, icons, colors, typography, microcopy. Practices are how we choose to create, capture, share and use those patterns, particularly when working in a team.
1. What does a good design system look like?
At present, in terms of design system, many teams have explored their own style. For example, let’s take a look at IBM’s carbon design system.
Carbon Design mainly forms a complete design system from five aspects: guideline, components, patterns, community assets, and data visualization. According to the definition of “Design System”, we can classify guideline, components, and patterns as “model”; Instead, community assets and data visualization are classified as “practice.”
In the guideline part, carbon design stipulates the basic color, motion, icon, content, pictograms and other specifications. Although these rules are not specific components, they can control the tone of the overall design system, which is equivalent to laying a solid foundation for the whole system. The dynamic effect part is easy to be ignored by many people, but it can really reflect the overall sense of detail and delicacy.
We should all be familiar with the component part. Usually, the component constitutes the element with the minimum functional granularity of the page, and forms a set of detailed and comprehensive reusable component assets with the interaction specification.
The pattern part is a core highlight of Carbon Design. Each “pattern” has an overview, theoretical source, usage method, case derivation, etc., rather than simply defining the style. It can be seen that IBM has been deeply cultivating in the B2B markets for many years. , has summed up a set of both theoretical and practical asset library, very rigorous and scientific.
Community assets can only be used by employees, so I can’t show you the specific content, but it can be guessed that this part should be the shared resource of different businesses of IBM, and this resource is maintained and reviewed by specific people to ensure the iteration and update of shared assets.
Visual charts. As a separate field, carbon design integrates and enumerates it separately.
Of course, in addition to IBM’s Carbon Design, there are many excellent design systems, such as Alibaba’s Ant Design, Atlassian’s Atlassian Design, Microsoft’s Microsoft Design, Google’s Material Design, SAP’s Fiori Design, etc. We will not list them all here. .
2. How to effectively organize design assets
In the chemical world, all objects are composed of atoms, atoms combine to form molecules, molecules combine to form organic matter, and finally form all things in the universe.
In 2013, front-end engineer Brad Frost proposed atomic design theory in the article “Atomic Design” and applied this theory to interface design. It is said that he was inspired by chemistry, atoms are combined together to form molecules ( , further combined with the formed organisms, according to his theory, the design system mainly contains 5 levels: atoms, molecules, organisms, templates, pages.
Last year, the Pixel design system has accumulated many basic components and general rules, so when defining how to use this design system, we try to reorganize and classify all the design assets currently in hand to facilitate other Designers or developers understand.
We found that Brad Frost’s atomic design theory is helpful for the material classification of the design system itself, so we tried to classify the design materials according to the following ideas:
Atom: the most basic element of the design system.
Such as: color card, font size, icon, fillet, spacing and other basic rules.
Organization: a block composed of basic components.
For example: list block, form block, data filtering block and detail block.
Template: A page template composed of blocks.
Such as: details page, list page, form page, exception page.
Page: scenario case with business logic.
Such as resource management scenario, message notification scenario and permission management scenario.
In this way, we can effectively classify all design assets according to the granularity from small to large. Designers can easily design with building blocks.
At the same time, front-end engineers can also make all assets online according to this set of asset specifications. While reducing repetitive development, it also ensures the unity of the design style and interaction of the entire team, and avoids the differences caused by the “personal habits” of different designers and engineers.
3. Establish a design system that belongs to business characteristics.
In the above step, we have uniformly classified and sorted all the designed materials. We once thought that with these materials and general rules, designers can scientifically use this design system for cooperation.
But after a period of actual implementation, we still found some problems:
If a novice designer uses the above assets in strict accordance with the rules, he will develop the habit of finding cases to apply from the asset library. Of course, this is not a problem in most daily business, but once encountering special business scenarios, or some innovations If the functional requirements are not met, designers will fall into the inertial thinking of “there is no such case in our design system”.
At the same time, due to the hierarchical structure of atoms- molecules-organisms -pages, it relies too much on rational “building” thinking, and loses the “perceptual” advantage as a designer, which is easy to cause all pages to be the same without highlights.
Corinna also mentioned the limitations of atomic design when it comes to the ground in the article “why our pattern library no longer uses atomic design” published in 2018. He mentioned that excessive reliance on layer by layer progressive relationship will make the whole system extremely complex and difficult to maintain. Once it is used, the cost of subsequent iteration and reconstruction will be very high.
So we began to ask ourselves, what is our original intention to solve when we spend energy on designing the system?
In fact, it is essentially to solve the pain points of the business team:
- Meet the rapid development and iteration of business.
- Quickly respond to different needs of different users.
- Reduce the design and development of a large number of repetitive pages and improve efficiency.
- Help the business to make more highlights and innovations and enhance the competitiveness of the business.
- The design system can work in parallel in multiple teams and will not be affected by each other.
Our current design system can meet the pain points of 1–3, but to solve 4 and 5, we still need to optimize the original design system to make it more suitable for business attributes.
If we compare our design system to a restaurant, we now have the raw materials for cooking and the use methods of raw materials, and we have also made several home dishes. What we need to do later is to use the existing materials to develop new recipes according to the tastes of different guests.
In order to adapt to different products and businesses, our current Pixel design system is mainly divided into PAAS and SaaS product fields under a set of basic component system. In the two product fields, different business fields are subdivided according to business characteristics, users and product forms, so as to ensure that you can switch different themes and retain your own business characteristics under a set of basic system specifications.
How can we help the business to make more highlights and innovations and enhance its competitiveness?
In the monitoring operation and maintenance business domain, according to the business attributes of the business platform, we divide this business into three directions of “Monitor”, “manage” and “control”. Each direction has different business objectives and users. Through research and analysis, we try to define a keyword for each direction.
- The goal of monitoring platform is to monitor the operation of business at all times. The keyword is [visual];
- The core goal of the application operation and maintenance platform is to flexibly handle a large number of change actions. The key words are [efficiency];
- The core of security engineering platform is to ensure the safety and stability of business and personnel action. The key word is [security].
Then, focusing on “visual”, we optimized some of the original traditional “list -details” pages into several visualization scenarios, respectively corresponding to the monitoring, choreography and operation and maintenance scenarios of different processes, and visually displayed the underlying business logic, link architecture or workflow.
So we defined the “atomic components” of choreography, and on this basis, we defined different states and styles, as well as which styles support customization and which styles need to comply with specifications. Through the splitting of business scenarios, we obtained the following “choreography scene library”. Based on this scene library, when we encounter similar scenes later, designers will no longer struggle and need to apply them from fixed recipes, It is more from the perspective of designers to consider how to create more “recipes” based on this library.
Similarly, we have also obtained topology scenario library and advanced operation scenario library, which are basically refined, summarized and split based on business characteristics.
So how to couple these scenarios with the previous design system?
We tried another classification method and divided four quadrants with the two axes of “general-business” and “case-rule”, and summarized the experience in business through regularized, case-based, and documented Forms fall into these four quadrants. In this way, a design system with both versatility and business characteristics is obtained.
In this design system with business attributes, it is not only limited to “design materials” and “design rules”, but also adds rules or materials with business characteristics such as “collaboration process” and “business model”. The division of the four quadrants enables novice designers to understand the business design system in an all-round way. While ensuring the unity of design, they can also carry out secondary innovation based on the business, thereby ensuring the continuous iteration and innovation of the design system.
The above is my thinking in actually exploring the construction of design system. In the process of building design system, universality and business customization seem to be a contradiction all the time.
Our ideal design system is neither a set of templates that only consider universality, nor a set of personalized skin for thousands of people, but a sustainable design system that can be mutually beneficial and win-win according to the development of business. In this process, there are bound to be more ups and downs waiting for us to face. Designers with more similar experience are welcome to communicate with us.
Alibaba TXD Team | Pixel Design System
Recommendation of Related Axure Products
We made this library for both mobile and desktop prototyping. It also includes common backend templates. Using templates, you can quickly build the backend system.
· Designed strictly according to the Ant Design System.
· Included most official .components and templates
· A large number of widgets and templates.