Master three steps to create a collaborative component library from scratch

As mentioned in previous articles, design components are the most basic and practical part of a design system. They bring many benefits and look cool. However, to create a successful collaborative component library, you need not only strong professional skills, but more importantly, you need to understand its significance to the company or team, and build it based on the current situation to maximize its cost-effectiveness.

[[424020]]

Step 1: Identify the value of creating components based on actual situations

From a designer's perspective, component libraries can be divided into three levels from small to large based on the breadth of coverage:

• Component libraries created for design reuse in a single project
• Component libraries created for design reuse between multiple projects

A component library created for cross-functional reuse between multiple projects, which can form a component library of the final product with a small amount of customization.

The first level of component library is to solve the problem of reuse within a single project, while also ensuring the design uniformity of the entire project. If there are multiple designers under the same project, a unified standard is even more necessary to ensure the interaction and visual consistency of each page, and the component library can be said to be the embodiment of this standard. Different designers use the same component, which can effectively ensure the consistency of the page and improve work efficiency.

So, is it necessary to create a component library at this time? I'm afraid not necessarily. If the project needs to be quickly developed and launched for verification, and the subsequent development route is also vague, then sacrificing some consistency, tolerating the relative differences between different pages, or using rough methods such as copying and pasting to achieve the goal may be more cost-effective.

The value of the second level component library lies in maintaining uniformity among multiple projects and freeing designers from repetitive work. This value has a premise, that is, these projects need to maintain consistency.

The third level of component library is to improve efficiency more widely. It has jumped out of the scope of designers and has been linked with other professions, covering R&D technology and even more professionals. It is also called business components. Although it is very attractive to not have to redesign or redevelop the same module, can the design of these components be recognized by the user? Is the original supported technology stack consistent with the needs of the user? Can the cost of learning and promoting these components get the same return? Are the relevant company processes, rules and resources convenient for learning, promoting and using components? These are all issues that need to be considered.

These three levels of component libraries are progressive, and each level sounds more attractive, but the more energy it consumes.

The best companies, such as Google, Microsoft, Apple, and Alibaba, have also made similar arrangements in their businesses, such as opening up to a wide range of developers to form an ecological platform. At this time, components empower the outside world and are no longer limited to the company. The value they bring is far greater than the energy they consume.

But as a new component library, we first need to confirm whether to create a component based on our actual situation, rather than just because it has a good reputation. Not creating a component library or using a third-party component library is an option. It is not about creating a component library for the sake of creating a component library. When it is confirmed that this component library is still worth creating in the current actual situation, we need to make this value more concrete and make it a feasible goal.

Step 2: Learn from OKR thinking and create a goal system that suits the actual situation

In my second year at the company, I started creating components based on the three B-side products I was involved in.

Each B-end product is actually a system, a platform + application structure, with data and information running between the two. Although it looks huge, first of all, these three product systems are based on a unified product value (AR technology) to map to different application scenarios (remote video, inspection, exhibition display). Secondly, in terms of human resources, the product, R&D and design managers of the three systems all belong to the same team with the same team priorities. In addition, although the primary and secondary divisions of labor are different, the same product manager or designer will be involved in the definition of the three product lines at the same time.

Therefore, when building the component library, I directly extracted the same functional modules of the three product lines and provided functional modules composed of multiple pages and multiple interactive logics. I did not specifically list the buttons, prompts, pop-up windows, etc. that most component libraries on the market would include. I only marked the modules that had special interactive instructions on the AR glasses.

Perhaps because it happened to be in line with the actual situation, the R&D team formed two modules, login and home page list, without spending much effort on promotion. The login module has been used until now.

However, as the exploration period deepened, the business scenarios of product docking expanded rapidly, coupled with the adjustment of architecture, company layout, and organizational mission, it soon became impossible to connect the components of the third level at once. Although I later made some adjustments to this phenomenon, the results were not obvious. I had always believed that the main reason was insufficient time and energy. It was not until the organizational design team completed a workshop that I realized that the lack of practical goals in connection with the actual situation might be the main problem with little effect.

What is the actual situation now?

In my organization, the three departments are responsible for 1-3 business lines respectively. Each business line corresponds to different user scenarios and product requirements. It is necessary to quickly prove the value of its business line to the company with actual performance and financial income. Therefore, even if I can see the possibility of reuse between different businesses, it is difficult to directly form the third-level components as before.

At this time, we can learn from the OKR thinking, set more substantive KR goals, and then iterate the component library like a product to ensure that each iteration is critical and effective.

For example, I think that the component library created should reach the third level to achieve the best value based on the current situation, so this can be set to O. The setting of this O is guided by the strategy and needs to be aligned with the goals of the company or department, which is the value we clarified in the first step.

Next, we design sub-goals, which are the key results in OKR, measurable key results, starting from the end, to form the goal system of this component library.

In my example, we can divide it into two categories based on the different user groups: one is useful for designers, and the other is useful for collaborative departments. Taking an annual cycle, we can form two key results:

• A set of Sketch component libraries used across projects, covering 50% of the project's interface design workload;
• A set of component design definition documents and resources used across projects, allowing corresponding functions to enter the development phase directly.

If we further break it down, we can also split the annual cycle into quarterly cycles or even monthly cycles, set a smaller OKR goal system, and track and review the results in a more timely manner.

Step 3: Focus on relevant competing products and set the component library content based on actual conditions

Because our projects are almost all To B business lines, each product, regardless of size, is a system, that is, information is transmitted between the front end and the back end, and users include at least 2 or more professional roles. The simplest is 1 Web platform + 1 AR terminal application, so to achieve the previous 2 key results, this component library needs to support at least 2 terminals from the beginning.

At the beginning, since we almost exclusively promoted our self-developed AR glasses as application terminals, when designing the component classification, I chose to list the components first, and then distinguish the terminals under each component.

This format is similar to the component library of Material design, which is derived from one terminal to other platforms. In the directory, you will first see the component list, and then see the platforms supported by each component.

But soon, this promotion model was changed. In addition to AR glasses, robots, edge algorithm boxes, industrial PDAs, cameras with CV modules, etc. were incorporated into different business lines to form a solution that is more suitable for the scene. Although they all revolve around computer vision as the core technology, they are very different in the performance of the interface layer.

At this time, I still organized the component library in the same way as before. As a result, when using it, I have to look through the long directory of each component before I can find the corresponding terminal resources I need.

Source: Company internal component introduction page

After organizing that workshop, I began to extensively research other excellent component libraries in the industry. In fact, most excellent component libraries have corresponding clear, single terminals, such as Ant components corresponding to web terminals, Hololens components corresponding to AR glasses, and even Apple, a cross-platform multi-device manufacturer, has output different component libraries for mobile devices, TV devices, and watches.

For various reasons, I upgraded the terminal classification from the second-level directory to the first level, and the Sketch components used by designers were also divided into separate files according to the terminal. Then, based on the current business situation, I focused on two main terminals: Web pages and AR glasses.

With a focused endpoint, when drawing on other component libraries, it is possible to narrow the scope based on previous extensive research and obtain more meaningful results.

For example, for AR glasses terminals, the designs of Windows Hololens and Magic Leap are more meaningful as references than Material Design.

Source: Magic Leap Design & Windows Hololens

Even though it has reference value, since the actual situations faced by each component library are different, corresponding changes still need to be made when generating the component library.

Take the AR glasses UI kit I created here as an example. Because it will eventually fall into various projects of different business lines, it is difficult to unify the customers and scenarios. Therefore, the color tone is not required as a condition that must be met when generating the component library. If you want to ensure consistency, the layer styles in Sketch and even color variables can be put into the component library as a solution.

Source: Company internal Sketch page

Excellent design skills and professional capabilities are essential to building an excellent component library, but I believe that an excellent component library must first be a practical component library. While being attracted by its halo, it must closely follow the actual situation of the current environment, be determined and changed according to the time, and not be limited by its own professional perspective. Only in this way can it bring the value it should bring to the team or company.

Adjusting according to the actual situation is easy to say but the most difficult thing to do, because it is like the soil of the component library. When the soil changes, the above must also change. These three steps are to first confirm that there is such a piece of soil for it to grow, then analyze the nutrients that the soil can provide to the component library now and in the future, and finally, to start working and let the component library bloom and bear fruit on this soil.

Because the soil is different, the component library generated by the same method may be completely different, but it does not prevent it from becoming a good component library to facilitate collaboration and improve efficiency.