如何向团队、向老板介绍设计系统？

这是前段时间应邀做的一次关于设计系统的“布道”分享。我将 PPT 内容进行了一些细化和调整，作为会员专栏的试读文章分享给大家。

如果有需要，大家可以关注公众号私信获取 PPT 的 Keynote 源文件。
这次的内容实际上也是对过往前面几篇文章一个不同视角的“串联”，比较适合做主题性的分享，给你的老板、团队同学讲解为什么要做设计系统。
这次分享的定位：

设计系统的理论和案例，相信大家在日常工作中已经看过不少，也不是本次的分享的重点。所以这份 PPT 不聊细节，而是基于这些年在设计系统、协同过程中的一些感受来给大家聊聊我是如何看待设计系统的。
外部环境正在发生的变化：

互联网早已不是新鲜产物，我们生活的方方面面都已经逐步地互联网化。也正是因此，互联网公司也越来越受到国家政策、经济环境的影响，而身处互联网行业的设计师，我们工作也与之息息相关。
就近一年的观察，我觉得这三块变化和我们还是有很大的关联的，所以先拿出来和大家分享一下：
就像我们每个公司都有自己的目标，政府这个最大的平台也对近 5 年整个国家的数字经济发展有一个明确的目标。这四五十亿的预期增长目标的背后有大量的需求增加，显然依靠现有的生产模式是无法解决的。
近两年大形势不太好，所有的企业都在做降本提效。降本很多团队都在做，但光降本还不够，提效同样也需要抓。
我还在阿里的时候，你和人聊设计系统，人家没那么感冒。但如果你说这个东西可以提效，减少开发周期。那么大家可能会眼前一亮，可以进一步聊聊。
软件开源，也是十四五规划中非常重要的一点。如今的中美关系、国际形势使得大家的意识上越发的明确，国内企业、公司、政府不能长期依赖外部的产品和工具。
开源是促进整体发展中非常重要的一环，互联网头部企业比如腾讯、字节、阿里都在其中承担着非常重要的带头作用。
一次关于设计系统的调研：

19 年的 Ucan，我做了一次关于设计系统的工作坊。大家都是带着好奇来参加的，真正在开展设计系统工作的团队并不多。
而到了今年我做了一次调研，虽然有效样本只有 100 多个，但还是具备一些代表性的。大家可以看到无论是公司对设计系统的认知，还是投入的程度都有了非常大的变化。
具体的分析结果，大家可以看看之前的这篇文章 ↓：

我向 100 位设计师做了次设计系统的小调研
聊聊在阿里的真实案例：

在阿里有两套主流的设计系统，分别是我们设计中台的 Fusion Design 和蚂蚁的 Ant Design。
两套设计系统都是差不多在 16 年左右启动的，发展至今它俩支撑了三大集团（阿里、菜鸟、蚂蚁）的全部数百条业务线。
在一些我们重点合作的业务里，已经可以达成帮助设计师提效 50%，研发提效 30%的成果。当然，这些成果不只是源于设计系统，还需要有一系列的配套流程和工具。
如何看待设计系统的价值：

在企业里工作，讲清楚一件事情的价值很重要，比如做设计系统就经常会面临很多人的疑问。19 年 Ucan 工作坊上我也收到过同样的问题，但我觉得当时回答的不太好，更多还是偏向于强调对设计、对设计师的价值。
但随着接下来这些年在阿里很多业务中的摸索，有成功也有失败，我认为从以上三个方面来回答这个问题会更容易获得大家的认同。
设计系统的三种类型：

这些年业内出现了很多的设计系统，国内、国外有很多。大家在聊起设计系统时候经常会说起这家怎么怎么好，那家怎么怎么不好。
为什么会有这些不同的看法？是因为大家所面临的问题以及对它们的定位有所不同。比如字节的 Arco、Semi、腾讯的 TDesign，有很多人说他们过于简单，也缺少差异性。
如果你带着对解决业务实际问题的角度看待它们，那确实很难满足大家的要求。因为他们的定位都是企业中后台的领域级系统，它的目的就是尽可能的减少同质化的基础工作，业务的部分并不在这套系统的目标范畴内。
有了这个定位的概念，我们就可以再来将我们曾经看过的这些设计系统做一下分类。（如上图）
从系统级→领域级→业务级，他们本质上是一个从抽象到具象的过程，大家可以关注一下这里，不同类型的设计系统在定义和要求上是有差异的。
对于我们绝大多数设计师而言，主要的工作都发生在业务级，基于一套底层的系统去构建符合业务诉求的设计系统。比如阿里云的 BDesign，就是在 Fusion Design 的基础上“生长”出来的。
领域级设计系统案例 AWS CloudScape：

AWS 的 CloudScape 是近期我看到完成度最高，最值得大家学习的设计系统。总体来说我会将它的优点总结为以下三点：
01. 内容简练务实，指导准确有效果
相较于很多设计系统的站点，CloudScape 提供的内容非常简练，没有太多对这套设计系统设计理念、价值观的讲解，更多还是落在实际应用指导。
它更像是一本面向实操的指导手册，每一个 Component 和 Pattern 都提供了清晰准确的定义、场景以及使用说明。而且大部分都提供了在线配置调试功能，帮助使用者更好地理解和使用。
02. 定位明确，领域性强
从 2016 年启动到现在已经有了 6 年时间，经过了 AWS 这么多年业务中的打磨后 CloudScape 给我的一个感觉就是清晰和明确。
特别是在 Pattern 的部分，35 个虽然不算多，但基本都是这个领域的内的一些标准场景的抽象。基本上云产品业务需要的场景它提供了指引，相信做过相关产品的同学会有更强的体感。
03. 强约束性 & 可控自由度
设计系统就是要对场景进行抽象、封装并逐步进行合理有效的约束，达成体验上的和谐和统一。
CloudScape 坚定的给出了很多强约束来保障产品的基础体验一致性和有效性，同时它也在可行的范围内提供了一些自定义空间，来确保产品设计过程中的差异性。
AWS CloudScape Design System 详细介绍 ↓

设计系统的构建思路：

前面我们讲了设计系统的三种类型，但到自己做的时候该怎么入手呢？我给大家推荐两种思路。
一种是基于领域级设计系统，适合偏 Web 端的产品，有很好的 0 到 1 基础。重点关注行业领域的特性，去抽象业务组件、业务 pattern。
另一种是基于系统级去构建，适合偏移动端的场景，直接业务级往上去做。这里在领域级，我推荐大家可以去使用阿里、字节、腾讯这几家的产品，因为迭代速度和维护有更好的保障。
设计师岗位的变迁：

03 年毕业工作至今，有幸经历了从“美工”到设计师的整个历程。时至今天设计师这个职能已经被行业、被公司所认可，职能和领域也在不断演变。设计系统的不断发展让设计的“架构”逐步成型。
19 年左右第一次在委员会和大家提出了架构型设计师和产品设计师的构想，不过当年的时机确实还不够成熟。随着这些年在团队内部的试验，我相信架构型设计师是未来设计师职能中非常重要的一种类型。