设计系统是栋大楼还是花园？设计系统创建模式随想

最近读了几篇类似的文章，都在说两种在创建和管理设计系统上对立的模式，也就是“建筑型设计系统”对立“园艺型设计系统”。啥意思呢，简单来说就是：

• 建筑型（architecture, prescriptive, intentional）
  常见的设计系统创建模式，一切井井有条，严丝合缝：定需求，构建设计体系，把体系分类，分完再细分，然后在平台开发基础组件，配有文档，设计指南等内容，业务团队按规则使用这些组件，并以此为基础按需扩展（得到批准后），形成一套工业化的流程，达到统一高效的目的。

• 园艺型（gardening, descriptive, emergent)
  接受不完美，手放得比较开，对设计系统内容有需求定义和大致规划，在统一平台上有少量基础的组件给业务团队使用，剩下的就看这些团队能创造出什么来了。效果好的，可重复使用的就和他们合作借鉴到设计系统里，不能重复使用的就给业务团队自己保留。这种方式的好处在于方便业务团队快速创新，保持设计系统的活力。

我自己是倾向于园艺型设计系统的。近七年的设计系统工作经验可以让我很自信的说，建筑型的设计系统在长期看来会限制产品的创新，并不会走的很远。但是，单单是园艺型的设计系统也会导致一些很严重的设计质量问题。再细看，这和每个公司的工作文化，设计系统的定位，产品成熟度，产品复杂度都有很大关系。

说这么多，还是来看几个应用场景的例子吧。

场景1：现有设计系统面临业务转型+新领域扩展

设计系统已经建立，内容和基础组件比较完善，利用率较高，因为公司业务转型或拓展导致新的需求爆炸性增长，这也是个接近我司app设计系统的应用场景。这里把设计系统比方成一栋高楼，往往远看宏伟壮观，走进去会发现角落里有灰，墙上有缝，到处缝缝补补，人山人海的楼里还在不停的进人，外面还嗡嗡传来打地钻的声音，好像是谁也准备开工盖自己的楼了，总觉得哪天这栋楼会塌掉也说不定。

其实绝大部分的设计系统都是建筑型模式里成长起来的，毕竟“统一高效”是产品对设计系统的首要需求。可是随着企业现有业务逐渐饱和，向外延展的需求越来越高，高度模块化的组件反而会限制想象力和创新的产生。如果你的设计系统不够灵活，自然会有业务团队（一般是公司当时最重视的业务方向）站出来建立一个更新，更适合他们需求的新设计系统，从而导致产品体验分裂，降低设计质量，增加技术负债。

这种情况下我觉得是适合转型到园艺型模式的。有了基于产品核心业务的设计系统做基础，采取比较开放的形式来进行扩展可以让业务团队感觉更有参与性，也可以给现有系统注入一些活力。打比方也就是在楼周围开一片田，规划一下大概每块地想要种什么，然后让业务团队承包开这块地，租给他们所需要的资源，并给予一些帮助。需要注意的是，越是复杂/多样化的业务，越是在选择业务团队上要有所取舍，选择合作意愿强烈，业务属于新领域，复用性比较强的团队。否则百花齐放，很容易失控，你设计系统这栋楼可能会塌的很快。

场景2: 全新的设计系统

这一点就要看公司对设计系统的定位了，而这个定位也大多会随着产品的成熟度而有所变化。

• 在产品初期（0-1），需要的大多是创新和能够根据情况快速反应的能力，这个时候园艺型比较适用。把业务当成种菜，分区，播种，呵护，长了杂草拔掉，养死了换一种再试。这个时候针对真实的应用场景而创造的解决方案可能并不能马上重复使用，也就没有必要花过多时间把设计系统每个细节做到完美，这个时候只要确保代码在统一平台，有一些最基础的组件方便修改就行了。

• 当产品发展到一定程度（但并不一定需要达到1），一些解决方案可能已经可复用，也就是说你知道一些菜会适合类似的生态环境，那就可以把这些菜聚在一起，规划温室大棚了。这时候首要目标大多是效率优先，那么建立新的设计系统用建筑型模式比较好，保证你的组件模版达到设计标准，方便业务团队使用，完善文档等等应该是此时设计系统的优先任务。

• 如果你的产品已经成熟，面临扩展（1-N），那么创建全新的设计系统可能需要从园艺型做起，建筑型为辅。花时间了解这片地现在的状态，哪里日照长，哪里阴凉，哪里杂草多什么的，再总结你目前可复用的东西有哪些，这样方便你规划出设计系统的优先顺序，在统一平台的前提下，把可复用的内容提效，根据公司目标制定需要重点关注的业务方向，和这些团队建立合作关系，和他们一起开发可以被其他团队使用的内容。

总结

其实说到底，就是要因地制宜，也要根据环境变化适当调整，找到适合自己产品的设计系统创建/管理模式。如果产品正处在起步阶段，创新第一，那么比较放手的园艺型是合适的；产品一旦进入了效率优先的阶段，或是有可复用的内容，那么标准化应该被重视更多，这时候采取建筑型的模式更好。有三点创建原则是相通的（这个感觉能单独写一篇）：

1. 目的性：一定要弄清楚这个设计系统是为谁服务的，用它能给业务团队带来怎样的好处；

2. 规划性: 设计系统不能什么都做，一锅大杂烩。一定要明确重点，确定优先级，哪些做，哪些不做，有舍才有得。

3. 实用性：不论什么模式，都一定要建立在实际案例的基础上，凭空想象的组件和模板除了浪费时间和人力，好像也没啥用处了。

你的设计系统现在是哪个阶段？使用的是那种模式？欢迎评论！