It needs to be stated again that most of these contents come from my daily work logs, which are more like essays, and only represent the work ideas and methods that I personally use when facing a specific product/project/team; there are only specific optimal solutions for things. , not the only answer; I hope to bring you some reference value.
Component Libraries and Design Specifications
I remember seeing an article before, and the analogy is very beautiful – only in terms of the relatively narrow Design System, which is mainly composed of component libraries and design specifications, you can imagine it as IKEA furniture – the component library is in the form of parts The furniture product presented, and the design specification is the instruction manual that guides you through the assembly.
The function and relevance of the two are so clear at a glance; the architecture design of the two has a large degree of commonality. Generally speaking, the architecture system of the component library and the design specification can usually be consistent at the level of smaller granularity; but the design specification will also have its specific goals and scope of action. When it comes to the "design pattern" and other levels, the granularity It often exceeds the scope of the component library, and there is no need to pursue comprehensive consistency at this time.
"Atomic Design" is good
Friends who have relevant experience may know that the initial architectural design of the component library is the most time-consuming and labor-intensive process, especially for large and medium-sized "mature" products, too many functional processes and corresponding composition pages, too much. There are many inconsistencies – what rules are used to sort out reusable components, what granularity is used to divide component levels, and how to ensure that the division method is sufficiently flexible and practical – the advancement process is often cautious and difficult Yes, each step is strictly based on the previous one.
Atom : The most basic and inseparable design element, a unit of IKEA furniture, a Lego brick, etc. It usually includes style elements such as color, text, and grid system, as well as functional interface elements such as icons, buttons, text input boxes, and switches.
Molecules : The smallest reusable unit composed of atoms with independent functionality, such as a search bar containing elements such as text input boxes, placeholder text, and buttons, or a user avatar, username, user Comment b2b data content and like button list cell (Table View Cell) and so on.
Organisms : Informational/functional modules composed of single/multiple types of molecules.
As for "template" and "page", I personally think that it is of little significance to the design of the component library architecture; or "template" can be understood from the perspective of "view", let's discuss this again.
But there will be many problems
However, in many cases, when you plan the architecture of the entire component library with the idea of atomic design, you will often find that the actual situation is by no means so clear-cut and logical ; and the "organism" level, it is often difficult to judge and distinguish.
The first step in sorting out the structure is usually UI inventory, which is a boring and tedious work. You need to integrate the existing typical pages (screenshots or design source files), extract various typical elements, and carry out relatively loose , and judge the general architecture of the component library; typical problems that may be encountered during the period include:
For some ambiguous elements, should they be classified according to similar styles, or should they be differentiated according to function? For example, elements that belong to "Tag" in style, from a functional point of view, some are attribute tags in the true sense, and some are part of the option list; should they be classified into one category at this time?
For most products involving "content", the "molecules" or "organisms" of the content occupy a large part, and their constituent elements are often different in size according to different page environments, including merchants, commodities , comments, content feeds, and more. For these contents, is it necessary to encapsulate them into reusable components, and will it affect the flexibility of actual design after encapsulation? How are they logically different from other "functional" components?
In addition to the main color palette and basic styles, there are often color, text and graphic styles with a single purpose or edge in products. Are these styles necessary to be strictly defined? If defined, how to avoid excessive complexity of style library and component library; if not defined, how to ensure the consistency of these "non-mainstream" elements in the future design process?