设计系统 · 我们为什么要做 Design System
我们为什么要做设计系统
序：
2018 年的 10 月，我在专栏里发布了第一篇关于设计系统的文章。那是我在阿里建立设计中台部门的第一个季度，作为部门三大重要方向之一，我们已经用 Fusion Design 支撑了集团内（除蚂蚁）几乎所有的 B 端产品。
2019 年的夏天，我在 Alibaba UCAN（现更名 U Design Week）做了一次 关于设计系统的工作坊，和来自不同公司的设计师朋友们一起聊了 3 个多小时。那个时候已经有不少的小伙伴开始思考如何借助设计系统的体系化思维来进行设计交付。
那个阶段大家大多都还处在理论和实践摸索期，更多的还是站在体验一致性的角度来思考如何构建设计系统。而当年专栏的差不多二十篇文章也更多是从工具书的视角，再带上一些公司里实践的经验给大家介绍设计系统。
时间一晃快 4 年，环境在发生变化，我们对于设计的理解也在发生变化，这本“工具书”也是时候该进行升级了。前段时间在读者群里做了一次调研，发现很多公司对于设计系统的关注和投入都在明显的变化。
- 近 70% 的设计师所在团队都已经完成或正在建设设计系统，40% 团队由设计师和前端工程师共同参与；
- 90% 多的公司期望通过设计系统来提升整体的设计研发效能。
从阿里离职以后也不想再找一家公司继续两点一线的生活了，希望还是能够多一些闲暇时光体验不一样的生活。想了想继续码字还是最适合我当下的状态，同时也能将这些年在阿里工作的经验和思考分享给大家，而「设计系统的构建与应用」就是这其中的重要板块之一。
准备怎么写：
在设计系统调研问卷的最后我留了一个开放问题给大家，想看看对于设计系统还有什么疑问。
- 设计系统的完整体系是怎样的？
- 如何面向行业、业务去定义设计系统？
- 设计系统需要做到什么程度？覆盖多少业务体量才算够？
- 什么样体量的团队需要设计系统？不同类型的公司做设计系统有没有什么差别？
- 如何看待设计系统的约束与创新诉求？
- 如果跨团队达成设计的共识？
- 如何衡量设计系统的价值？
- 市面上这么多开源设计系统，他们的差别是什么？
- 如何确保设计系统的落地？有没有具体的流程和方法？
- 设计系统启动之前有多的想法和思路，但在构建过程中出入又很多，有哪些道与术可以借鉴？
- 如何验证你所设计构建的系统就是当前最有效的方式？
通过以上内容你会发现大家不再是盯着规范如何制定、文档怎么写等相对具象的问题，而是更多的站在设计工程、业务价值、跨团队协作等更深入的角度进行思考。而这些，也是近几年我在集团内各业务做实施中感受最深的地方。
所以，这次设计系统专栏的重启我会先花一些篇幅和大家聊聊在阿里做设计系统的故事，聊聊背后的一些思考和决策逻辑。我们大家先在“基础土壤”上做到信息对齐，这样我们后面的讨论也会更加顺畅。
整个「设计系统的构建与应用」专栏我会主要围绕以下几个部分来写：
- 设计系统背后的思考
- 创建设计系统流程工具书
- 设计系统案例解析 & 应用案例解析
- Design Pattern 案例解析
- 设计系统对协作模式的影响以及面向未来的思考
专栏的第一期，我们将先从 Why 开始，聊一聊为什么要建立设计系统。
设计系统的现状：
在开始聊 Why 之前，我想还是先和大家一起回顾一下当前互联网产品设计领域设计系统的一些现状。首先还是会上次 UCAN 的工作坊一样，将设计系统定义为系统级、领域级、业务级三类。
系统级：
顾名思义，就是操作系统级别的设计系统，我们日常会涉及到的主要就是 Apple、Google 和 Microsoft 三家所提供的。
Human Interface Guidelines - Human Interface Guidelines - Design - Apple Developer
其实我们也可以将它“简化”一下，将它们比作支付宝或微信的小程序就更容易理解了。支付宝和微信经过多年的运作累积了海量的用户和流量，于是很多的企业（或开发者）希望能够进驻到平台，为用户提供服务并获取响应的收益。
为了给用户带来一致、优质的服务和使用体验，支付宝和微信向企业（或开发者）提供一整套完整的设计指导原则和开发框架，也借此来帮助提升小程序的开发效率，降低产品的实现成本。而企业（或开发者）也会尽可能的去遵守它们的规则，以获得更好的业务上的合作扶持。
也正是因为系统级的定位，它们所需要服务的产品类型会有着非常大的类型跨度。所以这些设计系统的定义会更加的“底层”，会更注重对设计世界观的定义。这也是为什么它们会更多的去模拟、还原真实的世界。
注：这里顺便简单说一下对设计系统的定义。如上述我们不能将它们简单理解为一套设计规范或是设计语言，而是一整套面向业务生产（产品开发）的设计 + 工程的整体解决方案。以后我们会详细聊，这里先不展开。
相较于其他两类，系统级的数量并不会太多。毕竟它的出现是依托于几大主流操作系统之上，而我们大家参与的设计系统，大多也是以这几家为基础来构建的。以目前的市场格局来看突然再出现一家的几率不太大，所以作为设计师我们只需要保持好对以上三家的关注就好。
领域级：
相较于系统级，领域级的设计系统会更加聚焦于某一类通用场景。比如 IBM 的 Carbon Design，阿里的 Fusion Design，蚂蚁的 Ant Design 以及字节的 Semi Design、Arco Design、腾讯的 TDesign，并且这些设计系统大多数也是开源的。
Ant Design - 一套企业级 UI 设计语言和 React 组件库
Arco Design - 企业级产品的完整设计和开发解决方案
如果对以上这些名字有过一定的了解，你应该发现它们基本面向的都是企业级应用场景，或者是我们常说的 B 端场景。造成这种“扎堆”现象的原因其实还是因为企业级（B 端）场景是当下最适合被抽象并达成产品和用户两侧的共识。
这里的共识并不是说它简单、对设计的要求不高。而是在企业级的场景下，高效、一致、简洁等关键词是每一个设计系统最为核心的设计原则，目的是让用户能够更为有效、轻松的完成当下的任务。再加上如今蓬勃发展的 B 端业务，设计系统的价值在这里可以得到很好的验证和体现。
有些同学可能还记得 2018 年底 Ant Design 的圣诞风波，当时在国内外网络上轩然大波甚至还有人因此被离职，可见作为一个小团队投入的 Ant Design 默默的服务了多少用户和产品。
为什么领域级大多是企业级场景，别的场景难道就不能做吗？
坦白讲，理论上是肯定可行的，但事实上当下还是有比较大的难度的。一年多前我们在设计委员会有过一次命题，希望建立一套完整的 Alibaba 设计语言，将阿里的设计讲清楚，并在此基础上延展出电商、物流、出行、金融、娱乐、企业级应用等不同领域的设计系统。
花了半年多的时间，我们完成了 Alibaba 最底层根基的设计语言，但到了领域这一层的时候我们却暂停了。因为我们发现除了企业级应用，其他的领域在目前大家还比较难达成真正的共识。无论是哪个领域，当下其业务属性都要远超过其领域属性。所以在当下，这些领域更多还是会以业务级设计系统的形式存在，服务好各自的业务。
注：这件事儿虽然没有最终完成，但 Alibaba 底层根基建立过程是个很有趣的事情，后面有机会给大家展开聊一聊。
业务级：
业务级是为某个具体的产品或业务进行服务的，比如业内较为知名的 Lighting Design、Fiori Design 以及各位正在公司里所做的设计系统。
这类设计系统都有一个共同点，它们基本上都是基于系统级或领域级的设计系统之上进行二次加工定义的。这一类设计系统的领域会非常广泛，大家需要做的是基于这个领域的特性再叠加上业务特性进行准备的定义，帮助企业在对应的生态中快速开展业务，提供服务。
举个例子，2016 年我把整个团队的精力都投入在 AliExpress 的设计系统中，基于 iOS 和 Android 的系统级规范去定义 AliExpress 的设计系统。这其中耗时最久的就是在寻找平衡，在遵守系统级规范的同时去定义电商领域中这个产品独有的设计理念、思路。
虽然最后我们看似轻松拿到了 Google Editors’ Choice，但这背后和 Google 设计、研发团队的沟通、耗时之久可能是大家没能想象的。是的，真正的业务级设计系统往往就是朴实的，因为它还是以解决业务的实际问题为首要前提的。
设计系统要解决什么问题：
这里我们再简单回顾一下这三类设计系统
- 系统级：操作系统级别的设计系统，提供最底层操作系统级的设计及研发指引；
- 领域级：聚焦于某一类通用场景的设计及研发指引，当前最为成熟的还是在企业级应用（B 端）场景；
- 业务级：基于系统级或领域级的二次加工定义，为具体的产品或业务提供设计及研发指引。
对于设计系统的思考变化
这里我们聊的思考变化不仅仅是指在设计师角度，更多的是公司的角度来看待设计系统以及它所提供的价值。
以前我们聊设计系统，很多都是设计师和前端从认知、从兴趣的角度出发来尝试更为先进的业务生产模式。而很多公司的管理者对它的理解是设计的一致性、设计体验的提升，而对于降本提效至少在工程上我们也并没有特别明显的价值产出。
经营视角的转变
这两年随着互联网红利的逐步消失、疫情的影响，成本、收益都都面临的巨大的考验，连各大互联网公司也不再放任大家去不断的“试错”。阿里在一年多前也逐步的开始对每个团队实行经营责任制，让大家必须认真思考每一次的资源投入。
虽然大家诸多抱怨，但宏观上来说我认可这是一件正确的事情。它也倒闭着团队管理者们通过更科学、高效的工作模式来运作团队，杜绝浪费。同时也就在这个时刻，因为业务的特性，一些企业级产品从相关方到管理者都开始重新审视设计系统所能带来的价值，有些想清楚的也早早的开始并已经获得了相当明显的收益。
这里面的逻辑其实也并不复杂，给大家举个例子：某事业部 CTO 线的核心交付就是各类中台系统，宏观角度可以拿页面数进行计算。
单页面成本 = 平均工时工资 x 单页面交付时长
这里提供了两个影响成本的变量，要么降低工时工资，要么降低单页面交付时长，但对于企业来说非常时期往往两手都得抓。平均工时工资不在我们的把控范围内，但单页面交付时长对于设计师和研发来说就有很多事情可做了。设计系统的投入和产出价值可以很清晰的算笔账，只要方案制定得合理，大概率这个 ROI 是满足预期的。
业务视角的转变
还是说回前面那次关于设计系统调研，你会发现产品经理的出现了，设计系统不再只是一个设计和研发的工作，产品经理也需要参与其中一起制定规则。
受访者中有 16% 表示团队中的设计系统参与者为设计师、前端工程师、产品经理。
产品经理为什么要参与？因为在设计系统的角度，设计师和前端工程师定义的是解决某一类问题的界面交互模式。而产品经理的日常工作是创建实例，解决某个具体业务流程问题。
想象一下产品经理在写 PRD 的时候如果是这样的场景:
这是一个新品报名系统
- 模块 1：注册登录
- 模块 2：报名表单
- 子模块 1：用户身份认证
- 子模块 2：商家资质认证
- 子模块 3：…
- 模块 3：报名管理
- 模块 4：商品管理
这背后每一个模块、子模块，除了交互模式上的定义，还需要从产品上进行业务逻辑的定义。好的业务级设计系统应该让产品经理将重心放在业务流程本身，而不必去关心某一个具体按钮、弹框。而作为设计系统的制定者也不用再整天纠缠在业务细节中，将工作的重心放在对业务 Pattern的抽象、制定中。
我们曾经在某个面向商家的业务中做过一次尝试，但失败了… 这个案例后续有机会和大家详细聊。
当然，这类模式并不是一件容易的事情。它首先需要设计师、前端工程师、产品经理达成共识：
- 我们需要的不仅仅是规范，还需要更多的确定性的“约束”，将达成的共识封装成模块供使用；
- 非必要情况下，我们要做无畏的“设计创新”，一切以切实解决问题为优先；
- 如果需要对制定好的规则进行改变，不要修改实例。去给已封装的模块提需求。
为什么要做设计系统：
以上聊了这么多，这里我们再总结一下为什么要做设计系统
- 提升业务生产效率。当下互联网红利逐步消失，业务生产的模式需要发生改变，来帮助企业留着利润；
- 回归业务本质问题。逐步抽象封装业务模块，让产品回归业务逻辑本身；
- 统一“业务语言”。建立包含业务、产品、设计、技术的共同业务语言，提升团队沟通效率；
- 提升体验一致性。让设计系统团队专注于系统本身，优化并统一用户使用体验，降低用户使用成本；
- 更先进的协作模式。通过设计系统的引入，优化业务生产环节中生产协作模式；
- 提升团队战斗力。帮助新加入成员或生态合作伙伴更快的融入，提升整体生产力。
设计系统的未来：
去年年末国务院发布了「十四五数字经济发展规划」，这里面有几个信息很值得关注。
加快推动数字产业化
增强关键技术创新能力。瞄准传感器、量子信息、网络通信、集成电路、关键软件、大数据、人工智能、区块链、新材料等战略性前瞻性领域，**::发挥我国社会主义制度优势、新型举国体制优势、超大规模市场优势，提高数字技术基础研发能力::。以数字技术与各领域融合应用为导向，推动行业企业、平台企业和数字技术服务企业跨界创新，优化创新成果快速转化机制，加快创新技术的工程化、产业化。鼓励发展新型研发机构、企业创新联合体等新型创新主体，打造多元化参与、网络化协同、市场化运作的创新生态体系。::支持具有自主核心技术的开源社区、开源平台、开源项目发展，推动创新资源共建共享，促进创新模式开放化演进。::**
营造繁荣有序的产业创新生态。**::发挥数字经济领军企业的引领带动作用，加强资源共享和数据开放，推动线上线下相结合的创新协同、产能共享、供应链互通。鼓励开源社区、开发者平台等新型协作平台发展，培育大中小企业和社会开发者开放协作的数字产业创新生态，带动创新型企业快速壮大。::**以园区、行业、区域为整体推进产业创新服务平台建设，强化技术研发、标准制修订、测试评估、应用培训、创业孵化等优势资源汇聚，提升产业创新服务支撑水平。
软件信息服务、工业互联网平台、在线政务服务规模都被放到“十四五”数字经济发展的主要指标中。
自主、开源是国家未来的重要方向，除了阿里很早就已经对外开源的 Fusion Design、Ant Design，腾讯和字节也已经加入设计系统开源的行列中。信息化服务、产业数字化、数字政务，这些未来几年最重要的数字经济指标已经带来了一个巨大的市场空间。这背后需求与 IT 从业人员数量之间还是存在一个不小的缺口，而设计系统相关的人才诉求已经悄然的在扩大了。
设计系统的人才诉求：
我所管理的设计中台部门只有 3 位设计师全职投入设计系统的工作，阿里有数百个设计团队，数千位设计师在支持着各式各样的业务，但一直以来稍有团队专门负责这项工作。但随着设计系统的发展，这两年内部已经有多个设计团队成立了设计系统相关的团队或小组，但这类人才依旧很难找。我花了 3 年时间也只从 IBM 的 Carbon Design 团队招募到一位设计系统架构师，其他大多数相关设计师我们都是在边做边学。
在我准备离职的前一段时间，有一位猎头找来说字节飞书开放了一个设计系统的高端岗位，准备大力投入做飞书的设计系统，而且目前团队已经有了 10 多个人的规模。而就在最近腾讯 TDesign、字节抖音也在开放设计系统相关岗位，但猎头依旧在和我抱怨人太难找了。
是的，设计系统在设计领域中还是一个相对小众的话题。即使是包括一直在关注着设计系统的的各位，也只是在中国几百万设计师里非常小的一部分群体。但环境始终是在变化的，尤其是互联网行业，三年前和大家提体验设计师角色的演变（体验架构师和产品设计师）已经在一步步显现。很高兴设计系统在大家的团队、公司里越来越被重视，而已经参与其中的各位也将比其他人更早的进入下一个更为重要阶段。
共勉！ 💪🏻
欢迎加入我的知识星球 – [设计有得聊↗]使用微信扫描下方二维码了解详细信息。
