如何规避 Design System 架构设计中的逻辑陷阱？

@C7210 ：上篇文章说到了《像做产品一样对Design System进行前期规划》，包括目标、原则、范围与架构，这四个方面。本周在最关键的部分深入推进一步，聊聊「架构」当中的一些问题。

需要再次说明，这些内容多数来自于我日常的工作日志，更像随笔，且仅代表我个人在面对特定的产品/项目/团队时所用到的工作思路和方法；事情只有特定的最优解，而非唯一答案；希望为各位带来一定的参考价值。

一、组件库与设计规范

记得之前看到一篇文章，比喻得非常漂亮——仅就相对狭义的、以组件库与设计规范为主要组成部分的 Design System 而言，你可以将其想象成宜家家具，组件库是以零件形态呈现的家具产品，而设计规范便是指导你完成组装的说明手册。

两者的功用及关联性就是这样一目了然；两者的架构设计在很大程度上具有共通性。大体上，组件库与设计规范的架构体系在颗粒度较小的层面通常可以做到一致；但设计规范也会有其特定的目标及作用范围，当涉及到「设计模式」等层面，颗粒度往往会超过组件库所能承担的范围，此时也无需追求全面一致。

二、「原子化设计」不错

有过相关经验的朋友或许都知道，组件库初期的架构设计工作是最消耗时间与心力的过程，特别是对于大中型「成熟」产品而言，太多的功能流程及相应的组成页面，太多的不一致性问题。以怎样的规则去梳理可复用的组件，以怎样的颗粒度去划分组件层级，怎样确保划分方式具有足够的灵活性与实用性。推进过程往往是慎之又慎、举步维艰的，每一个步骤都严格以上一个步骤为基础。

组件颗粒划，目典论「（Atomic Design）」，章介绍；致：

• 原子：最基础的、不可分割的设计要素，宜家家具的零件单元，一块乐高积木，等等。通常包括颜色、文字、栅格体系等样式风格要素，以及图标、按钮、文本输入框、切换等功能性的界面基础要素。
• ：由组、备独立功复，例含输框、占符及按钮素搜索栏，或含户、户、户论及按钮列表（Table View Cell）。
• 有机体：由单一/多种类型的分子组成的信息/功能性模块。

至于「模板」和「页面」，个人看来对于组件库架构设计的意义不大；或可从「视图」的角度理解「模板」，这个再议。

三、会出现很多问题

然而在很多时候，当你准备以原子化设计的思路规划整个组件库的架构时，往往会发现实际状况绝非如此层次分明、符合逻辑；原子级别的要素大体还好，一旦进行到「分子」和「有机体」的层面，时常感到难以判断和区分。

梳架构 UI查，项枯燥冗，需将典页（截图或件），炼各类典素，相散归类，判断组件库致架构。遇典问题括：

• 对于一些模棱两可的元素，应该按照相似的样式进行归类，还是按照功能做区分？譬如样式上均属于「标签（Tag）」的元素，从功能角度，某些是真正意义上的属性标签，某些则是选项列表的组成部分；这时是否应该将它们归为一类？
• 数涉及「」，类「」或「」占据组，身组素往往根据页，括户、、论、Feed 。，否必封复组件，封否反响灵？它「功」组件逻辑怎？
• 除了主色盘及基本样式以外，产品当中往往会四处出现用途比较单一或边缘的配色、文字及图形样式，这些样式是否有必要进行严格的定义？如果定义，如何避免样式库与组件库的过度复杂；如果不定义，如何确保这些「非主流」元素在未来设计过程中的一致性？

四、问题的根源

个人认为，通过原子化设计的思路进行 UI清查和架构设计时遇到的一系列问题，其根本原因在于，「原子化设计」本身更像是一种开发思路，它是事物构成的基本规律与方式，但未必适于「认知」和「使用」层面的心智模型。

你可以遵循严格意义上的原子化设计思路去到 Sketch 当中逐层进行样式定义与 Symbols 嵌套，但最终的产出未必是对设计师实际有用的组件库。

述系列问题、矛盾，质户（）智模（组件库）逻辑冲突。身，组件库/系，「」「」织互换。

五、一些原则

组件库/系复言，任何逻辑标准未必；终从篇聊「目标」「则」，结户认模身逻辑，相折。

对于实际「用户」，即设计师而言，组件库/设计体系的目标在于解决表现层面设计工作中的痛点，提高执行效率与产出的标准化。围绕着这样的目标，我给自己制定了几点原则；每当在组件库架构规划中遇到问题和矛盾时，通常可以参考这些原则，以实际结果为导向进行判断，避免陷入逻辑陷阱：

原则一

对于组件库架构设计与库文件的制作方式，在大方向上要符合原子化设计思路，即颗粒度从小到大，从简单到复杂；特别是在 Sketch Library 文件的实际制作过程中，从技术角度严格遵守层级思路是必需而非 better to have。原子化设计的思维方向无错，解决问题的关键在于结合使用者的心智模型，即原则二。

原则二

难以确定组件颗粒度/复用性/在架构中所处的类别时，避免陷入过于严格的逻辑思维模式，而要考虑设计师的实际所需，考虑设计师在组装界面时的直觉与思维模式，考虑设计师在典型的需求中预期得到哪些零件，他们/我们对这些零件通常是如何归类的，哪些属性是他们/我们需要频繁订制的，哪些是很少/不会触及到的。对于使用 Sketch 进行界面设计的团队，组件库最终的产出将体现在一个个 Symbol 和 Shared Style 当中，而非设计规范中描述的设计模式或是开发侧的代码包；这些Symbol和样式能否被设计师快速发现、理解和调用，才是最重要的，无论它们在实现逻辑上是否符合这样或那样的设计思想理论；其他都是浮云，实践是检验真理的唯一标准。

原则三

充分分析和参考现有的任何设计规范/标准，运用你的基础开发常识（如有）去理解开发侧的代码组件架构；所有这些文档都能在一定程度上映射出产品的信息与功能架构。此外，相比于埋头在繁冗的 UI清查工作当中难以自拔、纠结逻辑，不如多花些时间与一线设计师进行沟通，了解他们/我们当前是否有着组件化的、非正规但有效的解决方案。将所有这些「现有」的应对方案进行汇总，再沿着原子化设计的大方向，结合自己的UI清查，逐渐梳理出一套即在一定程度上符合逻辑，又充分适用于实际需求的组件库架构框架。

图片素材作者：sandeep virk