Timeline: December 2019 – November 2020
Role: Product Designer
Field: UI/UX, Design System, Component Library
时间：2019 年 12 月 – 2020 年 11 月
A well-developed component library was important for creating product interfaces in our multi-person team
When I joined SmartX in 2018, there were only 2 product designers on the product design team. It was relatively easy to keep the design consistent because the product structure and style was already relatively well established, and when creating new designs, it was easy to extract or derive the appropriate style elements from the existing interface, so we could reach consensus for each decision through a quick discussion.
2018 年我加入 SmartX 时，产品设计团队只有 2 名产品设计师。保持设计的一致性相对容易，因为当时的产品结构和风格已经较为完善，在创建新的设计时，我们很容易从已有的界面提取或推导相应的风格要素，因此可以通过快速的讨论来达成一致。
After 2 years, we started creating a new product called CloudTower and exploring a new look. This meant that the style that had been established in the old product would no longer work; and by this time the team had grown, with 4 designers working on this new product, each at a different stage of their career development.
2 年后，我们开始创建一个全新的名为 CloudTower 的产品，并探索全新的外观。这意味着旧产品中已经确定的风格将无法继续使用；而此时团队已经成长，有 4 名设计师参与到这个新产品中，每位设计师的职业发展阶段各不相同。
Therefore, it became especially important in our team to maintain consistency in interface style through a well-developed design system, so that we could deliver a familiar experience to users.
Create the design system when the software features were not fully defined and the visual style was not fully confirmed
I tried to create the component library in the early phase of development. This work was handled simultaneously with the interfaces design work, and these two works were handled by different designers. So this phase 1 was fraught with uncertainty. The team wanted to quickly use the design system to ensure consistency in the interface style. However, the specific functional scenes that support the design decisions of the design system were not clear yet, and the interface style was also unclear. The design system created in this context relied more on theory and assumptions about the interface.
It has been proven that designing a component library separately from specific interfaces not only leads to poorer results, but also makes the design decisions of the component library and interfaces tied to each other and reduce efficiency. On the other hand, there were designers at different stages of career development in the team, and their working habits varied, which could also affect the final effect of the design system component library.
In the second phase of the development process, I learned from my experience and started over: incorporating feedback from internal trials and lessons learned about the software interface and design system, redesigning CloudTower’s interface style, and reorganizing and creating the design system.
在研发的后期，我汲取了经验，并着手重新开始：结合研发过程中内部试用的反馈，以及总结出的关于软件界面和设计系统的设计经验，重新设计 CloudTower 的界面风格，以及重新梳理并创建了新的 Design System。
The Detour Taken at Phase 1
Without considering the actual scenario and user needs, the form limited the function
When we first started working on CloudTower, we had just moved from Sketch to Figma because of the benefits it offered to help increase productivity. We decided to make the components and all the associated instructions available in one place, and it was open to all designers and front-end developers.
刚开始研发 CloudTower 时，我们刚从 Sketch 转移到 Figma，因为它的优势能帮助提升工作效率。我们决定在一处提供组件及所有相关说明，它面向所有设计师和前端开发团队。
Figma’s functional features bring a lot of convenience to the team. However, as the component library became operational and expanded, this centralized solution raised some questions about the efficiency of its creation and use.
- When working with components, different designers have different habits. Experienced designers are used to searching the library and finding the assets they need from the tree catalog because they are familiar with the component types and functions, and searching helps them choose quickly, while junior designers are used to opening the Figma component file to find and copy components, which is not as fast as searching but seems more intuitive. However, the experience of both approaches was not optimal. For example, search results were also redundant and sometimes it was not possible to see the required components at a glance, and designers who looked for components in the file often needed to spend extra effort to select the available components or were guided to see content that was not relevant to the design purpose (e.g. component descriptions for front-end development).
- 使用组件时，不同设计师的习惯不同。富有经验的设计师习惯于搜索 Library 并从树状目录中找到所需资产，因为他们对组件类型和功能非常熟悉，搜索有助于快速选用；而初级设计师则习惯打开 Figma 组件文档寻找并复制，虽然它不如搜索快速，但看起来更加直观。可是，这两种方式的体验并非最佳，例如搜索结果也存在冗余，有时无法一眼看到所需组件；而在文档中寻找组件的设计师，往往需要耗费额外精力，甄选可使用的组件，或被引导查看与设计用途不相关的内容（例如面向前端开发的组件说明）。
- Each component was written in a document-like structure, including purpose, appearance, composition, interaction, etc. Sometimes I would consider the presentation of the documentation and forwent the use of “atomic components” because it really didn’t matter to the designers using the component, or to the front-end developers. This was an example of a trade-off between “structural soundness” and “ease of maintenance”. In fact, this did not allow the component library to perform optimally.
- Although I took advantage of Figma’s style feature, I was often unable to execute it during the design process when I wanted to adjust the colors and components as a whole, because multiple adjustments might interfere with the work being done by other colleagues.
- 虽然利用了 Figma 的样式功能，但在设计过程中想要整体性地调整颜色和组件时，却往往不会执行，因为多次调整可能会影响其他同事正在进行的工作。
In addition, designing components individually can lead to a lack of overall coherence, limiting the appearance. This situation also affects the user’s sense of accomplishment in design work and confidence in product performance.
The end result was that a nominal design system and component library was created, but it was disconnected from the final scenario and the user’s situation, and bound by rules and regulations that limited the final appearance. This was a situation that “form limited function” and led to human going to work for the system.
Analyze the Problem
Think about the relationship between the system and the user first, then consider the implementation method
In addition to improving production skills, these problems need to be solved based on an accurate understanding of the core part of the design system — the “components”.
After the first phase of experimentation and listening to feedback, I have learned that what we call “components” are divided into many “layers”, such as the expression layer, implementation layer, and usage layer of component design, component development, and component usage. These “layers” actually address different audiences, segments, and goals. When the content is brief, this variability can seem to be bridged; when the content becomes more detailed, it is necessary to ease this variability, meet the diverse needs, and make the information clearer. Providing all the information in one place slows down the efficiency of different actors to get the information they need from it.
At the beginning, “component” was a vague concept full of multiple semantics. With a clear analysis, it was clear where the problem laid: a single centralized file structure could not meet the needs of a complex and mature design system, and the needs of users with multiple roles. We were initially attracted to Figma’s flexibility when we tried it out, but it proved that taking full advantage of this flexibility required careful consideration in order to maximize its value.
而一开始，“组件”是充满多重语义的模糊概念。现在，通过清晰的梳理，我们可以明确问题所在：单一集中式的文档结构无法适应一个复杂而成熟的 Design System 的需求，无法满足多种角色的用户的需求。起初我们试用 Figma 时被它的灵活性吸引，但实践证明，要充分利用这种灵活性，就必须经过审慎的考量，才能最大程度地发挥它的价值。
In fact, this is to a certain extent in line with the laws of natural and social development. In the early days of infrastructure development, more attention was paid to the commonality of the framework, and individual needs were not yet clearly reflected at this point. However, as more and more different types of users join and use it more deeply, optimization of local efficiency becomes important, and the framework must further support the diversity of needs.
For us, the type of users of the design system was relatively fixed, and we had more reason to take that into account from the beginning.
Emphasized the “human” experience by defining the design system as “a product that provides services”
The CloudTower Design System would be repositioned as a “product” and would serve our internal team.
CloudTower Design System 将被重新定位为一个“产品”，并由此向内部团队提供服务。
From the first phase of experience, it needs to provide the best experience for different usage scenes for users in different roles. For example, designers should be able to have the most intuitive experience possible when viewing and searching for components in a tree list of assets, quickly discover the desired target when browsing components in a document, front-end developers can more easily view design descriptions, and so on. It’s important to note that the designers who design and create components are also one of the users of this system, and it’s our goal to be able to create and organize components more efficiently.
Phase 2, Redesign
Returned to the scene and stayed close to the user to enhance flexibility without losing reasonableness
During the second phase of development, the design system was given the opportunity to be redesigned as the CloudTower user interface was re-styled.
随着研发后期对 CloudTower 用户界面风格的重新设计，Design System 也获得了重新设计的机会。
This round of redesign was based on a proven user interface design solution, so the components gained a look that better supported the overall appearance. In addition to this, I have enhanced its performance in several ways across the board.
Reorganized the structure of the design system
Planned the content composition of the design system in relation to user types and user needs. This approach helps improve overall efficiency, with each type of user seeing only the content they need and using it in the way they are most accustomed and preferred.
Benefit from the reorganization of content composition, the efficiency of creation, maintenance and usage could be improved. For example:
- In UI Library, it is possible to abstract the same features of a bunch of components and create atomic components, and then create instances with the Override feature. This file allows you to focus on the production of the component without having to divert your efforts to the documentation layout of the component description. This approach helps improve the efficiency of production and post-maintenance.
- 在 UI Library 中，可以抽象一众组件的同一特征，并创建原子组件，然后再以 Override 创建实例。这个文档可以专注于组件的制作，而无需将精力分散在组件描述的文档排版上。这个方式帮助提升制作和后期维护的效率。
- Design Templates can provide examples of the most common states of a component, laid out by category to enhance ease of discovery. This way, users are not distracted by irrelevant information and the rhythm of interface design work is not interrupted. Also, by copying components from here, the current state and functionality of the component can be maintained, and if the same component is upgraded, a new component can be placed here (instead of being modified from the original), thus avoiding the impact on other designs. This approach helps to improve the efficiency of use.
- Design Templates 可以提供组件最为常用的 states 的实例，并按类别布局，提升易发现性。这样使用者就不会被无关的信息干扰，保护界面设计工作的节奏不被打断。并且，从此处复制使用的组件，能保持当时的状态和功能，倘若同一组件升级了版本，可以在此放置全新制作的组件（而非在原来基础上修改），从而避免对其他设计稿造成影响。这个方式帮助提升使用的效率。
- UI Guidelines can decouple design guidelines from component descriptions and focus on their distinct guideline uses.
- UI Guidelines 可以将设计指南从组件描述中解藕出来，专注其鲜明的指南用途。
- UI Development Documents enable developers to obtain a definitive version of content related only to front-end development.
- UI Development Documents 可以令研发获得仅与前端开发相关的、确定版本的内容。
Took advantage of the latest Figma features
充分利用 Figma 的最新特性
Take advantage of Figma’s latest features to improve the way design components are made and organized, enhance the efficiency of creation and use, and improve the appearance of performance.
利用 Figma 的最新特性，改进设计组件的制作和组织方式，提升创建和使用效率，以及提升外观表现。
- With the Variants feature, different states of a single component can become variants of that component with the help of multidimensional property declarations. When these states are grouped together, they can be displayed as a single component in the search results, making them easier to find. This feature helps improve the efficiency of use.
- 利用 Variants 特性，单一组件的不同 states 可以借助多维度的属性声明，成为该组件的变体。当这些 states 归集在一起，它们就能在搜索结果中展示为单一组件，从而更容易被发现。同时，组件被拽入后也能进一步调节到所需的 state。这个特性帮助提升使用效率。
- With the new Auto Layout feature, CSS-like flex layouts can be implemented to achieve component structures that were previously difficult to make. This feature helps to improve the appearance.
- 利用新版 Auto Layout 特性，可以实现类似 CSS 的 flex 布局的表现，从而实现原先难以做出的组件结构。这个特性帮助提升外观表现。
Improved production skills
- Build a logical and convenient organization structure by considering the experience of final search and variants selecting. For example:
- The placement of component variants affects the component instances displayed in the search results. Placing the default state component in the top left position of all variant combinations can improve the recognition of search results.
- The properties of component variants need to be set with both the sequential relationship between properties and ease of use in mind.
- The hierarchy of components requires a balance between rational organization and ease of use. While we often rely on search, we should also get a good experience when expanding the tree diagram to find it.
- 组件变体的排列位置，会影响搜索结果中展示的组件实例。将 default 状态的组件放在所有变体组合的左上位置，可以提升搜索结果的辨识度。
- Hide components that will not be used individually, such as atomic components and subcomponents within complex functional components. If a user can search for a component that he will never use, then the asset list and search results become complex and may be less efficient to use. Adding a half-width period to the beginning of the name of a component of this type keeps it inside the component library document and prevents it from being searched for by the end user.
- Focus on semantics and create variants whenever possible, rather than allowing users to adjust the visibility of layers. The first consideration at all times should be to create exhaustible combinations and provide semantic variant options. While there are some components with complex functionality that have to let the user adjust the visibility of the layer to achieve the desired state because of too many combination cases, this should only be used as a final approach (and should be explicitly stated in the component description).
- Maintain text content when switching component states. When a user changes a button title and switches the state, he should expect to not have to re-enter the title once. Setting identical names for the text boxes that need to maintain text in different state instances of the component can help to maintain the text.
- 在切换组件 state 时保持文本内容。当用户修改一个按钮标题并切换 state 时，他应该希望不用重新输入一次标题。为组件的不同 state 实例中需要保持文本的文本框设定完全一致的名称，可以帮助保持文本。
- Optimize responsiveness and provide expandability. For example, a software form interface provides at least two different widths for different scenes, but the form content is not significantly different. In this case, it is possible to combine atomic components and responsive capabilities to generate form components of two different widths at the same time. This way, when the form is adjusted, modifications will be applied to instances of each width to maintain a high degree of consistency in appearance.
- Make layer naming more accurate and understandable, and use default names for meaningless auxiliary structures. A jumbled order of layers and names makes the product look unprofessional and does not help designers understand the components in depth, nor does it help development efforts. Set accurate names for important layers and put them in a logical order, and delete names for unimportant layers and hit return/enter key to fall back to the default names.
- Reduce additional operations. For example, how to keep the visual position of Checkbox and Radio consistent? To correct for the visual illusion, the Radio should be somewhat larger than the Checkbox, but it is obviously more clever to preemptively free up space in the child components than to set separate paddings (inner margin), since it will remain visually centered in any future layout combinations that may be created, without relying on the external environment.
- 减少额外操作。例如，如何保持 Checkbox 和 Radio 的视觉位置一致？为了校正视觉的错觉，Radio 的尺寸应比 Checkbox 更大一些，但相比分别设置不同的内边距，在子组件中预先腾出空白显然要更巧妙，因为它在未来可能创建的任何布局组合下都能保持视觉居中，而无需依赖外部环境。
- Use plugins or efficiency features to improve creation efficiency. When creating a large library of components, it is inevitable that you will perform repetitive operations such as renaming, detach styles, creating styles, organizing the order of layers, and so on. In this case, you can use the batch function to improve efficiency.
- 使用插件或效率功能提升创建效率。在创建庞大组件库时，不可避免地会进行重复性的操作，例如重命名、detach 样式、创建样式、整理图层顺序等。此时可借助批量功能提升效率。
- Use descriptions and provide supporting instructions as necessary. When necessary, write supporting instructions to help users understand and use (but this should only be the final approach and should always be the first to consider creating intuitive options).
- Provide links to relevant documentation. If a designer wants to view content related to front-end development for a component, he or she should be able to click the Documentation Link on the Inspect panel of the component to jump without having to leave his or her familiar work environment, find and open other documents.
- 提供相关文档链接。若设计师想要查看组件与前端开发相关的内容，应能通过 Figma 为组件提供的链接功能，从单个组件的 Inspect 面板中跳转查看，而无需离开自己熟悉的工作环境、查找并打开其他文档。
Results and Reflections
Stay close to the needs and scenes, and let the function define the form
Although the process of reaching the goal took a detour, after continuous listening and learning from experience, the end result was highly appreciated by the designers who used the design system. The key to this transformation is to get back to the scenes and to the needs of the users.
In addition, if we were to do it all over again, I think a significant part of the design system should be used as an “efficiency project”, such as a component library, which should be summarized at a stage when the functionality and style of the interface is relatively well defined, and serve to organize the design drafts and new designs in the future. In this way, the requirements can be truly clarified and served in the most appropriate form for those who need them.