Component Library Design Guide: The Birth of a Component Library

Editor's Note: How to build a component library? This article summarizes the settings of the component library, the tools needed, and the synchronization methods to help you quickly get started with component library design.

As the company's business continues to grow, componentization not only brings a consistent design language and work efficiency improvement to the business, but also affects and changes the output and collaboration methods of the design team. While designing requirements, the Gtech UED team has gradually developed a set of component libraries suitable for multiple platforms and multiple businesses to improve design and collaboration efficiency, and ultimately achieve a balance between professional value and commercial value. In this series of articles, I will share some of my thoughts and methods in the process of organizing and maintaining Gtech UI Kit (Mob). Today, let's talk about how to take the "first step" in component library design.

1. About the component library

1. The essence of a component is a rule

To some extent, a design system is such a "rule" - a series of design elements such as color matching, text, components, etc. together constitute a standardized system to provide decision-making guidance for designers. As part of the design system, the component library helps designers quickly realize the design of medium/high-fidelity prototypes by summarizing typical styles and encapsulating commonly used components.

Following such "rules" will not only effectively accelerate the design process, but also improve the reusability and consistency of design patterns, making the overall product design solution more scalable and easier to maintain.

2. The significance of continuous maintenance

The component library project is not actually a product delivered after a cycle of hard work, but a product that has been continuously precipitated after a long period of iteration of business needs. Just like running a marathon, it is easy to take the first step from the starting point, but the difficulty is to keep running and eventually reach the finish line. Usually, the timelines of business iteration and component maintenance are not intertwined. Each business iteration cycle will call the current version of the component library as the basic template; similarly, at the end of each iteration cycle, the components or style definitions with high reusability during the period will be updated to the library. Over time, for many needs in daily work projects, you can quickly build pages by easily dragging or making small changes.

To achieve rapid page building, the component library itself needs to meet the "rationality" requirement, including reasonable structure, naming, etc., and these need to be constantly thought about and corrected during the process of organization and maintenance. In the actual process, it is often discovered that it seems more reasonable to encapsulate a component in another structure when it is in the middle of organizing it, so the previous results may need to be overturned or modified; at the same time, the component library should also meet the requirements of reusability and ease of use to meet the needs of daily business. In addition to learning to improve work efficiency by using components, designers also need to try to understand the methods and processes of encapsulation, naming and even maintenance, so that they can use components more easily.

2. Necessary settings

1. Basic style

The component library is composed of components. The style is the basis of component design, which is built from bottom to top through the hierarchy. When making components, templates, and pages, the first thing to do is to fully and meticulously define and maintain the basic style, including color, container, font, layer, etc.

Taking "font" as an example, text is one of the basic elements that constitute interface information and content, whether in the high-fidelity design stage or for interaction designers in the line draft and low-fidelity prototype stage. Different parameters such as color, font size, font weight, etc. are used to construct the overall and local information display of the interface to ensure the hierarchy and breath of the interface content, helping users to better obtain interface information.

For common scenarios of system-level products, Gtech UI Kit (Mob) provides 360 common styles for single text. The naming rules of the styles are based on the explicit attributes of the text, namely "font weight/font size/alignment/color". For example, "Regular/14/1_Left/Grey 6" represents text with regular font weight, size 14, left alignment, and color defined as "Grey6".

Of course, among all these text styles, there may not be many that are used frequently, but we still hope to spend enough time in the early stage to define a unified style sheet that can cope with most usage scenarios, increase the fault tolerance of the component library in the later maintenance, and meet the ease of use of the component library.

2. Component Structure

"Clear structure" is a requirement for component definition and one of the factors to consider in the usability of a component library. If the ultimate goal of a component library is to be open source, then one of the issues that needs to be considered in the initial organization and subsequent maintenance is "universality", that is, exploring a component classification method that is well adapted and understood by most teams and individuals and is easy to index and call. After research and internal discussions, we finally chose to divide the component library into 6 modules based on usage scenarios, and display each typical component in pages. The specific display structure is as follows:

Of course, classification based on component attributes is also a common organizational structure. System-level components such as Apple iOS UI or Google Material Design are divided according to component attributes. Everything is for easier indexing and calling. In design, as long as the goal can be achieved, the most appropriate method to the goal can be selected.

3. Naming conventions

The naming method and rules are also one of the important links in the process of organizing and maintaining the component library. Whether it is the definition of colors, layers, and text styles, or the organization and organization of components, icons, and typical interfaces, unified, universal, and flexible naming rules are the baseline throughout.

As mentioned earlier, components are divided based on usage scenarios, where each category contains several components, such as cells, labels, logos, etc. in the "display" scenario, and each component is composed of several states, parameters, etc.

A well-organized structure has certain requirements for the naming of components. On the one hand, it is necessary to make the maintenance process more orderly and clear, and on the other hand, it is necessary to ensure that the final components are easy to index and call. Usually, in order to reflect the structural hierarchy, we use the "/" symbol in the component naming to separate category scenes, components, states or other parameters (Sketch can automatically recognize the "/" symbol and use it as a category separation mark to organize layer by layer, and finally form a complete directory structure), such as the following figure "Display/Label/Circular Label/Small Label" and so on. As long as the user knows what kind of component he needs when calling, he can easily index it layer by layer.

Just like component structure, there is no set of so-called "most correct" rules for naming. The most correct rule is to fully discuss it within the team and reach a consensus on it after it conforms to the usage habits of most people.

3. Tools and Synchronization

1. Plugin recommendation

"If you want to do your work well, you must first sharpen your tools." As the content of work continues to expand, many operations are often difficult and cumbersome for designers to implement manually. In the Sketch community, there are not only many designers, but also an active developer community. Developers have provided many excellent plug-ins, which have improved the functions of Sketch from different angles and improved the work efficiency of designers. When organizing and maintaining components, I usually use the following two plug-ins:

Find and Replace Text is used to find and replace text content in the entire Sketch file of the selected layer, artboard, page setting - whether it is the actual text content in the layer or the text name in the layer list; in the process of trying out naming rules, we will use this plug-in to batch modify the text style names presented in the basic style definition.

Styles Generator is used to automatically define text and layer styles in batches. After determining the naming rules and completing the initial style or font property settings, select all sample objects and execute "Generate Shared Styles". Sketch will automatically generate corresponding Styles based on the layer names of the objects you selected, without any manual naming process.

2. Collaborative solutions

As mentioned earlier, the organization and maintenance of the component library is a work that is constantly updated with business needs. Timely iteration and optimization can make the components better meet the needs of the current project. Internally, we think about the existing problems and try to find an optimal way to make the team easily and efficiently collaborate.

Finally, we decided to move the component maintenance workflow to the cloud, that is, to conduct design collaboration in the cloud. Simply put, this way of working is to put the component library Sketch file in the cloud, and through the capabilities of the cloud account, everyone can share and use this file at the same time. The file will contain design specifications, components, typical pages, etc. Designers can directly call these contents when working. The specific operations are as follows:

1. Share the component library Sketch file with team designers via iCloud (you can set corresponding editing and viewing permissions according to the needs of the team);
2. The component library file will appear in the cloud drive of the friends who shared it, and can be added to the Sketch Library;
3. That is, you can reference components in project files through Symbol;
4. Whenever a component is updated within the team, a "Library Update" push will appear in the upper right corner. Just select the updated component.

4. It’s not just about designers

I believe that many people have also tried to sort out a set of standard component specifications, hoping to improve design efficiency and ensure consistent output. However, in actual work, there are some problems: in addition to using components by yourself or the design team, it seems that the front-end page does not achieve the effect of componentization, and different developers still rewrite the code for each component, which is inefficient and the visual restoration is relatively poor.

The main reason for this situation is that coding is not implemented at the development level, and the component is just a design draft, not a real callable "building block".

Therefore, maintaining components is not just up to designers, but developers should also be one of the main participants. Both parties need to communicate, proofread, and continuously develop and maintain (many collaborative processes are omitted here. In fact, team scheduling coordination is a very important factor). In the end, what we output should be a set of visual products and the implementation code behind them, which can truly achieve the goal of dragging components to build interfaces at the code level.

summary

In this article, we mainly discussed some common problems about "how to design a component library", such as the necessary settings for organizing and maintaining the component library, recommendations for plug-ins and collaboration solutions, and component coding, etc. We hope that it will bring some thoughts and help to your work.