这么多 Design System,我们应该怎样去学习?

2024-03-28

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

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

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

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

设计系统 的不同层级 design system levels

设计系统 – 三个层级

系统级设计系统:

当下的数字产品大部分是基于操作系统和浏览器所构建的,所以我们首先需要基于 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

📬 专栏:设计有得聊

欢迎加入我的知识星球 – [设计有得聊↗]使用微信扫描下方二维码了解详细信息。

设计有得聊专栏