这么多 Design System，我们应该怎样去学习？

设计系统 近几年越来越受到大家的关注，国内有阿里集团的 Ant Design、Fusion Design，以及字节系的 Semi、Arco、腾讯的 TDesign；国外也有大家比较熟悉的 IBM Carbon Design、Salesforce Lightning Design，以及前段时间给大家介绍的 AWS CloudScape。

对于这些设计系统，大家时常会有一些不一样的观点。比如有的同学认为 A 做得好，B 太过于简单，全是底层能力没啥用。

如何理解这些设计系统之间的差异，是我们学习过程中非常重要的一环。我们不能简单的从内容上去做比较，而是需要先从它们的定位出发。

我个人的观点，是会将这些设计系统分为系统级→领域级→业务级三层，大家可以用下面这张图看清楚它们的逻辑。

设计系统 – 三个层级

系统级设计系统：

当下的数字产品大部分是基于操作系统和浏览器所构建的，所以我们首先需要基于 OS 或浏览器级的设计系统开始工作。这里最常见的是 Google 的 Material Design、Apple 的 Human Interface Guideline以及各种 Web 前端框架，比如 BootStrap。配合硬件和软件技术的发展，系统级的设计系统为我们提供丰富的交互形式以及设计指引。同时它们也对用户的基础认知和使用习惯做出了定义和引导，确保了一个产品在基础交互层面的体验基准线。

领域级（行业级）设计系统：

移动互联网时代，大家都在研究系统级的设计系统。但实际上我们绝大多数的工作并不在这里，它们也并不能对我们在业务中的设计提供明确的指引。

每一个行业也都在过程中逐渐积累、形成具备领域特性的设计模式，比如电商体系中的购物车、toB 体系中表单、列表。

我们前面聊的腾讯、阿里、字节的这些设计系统大多都是属于这一层级。通过建立一些具备共同认知和有力量的标准，来提升这个领域的体验基线。

同时它们还需要具备良好的生长性，让其他的公司能够基于它去构建自己的设计系统，解决领域内产品 0 到 1 的问题。

大家可能会发现一个有意思的地方，目前的开源设计系统大部分都是 toB 端这个领域的。在我看来最主要的原因就是 toB 端的场景会相对“严肃”，大家的核心策略都是尽可能的清晰、高效，帮助用户快速完成任务，也更容易达成统一。

这并不代表只有 toB 的场景才能够出现领域级的解决方案。随着互联网越来越基础化和行业的发展，未来在这一个层级上会出现越来越多细分的领域级解决方案。当然，它也还得需要各位的努力和支持。

业务级（产品级）设计系统：

业务级是整个设计系统层级中最上面一层，也是大家参与得最多的部分。它的定位很明确，就是基于行业的特性去给自己的业务构建设计系统。IBM 的 Carbon Design、AWS 的 CloudScape Design 以及大家都在参与的都属于这一类。

业务级的设计系统的目的是提供明确的约束和指引，能够帮助业务快速的实现产品业务逻辑，避免不必要的浪费。同时也需要具备良好的业务抽象和扩展性，有非常好的运作机制，能够提升整体业务生产链路的效率。

延展阅读：设计系统 · Design System 应该做到什么程度才够？

网络上能找到的业务级设计系统很多，它们也是我们非常好的学习案例。正是因为它们面向的是解决业务问题，所以大家不能单纯的看内容，而是需要结合这个行业以及这个产品的特性、问题来进行分析。

很多人都觉得类似 IBM 的 Carbon Design 做的非常好，但虽然它是开源的设计系统，却似乎很少看到使用的案例。其实这一类的设计系统大多都是在自己的业务中逐渐生长出来的，还是带有比较强的业务属性和品牌特性，真正在自己的业务中去使用未必合适。

这里我非常推荐大家去看一看 AWS 的 CloudScape，看看它是如何去做对设计的抽象和约束的。

📬 设计系统案例 CloudScape Design System