Kuaishou Design System*
快手企业服务设计系统
我在2021年秋天加入了快手的KID用户体验中心，成为600名设计师中的一员。
作为一名产品设计师/用户体验设计师，我主要负责快手企业级 Design System 的建设工作。此外作为设计基建（DesignOps）团队的一员，我们还在设计工程化、产设研工作流上做出了许多工作。
Client
Volt Industry
Services
Visual Design
UI & UX Design
Industries
Travel
Date
January 2023
作为快手企业服务设计系统的主 R，过去一年多时间其实做了很多工作，这里我放置了一个设计系统全景图，里面包含了我绝大多数过往工作的内容。
由于时间原因我不可能巨细无遗的一个个平铺讲述，一些基础的组件、规范等等内容虽然是 DS 的核心，但是由于已经在行业内高度规范化了，所以我不会详细讲述，感兴趣可以直接访问站点或者 NPM 下载我们的组件。
这里我想讨论的更多是高价值、具有复杂性、设计工程化的前沿产出，这里是我要讲述的设计系统核心要点：
企业服务 DS 服务范围
Design Token 原子化实践
Components 组件库
Document 设计系统文档化
设计系统的支持与迭代更新
设计系统的 ROI
Design Token 原子化实践
设计变量（Design Token，后面简称 DT）的定义、命名和建设是我在快手设计中台团队核心的产出之一。DT 的建设主要解决 6 个目的：
多业务、多产品下缺少唯一的、中心化的设计决策来源
设计还原度低下，需要反复走查与验收；
跨业务、跨平台的用户界面一致性；
更好的管理和维护设计系统；
多主题、深色浅色模式的应用与快速切换；
Design Token：设计决策的唯一真实来源
快手企业服务下业务产品繁多，且多数产品都是在同一个工作流中结合使用。比如：研发交付工具链，用户需要先创建需求任务，然后在代码工具中进行开发和上线，并在项目管理中上线。
针对可以界面中多种类型的原子样式，我们都进行了 DT 的定义。包含但不限于：颜色、字体、阴影、描边、间距等类型。这些元素都是组件界面的基本元要素，通过规范它们来达成整体界面的约束控制。
同时 DT 的核心优势是设计+研发双侧的约束和规范化。通过调用唯一的变量值，来达到高设计还原度的目的，减少走查和验收成本。
并且，我们通过引入 Klib × Figma，实现了设计变量的自动化维护。这意味着我们只需要管理唯一的“源”，即可实现内容层的分发管理。
语义化的三级 Token 结构
快手的企业服务 DT 是由三层次结构组成，底层为 十六进制编码 记录具体的色值，但是业务设计与研发都不会直接使用十六进制进行开发。
第二层我们称之为 Global Token：这些记录了企服的基础色，也是业务设计师可以使用的全量色彩，表现形式为：N100 - N1000；
第三层我们叫做 Alias Token：它是高度语义化的 Token 名称，记录了该变量的使用场景、使用类型和使用状态，设计师在进行界面设计时主要是调用 Alias Token。表现形式为：fill_brand_disable ；
中心化的 NPM Token Library
快手企业服务存在多框架的情况，不同的产品在使用不同的框架，目前是有 Vue2、Vue3、React。为了能够对不同框架版本的库进行统一化、中心化的维护管理，我们建设了 NPM Token Library。这个中心化的 NPM 包由单一接口人进行维护、管理，而其它研发只是进行调用即可，版本发生变更、更新时，所有引用该 NPM 包的团队都会同步变更。
这个变化的引入是我建设 DS 后逐渐推动起来的，过去需要一对一的进行沟通和发布，现在中心化的管理方式减少了沟通成本，也提升了迭代更新效率和准确度。
Dark 与 Light 模式：Design Token 的色彩空间概念
快手企服业务下的一些产品对于深色模式有强诉求（比如研发工具产品中需要深色的代码编辑器），而 DT 的另一个核心特性是对不同色彩空间的支持。这对于实现产品级别的深色与亮色切换，以及多主题定制都有非常好的支持。
对于业务设计师和研发来说，他们只需要在 Figma 或者 VSCode 中调用统一的语义化 Token，不会带来任何的使用成本。并且通过 Figma 自带的 Swap Style 能力，可以一键将深色界面转为亮色，反之亦可。
Components 组件库
38+基础组件
作为快手企业服务 DS 的主 R，我和其他几位同学一起建设了 38+ 基础组件库。数量和质量与业内开源的组件框架持平。
基础组件的科普不是本文的重点，感兴趣可以查看库链接或者我们的站点。
基础组件充分应用 Figma 特性：变体、文字、布尔、嵌套组件、自动布局
Figma的优势在于设计工程化的落地。我们充分使用了 Figma 组件的一些核心特性来构建我们的组件库，这可以满足业务设计师多样、复杂的使用诉求。
快手企服 DS 所有的组件都是基于 Autolayout 构建，这意味着它有充分的自适应能力。比如：文本溢出自适应，输入框自适应等等。
对于多交互状态的组件，我们都规范化的建设了所有状态变体：Normal、Hover、Focus、Disable、Readonly、Click。
Boolean 属性的应用帮助我们减少了 Component 的数量，比如最常见的 icon 是否展示，过去都是通过 Variant 实现，现在都过渡到了 Boolean。
嵌套组件的应用让复合组件中的子组件可以快捷进行参数调整，免去了业务设计师层层点选再调整的低效工作，在组件上层即可快速调参。
Atom Component：组件原子化
原子化设计虽然是老生常谈的主题，但确实是一个设计系统的基本盘。我们建设的设计系统同样是应用了原子化的理念，比如 Token，复合组件等等。
这里我更想讲述的是复杂组件的原子化设计理念，也就是我们日常聊的业务组件。它们是对某个业务场景的最佳解决方案（最佳实践），在我们设计侧通常会成为“设计模式”。比如代码差异比对的最佳实践，我们会将整个 Diff 的模块抽象为一个独立的复杂组件并给出具体的使用规则。
基于原子化理念构建的复杂组件有以下核心收益：
同步动态更新。
—— 以复杂的 Diff 组件为例，它嵌套了Button、input、Select、Badge 等等多种子组件。那么过去 Sketch 年代我们做子组件更新时，父组件并不会同步变更。而现在我们实现了这种可控制的同步更新。对于版本升级、库管理方面的质效有极高提升。
受原子规范约束，避免一致性问题。
—— 原子化的另一个好处就是复杂组件的所有要素都是原子规范建设起来的，而原子规范是被 设计系统团队高度约束和规范化的（设计研发双侧）。这就保证了一致性。
组件逻辑对齐代码逻辑。设计与研发保持同频对话。
—— 代码侧中，复合组件也是通过嵌套子组件来实现的。那么原子化就完成了与代码侧的对齐。这样在项目使用中也保证了和研发的相同视角。
Figma Properties 映射 API
作为设计系统建设者必须具备研发视角。
组件库的属性设置要能够和研发组件的 API 映射起来，这样设计师在调用任何状态事件时，研发在代码侧也有相对应的内容。
这部分工作我也和研发同学进行的深入对齐和共识，保证了 Figma 组件 Properties 的有效性。
03.Document 设计系统文档化
设计系统的文档化是设计系统的“视觉传达”工作，设计系统做的再好，也需要清晰的传递出去。并且业务侧对于这个站点也是强诉求，他们需要一个统一的位置查看规范、Demo、组件和资源。
对于重新自研的高成本、高时间投入，我决定采用业内已有的文档框架来做封装。
同时我们整理了需要满足的设计系统能力项，如下：
设计系统的文档化是设计系统的“视觉传达”工作，设计系统做的再好，也需要清晰的传递出去。并且业务侧对于这个站点也是强诉求，他们需要一个统一的位置查看规范、Demo、组件和资源。
对于重新自研的高成本、高时间投入，我决定采用业内已有的文档框架来做封装。
同时我们整理了需要满足的设计系统能力项，如下：
方案选型
最终我们选择了 Supernova + Storybook 的方式混合搭建，核心是能够满足我们对 Vue2、Vue3 以及 React 的支持。
04.设计系统的支持与迭代更新
设计系统一直都是一个动态发展的事物，它不是说建设完成就完成了，而是需要跟随业务的发展进步持续更新。
设计系统必须准备好解决设计人员和开发人员的新兴需求，有时甚至是紧急需求。这需要对流程进行前期投资和持续承诺，而这并非微不足道。相反，设计系统团队必须了解它支持什么类型的案例，它们出现在什么渠道，以及谁负责通过定义明确的工作流程来管理和解决每个案例。
因此针对设计系统的支持、更新与发布我定义了一个完整的流程机制来进行管理。
需求/诉求收集（Team、Figma、Kim…） ＞ 修改判断（改 or 现状） ＞ 优先级判断 ＞ 交付研发 ＞ 全员群发布 ＞ 组件更新上线
05.设计系统的 ROI
Figma 调用率
调用率一直是我持续观察的指标之一，它能够客观反映出设计系统中各种库的团队调用比例、调用次数（组件、图标、插图…）。
我们还看到今年格式塔 Figma 组件的采用率高达 45%，比我们在第二季度开始跟踪时提高了大约 15%。我们如何衡量 Figma 组件的采用率？因为我们建立了近乎实时地跟踪我们的组件在设计中的采用情况的能力！是的，这非常令人兴奋。是的，它改变了一切。是的，我们将在 2023 年更多地讨论这个问题。
组件分离率
组件的分离率代表了组件在业务需求中的适用程度，通常变体充分、能够满足业务设计师诉求的组件分离率会很低。过去一年时间，组件分离率仅为 0.56%。
计算口径：组件分离次数 / 组件单位时间调用次数 = 分离率
© Yifei(Allen) Xue. Have a nice Thursday.
关于本站：几乎所有内容在 Framer 中设计（少数在 Figma）。项目编排设计在 Illustrator & Photoshop 中处理。该站点动效使用 Framer Motion 构建，部分动画使用 Lottie.js。文章使用 Notion 撰写后同步过来，并使用 CMS 排版。图片采用 WebP 格式，图片大小平均减少70%。
Images generated using MidJourney · WebSite made with ♥︎ by AllenXue 薛困惑 · Made in Framer