AI 设计系统创建：一键开启 AI 时代的新实践

一个良好运转的设计系统能够提供可复用的组件和设计规范，使得开发人员和设计师可以快速构建新页面或功能，而不需要每次都从零开始，这意味着团队可以更快地设计和开发产品，同时保证产品质量和使用体验的一致性。随着越来越多互联网公司推出自己的设计系统，大家也基本都会认同设计系统是一套先进且对团队有帮助的实践方式。

顺理成章地，我们认为这样的实践应该在产品设计团队中普及。

有了这样的假设，我着手调研设计系统在身边的专业设计师及他们所在团队中真实的实践情况。我花了 1 个月时间，访谈了大约 15 个设计团队，结果却不尽如人意——这些团队中很多没有设计系统，只有 2 个规模较大的“大厂”设计团队表示他们有良好运行的设计系统。

一个行业内被普遍共识的最佳实践，实践的渗透率却不高，这令我费解。带着疑问我们调研了更多团队，发现阻碍团队搭建设计系统主要有两个原因：

• 团队对于设计系统的重要性认知不足：当我们提出要搭建设计系统时，往往会面临一个问题——如何说服大家抽出一部分精力去搭建设计系统。通常只去介绍设计系统的好处，但不指出当下设计实践脱离设计系统的问题，是无法说服团队做出“立刻搭建”的决策的。提出建议的人还会面对一些难以回答的问题，诸如“当前虽然没有设计系统，但也没什么问题啊”，“目前的实践运行良好，设计体验看起来挺一致的”。
• 设计系统的搭建成本很高：搭建设计系统要求我们先遍历过往所有设计稿，再总结概括成自己团队的设计规范。单说收集整理过往设计稿这个过程就十分耗时，拿我们调研的团队举例，他们的设计系统需要 2-3 设计师花费 2 天才能完成收集工作。

决定让 AI 辅助搭建设计系统

在了解过问题后，作为一直在探索用 AI 解决设计场景问题的 Motiff，我们则思考 AI 是否能解决上述两个问题：

针对如何说服团队开始搭建设计系统的问题，《原子设计》的作者 Brad Frost 曾提出过一个“展示代替说教（Show, don’t tell）”的概念，这个概念的核心是收集构成当前应用程序的样式和组件，整理成一份“界面清单”，将不一致的地方直接“暴露”出来，而非一味地科普设计系统有多好。

在这里，我很自然地联想到也许 AI 能帮助设计师完成界面清单的整理工作，因为收集和整理恰是 AI 擅长的。

而设计系统的搭建成本问题其实可以拆成两部分，收集和定义：

• 收集就是提炼出当前应用可被创建成样式和组件的元素，和第一个问题的答案一样，收集其实也是在制作界面清单，我们认为 AI 可以帮助人完成这部分工作；
• 定义是对界面清单中的样式和组件进行新的重组和剔除，并最终定义出设计系统中的样式和组件，这部分工作需要掌握设计上下文和业务背景，甚至不是一个人可以完成，它需要在团队内集体讨论并最终达成共识。我们认为这部分工作只能由人决策。

界面清单既能成为设计系统发起人的“说服工具”，又是设计系统创建的第一步，帮助设计师及团队完成收集工作。基于这些分析，我们确立一个阶段性目标，让 AI 帮助设计师整理出一份界面清单。

如何让 AI 识别出界面清单

分类

正如上文所讲，界面清单是对当前应用程序中样式和组件的整理和分类。要想让 AI 整理出“界面清单”，对我们来说首先要定义有哪些样式和组件类别，并让机器学会这些分类。在分类上，我们除了借鉴《原子理论》中举例的类别，也借鉴了 HIG、Material Design、Fluent、Spectrum、Ant Design 等设计系统里组件的分类，如颜色、排版、按钮、标签等。

这里不得不说最开始我们低估了分类工作的难度，随着不断涌现的特殊情况，分类体系也在一直更新和迭代。

重新打组

AI 学会了分类之后，我们又遇到了新问题——AI 的每次识别都在丢东西。在分析了大量的错误案例后，我们找到了问题所在。

以下图为例，设计稿中的 List 都有头像，为什么识别结果中没有头像呢？原因是头像并不在当前 List 的图层组内，它在图层列表中很远的位置，所以 AI 在识别时把它丢了。针对这个问题，我们抛弃了原来的图层关系，先让 AI 进行重新打组。

完成了分类和重新打组的训练后，AI 给出的识别结果差不多可以看了，但：

• 设计稿中存在大量“冗余设计”，它们被整理在了界面清单中；
• 识别结果中各种信息的陈列无序且低效。

即使是对这个产品最熟悉的设计师，也无法判断哪个组件会在什么场景下使用。

于是，我们下一步的任务是“让界面清单更好用”。

如何让界面清单更好用

在做功能的过程中，我们不断优化界面清单的呈现，希望 AI 能提供给设计师更多辅助信息，帮助设计师高效决策。

为了让 AI 生成的界面清单更便利地供设计师使用，我们开始思考设计师拿到界面清单后可能会做什么事，并且沿着这个思路，我们期望寻找到关于两个问题的答案：

• 在设计师看来，界面清单怎样展示最方便易看？
• 哪些信息最能辅助设计师做决策？

更有效率地展示

• 去重

在我们第一次拿到 AI 识别结果时，它的数量多到根本无法使用。原因是在这其中，出现了大量有细微差别的组件。AI 会因为文字或配图的不一致，将同一组件判定为多个相近但并非完全不同的候选内容；但对人来讲，则很容易理解这其实就是同一个组件，只是应用了不同的内容。

为了避免无效信息展示给设计师，我们制定了去重策略，例如：

下图中列表（List）因为头像和文案不同，被 AI 判定成了 2 个组件。

下图中对话框（Dialog）因为文案不同，导致弹窗大小发生了改变，被 AI 判定成了 2 个组件。

• 聚类和排版

在界面清单中组件的聚类和排版上，我们也花了很长时间来优化结果。拿颜色举例，你会发现有大量相似的颜色，比如「红色」也许在设计系统中只需要 1 个样式，但现实中却识别出了 7 种红色。为了帮助设计师更直观的发现冗余设计，所以我们在聚类和排版上的目标是，将相似的样式和元素聚类展示。

相似度计算：起初我们用 HSL、HSB 色彩模型计算两个颜色的相似度，但结果却不尽人意，和我们眼睛实际看起来差异却很大。为了解决这个问题，我们开始寻找更符合人视觉的色彩模型，直到遇到 Google 的 HCT，真的非常感谢 HCT 。

聚类数量：我们还遇到过“究竟要将展示出来的颜色排成几排”的问题，如果要机械地根据色相区间排列，显然不是设计师们所期望的，过程中我们想到了可以用层次聚类算法，重新计算各个颜色的距离，算出更符合设计师所能理解的聚类方式。

辅助设计师做决策

• 使用频次

除了组件和样式的聚类与排版可以帮助设计师查看界面清单，我们还把“使用频次”纳入了考虑。用数字来帮助设计师做决策。

我们发现在面对一堆相似的字体样式时，统计它们的使用次数后，很容易发现哪个样式是被误用的，因为那些误用的样式毕竟不是共识，所以这些样式使用次数很少。

下图中，你可以看到他们数量差异很大。

• 回溯来源

发现了“使用频次”可以帮助找到被误用的样式后，我们发现了这个数据的还可以跟一个新的功能结合使用——“溯源”。设计师可以更方便地通过样式、组件使用的频次高低，查看他们被使用在了哪里，以便纠错和了解使用场景。

此外，这个功能的另一个用处是，在遇到一堆很相似的按钮时，设计师往往很难判断哪些是可以合并的，这时了解具体的使用场景成为了设计师的常见操作。为了更方便的帮助设计师了解使用场景，“溯源”这个功能能够帮助设计师快速了解这个元素和组件在什么场景下使用，也可以直接跳转到源文件查看具体设计稿。

AI 设计系统创建中的难题

以上讲述了我们在做“AI 设计系统创建”这个功能中克服掉的一些难题，下面讲一下我们至今没解决，可能之后也不好解决的问题。

什么是 Checkbox&Radio？

相信大家很容易回答组件中 Checkbox 和 Radio 的区别，简单来说就是多选和单选，多选中大概率中间是个“对号”，单选中大概率中间是个“实心圆”。

如果要给上图相信你也很快就能回答左边是多选框右边是单选框，但下图中，因为他们都是未选中状态，好像谁无法准确说出被选中后，这个组件中间是个“对号”还是“实心圆”。

好在这俩组件出现频次不高，我们就将他们合并展示在同一页面下：

什么是 Avatar？

在很长的一个过程中我都在和 AI 工程师辩论“什么是头像”。

我核心的观点：不是只有人才叫头像。这让他们很抓狂，机器很自然地认为头像必须得是人。但是我们都知道你可能将你家猫猫狗狗、你爬过的山、你喜欢的花设置成头像，甚至你就将纯色的色块设置成你的头像。

既然这条路走不通我们就反过来想哪些不是头像，于是我告诉工程师大概率 icon 不是头像，logo 不是头像；这个方向似乎帮我们排除了一批 Badcase，但我们在做 Web 端识别时又发现大量账号的头像就是自家公司 logo😊，我们Too young😊。

这类的错误案例还有很多，每当我们惊叹于自己完美的“解题思路”，却遭遇了一次一次的打脸。但我们依然相信这类困难会在数据集和算法上得到突破。

创建完设计系统后就真的结束了吗？

在上述内容中，我其实讲了一堆在识别结果中，我们如何为你优化界面清单，帮助你根据推荐的组件或样式去找出那个需要被保留、可被复用的设计元素。

但我很快就意识到了一个新问题——剩下的设计元素怎么办，直接剔除吗？那些偏离设计规范的设计要不要修改呢？

就这问题我又开始了新的调研。采访 10 余个团队的过程中我自己也做了个假设：为了保证设计一致性，过往设计稿应该被替换。

调研结论也印证了我的猜想，所有团队都表示需要将“误用”的元素替换成正确的样式或组件。因为大多数产品研发后续迭代的设计都要复用前人的设计稿，如果前人不去改正，后人也很难发现之前的界面是不正确的。

随后在调研中我又发现了一个新的问题，虽然大家主观都觉得应该去替换，但没有一个团队去真正替换历史设计稿。当前，这个问题的原因很容易猜到：替换太麻烦了。

我们甚至发现有的团队会需要用 KPI 强制要求设计师花费时间定期维护过往设计稿中被使用的元素。显然这不是问题的最优解。为了解决这个问题，我们设计了 AI 组件替换功能，这个功能已上线，欢迎使用。

同时，从生产者的关系来看，设计系统也并不完全只是设计团队内部的工作。它的创建不仅需要和下游研发组件库形成对应的共识，也需要整个业务团队中与设计相关的角色参与到这套系统的构建。当设计团队内部的组件库达成一致，前端开发的组件库如何统一？

我们正在研究如何在设计和研发之间搭建组件库同步的桥梁，敬请期待我们新功能…

回归问题的本质

我们真正关注的是设计一致性和设计效率问题，而设计系统是我们目前找到并坚信的最佳实践。

但我们的目标不仅仅帮中小团队搭建一套设计系统。我们期望在 AI 的帮助下将设计系统打造成一种 AI 与人共同协作的模式，同时期望通过这种新的实践方式，让更多的团队能够实现和提升设计系统的应用，从而推动整个行业的进步。