前言

在 Ant Design 5.0 发布会上将蚂蚁内部建设设计系统的理论、方法。今日前端早读课文章由 @梓义分享，公号：支付宝体验科技授权。

正文从这开始～～

在开始分享之前，我想先与大家探讨几个问题。

第一个问题，有两个组件，左边用来控制页面间切换，右边用来定位页面内内容，它们在样式上一模一样，请问，在设计系统里应将它们归为一类组件吗？

第二个问题，同样都是日期选择器组件，理论上它可以承载很多功能，那么，我们在设计系统里应该做到何种程度才算合适呢？

第三个问题，BackTop 组件在 Ant Design 4.0 之前作为一个独立组件而存在，请问，它真的算是一个组件类型吗？如果算，那右边这种情况是否应该归为新的一类组件？

最后一个问题，某设计系统需要建设平铺式多选器这样一类组件，我们有两位设计师出了两套方案，请问哪个方案更适合作为规范纳入到设计系统当中呢？

上述问题其实也是我们过去在建设各类设计系统时经常遇到的问题，由于各种原因最终导致所谓的设计系统越来越不规范，那么长期而言，对业务来说其应用价值将会递减、运维成本递增。

如何解决上述问题？经过两年的思索、实践，我们内部沉淀出一套相对确定的、易用的理论方法，能帮助我们更快、更好的建设设计系统，目前它已被应用于指导 Ant Design 5.0、 Ant Design Mobile 5.0 以及蚂蚁内部诸如企业智能场景子系统等各种设计系统的建设当中。

我们给它起了一个好记的名字：Ant Design MetaGuide 设计系统元规范（下文简称 ADM）。

什么是 ADM 元规范？

ADM 就是设计系统自身的建设规范，它的目标用户是设计系统的建设者们，希望授人以渔，帮助系统建设者更好的建设和发展自己企业的设计系统。

更具体来说，ADM 能帮助系统建设者达到两个目的：1、确定要做什么组件；2、评估组件的质量。

Part 1：如何确定做什么组件？

回到今天主题的第一部分，如何通过 ADM 元规范来确定设计系统应该要做什么组件呢？

在讲解之前，我想先和大家分享一则小故事。

在我上大学的时候，有一门设计课程，导师要求我们用废弃的瓦楞纸设计一把让人叫好的椅子。起初我心里犯嘀咕，常见的椅子不都是木质、塑料或钢铁材料设计而成的吗，瓦楞纸怎么可能设计出一把好椅子？

老师接着说，所谓椅子的设计，不是要我们去思考要设计 “什么颜色的椅子”、“什么材质的椅子” 抑或 “什么形状的椅子”。他希望我们回归用户去思考，设计椅子的初衷究竟是为了什么？是为了满足用户 “坐” 这个行为目的。

因此，所以 “设计一把椅子”，其本质不是设计一把怎样的椅子，而是设计 “坐”。真正的设计者，即使面对瓦楞纸这样一个简单的材料，一样能设计出一把用户心满意足的椅子。

初入设计学的我，醍醐灌顶。

其实，为设计系统设计一个组件，一样如此。用户通过界面使用我们的组件，并非为了用而用，而是为了达到他的某种行为目的。如果我们回归到这样一个简单的本质，那么对于组件的定义可能就十分清晰了。

回顾一下过去我们都是如何建设一个设计系统的。

我们可能会去看看竞品做没做这类组件、我们可能会听从老板的建议增删某类组件、我们也可能掉入满足所有业务诉求的陷阱当中，让用户之声成为系统建设的依据。诸如此类的判断标准，正是一种从现状和多决策因素出发形成的归纳性思维，在设计系统构建过程当中，它容易让我们优先思考组件的表层属性即其作为物品时的属性，从而作出建设的判断。正因如此，我们才经常会看到类似组件越做越多、越做越不成规范的设计系统。

归纳性建设思维，在建设 0-1 设计系统时很快。但当设计系统伴随企业发展变得越来越成熟，这样的建设思维就会出发很多 “规范不规范” 的难题。

这时，我们要回归本质，去源头寻找组件建设的决策依据，一个确定的能让团队共识的决策依据。这个依据正是 ADM 所倡导的，将建设视角从归纳视角切换成演绎视角，认识到真正的设计规范不是「物的规范」而是「行为的规范」。演绎视角是一种探究本质的思维，这与 “第一性原理” 一样，我们需要去寻根究底何为组件的本质。

想想椅子的故事，组件的本质正是为了满足用户某种行为目的。因此，组件做到和中程度取决于你要多大程度的满足用户的某个行为目的。根据组件满足的行为目的不同，我们就会产生组件的分类，更进一步，根据衍生出来的行为目的，系统会建设对应组件变体。

将设计系统理解为「行为的规范」，我们便能对系统的边界有清晰的认知，当下应该建设到何种程度，未来又该往何处发展。

理论比较抽象，接下来我将带着一个小工具帮助大家消化这个理论，并真正理解它是怎样在建设过程当中其作用的。这个小工具我称之为「组件行为模式地图」。

以开篇提到的 DatePicker 日期选择器为例，我们使用行为模式地图来对其进行定义。

首先我们知道，使用日期选择器不是用户的行为目的，用户是想通过它来达到「输入时间型数据」这样一个行为目的，根据时间型数据的不同，行为目的可细分为「输入时间点」和「输入时间段」，因此无论如何我们的设计系统，必须提供对应的必备组件，供用户使用（下图蓝色部分是 3.0 之前建设完成的组件）。

伴随企业数字化的发展，用户希望能够更快的达成他的行为目的，因此在原来的行为目的之上产生了衍生的行为目的，如「更快捷的选择某个特定日期的数据」等，因此我们在设计系统里，提供了对应的组件交互变体（下图中绿色部分是 5.0 本次新增的变体组件）。请注意，因为组件交互变体满足的是衍生行为目的，所以理论上我们的设计系统不提供对应的交互变体，用户一样能够完成他的行为目的。

在考虑完组件的定义之后，我们根据对应服务的企业和业务的差异，为组件穿上全局一致的 “衣服”，便完成组件的建设。当然如果企业对于本组件有特殊的样式要求，通过判断这种样式具备一定的通用性，那么我们也可以新增一个组件的样式，以便进一步提效，这样我们便有组件的样式变体。

当然，我们希望样式尽量通过底层 token 灵活性提供给业务自行改造，尽可能克制的在系统中增加样式变体。

通过这样一个行为模式地图的拆解和定义，一个完整的「DataPicker 日期选择器」便定义和建设完成了，而它未来的生长方向也有了清晰的预判。

再来看一个设计系统里比较复杂的案例，重型表格组件。

在 Ant Design 5.0 当中，我们也将内部使用多年的 6+ 重型组件开放出来给大家使用。

任何一个设计系统都有关于表格组件的定义，但各有差异。这种差异的根源也正是从物的规范去理解表格这个资产带来的。过去我们内部也是从物的角度去抽象结构表格的建设范围，会发现越抽象越多，最终只能交给专家感性判断做什么与不做什么。

如果我们转变成 ADM 元规范的视角来指导表格的建设， 我们能得到什么？我们能得到：

• 一个有内在统一逻辑，可维护，可拓展的表格组件架构图

• 组件不容易重复建设，不会使表格演变的越来越冗余

• 有清晰的表格组件演进路径，容易判断当下应该先做什么

• 建设者认知统一，从生产到消费的产物都能达到内在的统一

由于时间原因，大家可自行对比查阅下列两张资产架构图的差异点。

我们将视野从组件拔到整个设计系统层面，理论上，如果能对每类组件逐一定义其「行为模式地图」，我们可以便能等到一张完整的设计系统的行为模式大图。这张大图告诉了我们，设计系统的边界在哪里，现状是怎样的，未来可以往哪里发展。

从而，让设计系统更「确定」，让基于其发展的领域设计子系统具备「生长性」。

这里也跟大家分享我们的一些判断，如果你所服务的企业还处于中小型初创阶段，那么你可以建设一个满足必要行为目的的「0-1 通用设计系统」，用 ADM 确保组件交互是收敛确定的，用底层 token 的灵活度机制让样式足够的开放，可被灵活定制。如果伴随的企业业务壮大，你可能需要更成熟和大型的设计系统，此时你可以通过满足更多的行为目的和衍生行为目的来构建一个「1-N 通用设计系统」。

更进一步，如果你所服务的企业是像蚂蚁一样具有海量业务场景的平台型企业，那你可能需要依赖通用系统去生长出适用于不同业务场景的领域设计子系统，去进一步深入到不同领域里提供更高效、垂域的设计解决方案。

以上就是关于 ADM 元规范第一部分的介绍，分别从意识层和方法层介绍了如何定义组件。

是不是挺简单的