成功建立有效的设计系统并持续维护已经是业内一个组织是否在创新文化方面成功/及格的标志。本文作者从自身工作经验出发，结合实际案例，对设计系统的意义、具体设计方法和注意要点进行了总结，希望对你有用。

Design System是不可能一篇讲完的，实际上根本不可能讲完。因为design system相关技术、建设方法、对应要求等都在一直变化，各位看官容小弟在这里浅谈一下算了。

一、什么是design system（设计系统）?

相信今天从事互联网产品设计的朋友们听说过，尤其是UI设计师、前端工程师。不过如果你打算举手并交出你的sketch控件库?，那么可能还是需要进修一下。成功建立有效的设计系统并持续维护之已经是业内一个组织是否在创新文化方面成功/及格的标志。在不同的产品属性、生命周期导致的不同语境之下，设计系统的定义可以非常不一样，我以能够对产品团队输出实际价值的角度去定义设计系统的关键组成的话，它至少应该起到以下作用：

1. 对于统一的、不断补充、丰富甚至修正的设计语言有完整的描述
2. 保证高质量产出的前提下，能够为设计流程、代码落地过程提速
3. 把设计样式和代码对应到一起的系统结构

二、制作design system的意义何在?

从2017年开始接触并且在一家全球五百里面瞎弄过些（对~不止一个所以是“些”）设计系统。因为有吐槽嫌疑就不明言了，毕竟学习、试错过程谁都可以有，个人也罢部门也罢公司也罢。之前在微软也参与过Bing的new branding refresh，不过如果用现在的设计系统标准看，那仅仅是设计层面的设计语言总结、控件规范的那一部分，再强调一次，这些还不算是设计系统，去面试的时候别拿一套控件库出来就瞎比比，专业领域里面有术语的变化肯定是有原因的，而且那个原因极少是“逼格更高”，认清这一点才算有了持续进步的门票。

相信很多团队对于设计系统都经历过因为“人有我有”的根本原因而发起过甚至建成了形形色色的设计系统，有个内容丰富的网站，满满的小字号文案、分门别类的控件库、页面模板以及不管用不用反正这里有的对应代码。对了，还需要有个trendy的名字。

没有实际意义的设计系统一般有特征如下：建立完成了之后，一直就岁月静好地躺着，没有更新；流量不大，展示时会被打开一下，但是鲜有设计师点开（可能刚到岗下载完控件库文件就没有然后），团队里面的前端工程师更甚可能连网址都记不住。好了吐槽完毕，以下净说好话。

其实设计系统的意义从一开始被提出概念时就已经非常明确。整体设计有所沉淀之后，设计样式抽象出复用性、前端根据所用框架制作可复用（并真实被一直复用）代码，达到省却设计、前端重复用力，从最终落地效果去保证设计一致性。理论基础是atomic design，出色例子有air BnB的驰名国内外设计系统、salesfoce的Lightning Design System，当然还有国粹Ant Design，这些你都知道了。

至于行业环境基础，我自己的总结是任何一个在某垂直做大做精的产品，都会有许许多多类似但是又有那么丁丁点点的必要差异化需要照顾，参照一下中台功能带来的变革就是为了避免重复造轮糟蹋人力一样，难道作为设计师/前端工程师的你真希望人力在无尽的岁月里头，把精力耗在“改个字段”、“加个输入框”之类的需求当中？你乐意养老，公司还不愿意养会用sketch的流水线工人。

所以致亲爱的领导们，如果你的百人团队做出来的产品，怎么老会出现类似同是一个确认键但是在这和在那总是有点什么不一样，然后明明人已经那么多了还是天天要加班，设计师/前端工程师还天天黑眼圈脸泛黄一副欲求不满的鬼样，估计是设计系统没有做好也没有用起来。

设计系统真做起来了之后怎么办？多出来的人力怎么办，难道裁掉吗？在这一步之前，还有很多让员工如沐春风朝气蓬勃并且对产品有大裨益的事可以做的，例如多出来的设计人力做用户调研，前端技术日新月异随时掌握了个降维打击的新展现层技术让你的产品鹤立鸡群也不是没可能。

但是设计系统不是一个解决了有和无就完事儿了的组织层面任务，如果不因地制宜去做肯定是无用功。我保证牢骚发到这一行字为止。

这几年新的UI设计技术手段，我自己的总结都是在两方面发展与用力：做出比真产品还要真（这是个笑话，当然）的prototype变得越来越容易；设计协同（设计师 与 设计师、设计师 与 开发工程师）越来越科学理性与流程化。而设计协同方面，各大工具作出的一个个努力（或者说一些让你觉得一定要买买买的feature们）最终沉淀下来都必将指向一套真正有效的design system。不管你是否有意识而为之。

三、一个设计系统包含了什么

网上找来的绝世武功的目录。所谓该有不该有都有了。每一个具体的话题你都可以无止境地深挖，而且每一个类别认真做的话都有无穷尽可以做的事。但是我们实际要做的结合自己产品、组织之中的实际需要，再参考别人的总表去规划自己的设计系统边界是什么。

规划设计系统范围的重点是：保持关键无赘肉。我始终认为判定一个设计系统成功与否的关键是，它是不是真的最终能够成为设计师、前端的工作工具，是不是真的简化了他们的工作流程，他们是不是真的喜欢用这个工具。

很多时候出于组织原因要去汇报，对标行业标杆设计系统的完整目录去依葫芦画瓢无可厚非。但是除非真的像ant design那样具有对外输出企业价值的产品使命的话，真没必要。

四、Design System可能牵涉到的工具

那我就献丑也说说最近也许和建立设计系统有关的工具的理解。真的很不喜欢提及工具，因为太多设计师都是盲目的工具控了，喜欢不停去“知道”新工具而非真正把工具当成成就自己的手段，还会时不时在别人提起xxx新工具的时候跳出来说那个yyy也可以云云。

Any way。Abstract，用于管理设计文件的版本、并让设计文件上云而驰名，但我最喜欢的还是shared libraries，至少设计层面内部真正统一了设计语言。嗯我知道蓝湖也有这个功能，当时看到蓝湖发布此功能也是佩服反应之快。如果会从零开始新项目的话我会尝试用figma，虽然是browser based但是性能出色，还真正做到了高度协同（那个高度是至少十层楼高）而且前端工程师可以无缝接棒，真正映射了互联网公司的设计流程而生的设计工具（某类）。

当然真正有用的设计系统还少不了像Stencil这种建立web element控件库的工具，才算完整。还有一直关注谜一样的终极杀器阿里出品Fusion Design。工具不重要，搞清楚需要什么工具才重要。不知道自己手头的活儿意义何在就会落得连工具都可以牵着你鼻子走了。

五、规划设计系统时需要考虑哪些点

1. 你的设计系统打算支持那些设计软件?

Sketch、Figma、XD，估计再偏门一点的就难以在讨论范围内了。是的，除了sketch还有人在用别的工具的。理论上团队已经在用的工具有哪几个就要做那几套的控件库。但是不得不考虑成本与成效的问题，因为这里所说的成本并不是一次性成本，设计系统是需要维护的，每一次维护成本的倍数都是你今天选择支持的软件个数。

个人意见是：其实三者实际操作概念大同小异，转换工具对于设计师个体成本不见得就十分大。而且买软件公司也是要钱的啊，为什么不统一就用一个工具，然后为此而开发组件库呢？Figma原生就是一个比较合适建立设计系统、团队协同，习惯了的话基本就是一个跨团队型的全流程工具。XD也是很强也许因为贵族基因吧，基本上每个月都有让人惊喜的更新。Sketch就不用说了，但是在2020的今天，不靠插件强大不起来的它是不是显得有点落后？

不是。请见what Sketch has planned for 2020。teams功能、字体优化、智能layout等等这些（虽然好像在XD早就见过了）明显是不耐烦想出王炸了。虽然工具只是工具，但是我始终认为对于一个团队甚至企业而言，工具映射了也引导着团队工作方式进而影响着文化（TMD又出金句了），所以建议好好比较差异，选一个最合适你团队的工具。这和统一度量衡是差不多伟大的事儿~

2. 应该支持什么代码技术？

对于前端技术，我连略懂都算不上，不过这几年因为需要推动事情落地也稍稍有了些认知。网页端主流框架React、Angular、Vue，移动端主流框架Swift、Java和React Native，实际使用起来对于设计的妥协程度要求都差不多。最理想当然是建立能够支持所有框架的控件代码库，但是同样由于开发成本与持续维护成本，明显这是不实在的。

最诡异的是在一些大团队里面，可能前端框架都不只只有一款，导致设计系统没有办法统一，或者说导致到同时“存在”了不止一套设计系统。据我了解这其实也算是不少团队的情况与历史原因，即便是不少国内外大厂也是有过这样的状态，要不就一直这么苟且下去，要么还是咬咬牙同一个了框架与控件库代码。

由于面对过不少这一类的问题，之前也花过些时间研究过网页端解决方案：运用像Stencil这样的工具就可以建立支持绝大多数市面上的主流浏览器的Web components，兼容不同的现存框架，节省重复开发工作。

3. 利用好开源资源

从零开始建立一切是玛丽苏电视剧剧情，尤其是你如果同时还对设计系统里面每个元素的可用性有比较高的要求。加上无论组织大小，公司希望能够尽快落地产品，团队、部门希望在使用了有效资源的前提下尽快作出有效输出。作为设计师的成长，一般都会有过纠结“我不想抄作业”的心情。但是理性应用现成资源、着力于差异点，平衡成本与产出，这些才是走向专业的标志。

如果你和以前的我一样对吃现有点排斥的内心戏，我建议好好平常心仔细学习一下吃现者最爱的Ant Design，尤其在新版（现在是4.x）的补充下很多里面的设计思路，虽然满满的通用性导向设计，但是逻辑、实施层面的周密与整全，俨然就是企业系统交互设计的教科书了。

另外同样具有教育属性的还有Material Design最近的升级。嗯嗯嗯我知道这些你知道，但是细读过了吗？暗暗告诉你，很多面试中的“必答题”，有正确答案的那些，都是就那几个题库里面来的。

在建立设计系统时，平衡好吃现的吃相与妥协的程度，最终保证产出有你的产品特色不是一件容易的事。我建议尽量使用开源资源让你能够保证带给公司与团队的价值最大化。差异化产品特色，来自于你通过调研与产品规划，不是你的设计（又有金句了）；可行性落地性？来自于你和前端工程师的沟通与合作程度。

六、建立好维护与修改机制

维护、修改机制比起设计库与代码库本身更加重要，甚至在建立好设计系统之后，维护、扩展，让设计系统活起来应该由专门的人员（设计+前端）共同负责，作为整个设计团队的核心工作，保证这套系统在产品开发过程中顺畅的使用而非給产品落地带来阻力。

这样的话就牵涉到这套系统需要有管理机制与负责人（组织）。设计系统的维护说来容易做来难，参考多少公司希望借鉴阿里巴巴建立强大的中台系统最后都落得只有假把式。殊不知阿里的中台系统背后是组织的上下变革的结果，能够让设计系统活起来其实也是要求能够在系统建立之后，一套落实到开发管理流程里面去的强管控机制。在为设计系统设定落地机制与流程之前，可以从搞清楚以下几个问题为起点：

1. 这是一套中心化管理的设计系统还是分布到各部组独自管理比较合适？
2. 里面的设计规范哪些是需要严守的、哪些是有宽容度的？
3. 设计系统不同部分的维护责任落在谁身上？
4. 设计师/前端工程师找不到需要的组件时，是否有快速先解决版本落地的机制？
5. 当需要增加组件甚至修改规范，审核机制如何？个人建议如果希望设计系统越有主导权，修改机制越应该严密。
6. 最后也是最重要，验收机制是如何落实的？

和世界上任何系统一样，实施机制比内容本身重要得多了。如果管理不恰当、同步做得不够好、统一调用不严格的话，哪天需要进行设计改版，那天就是你的设计系统的停用纪念日。

1. 设计系统的网站

是拿来干什么的？把设计系统当成是一个产品，那么它的用户就是设计师、前端工程师、系统维护组、新员工。当然如果这个产品还有更高一层的文化输出的产品任务，那这个讨论范围就更广了。

仔细分析这些关键用户的value proposition，你就发现其实这些“用户”与设计系统的interface大多不一定是设计系统的网站，设计师也许是平台上的shared libraries，工程师也许是github仓库。但是一个网站对于设计系统依然十分必要，是因为：一，那些“你懂的”的组织原因；二，任何人尤其是新人来了之后快速上手的中枢环节；三，设计系统的路标、建设环节的宣布渠道，包含使用说明、规则发布。

2. 高度自动化……目前好像还没有办法

聪明如你，肯定会发现，设计系统包含了那么多具体设计层面、代码层面的细节，而且应用角色有那么多，自动化与高度同步是很重要的。

坦率讲……本人目前没有任何明确方向完美解决这一个问题。但是有个提示是可以密切留意阿里出品的Fusion Design套装。当然，如果你用Figma的话，你会发现Figma‘s Embed至少是解决了同步控件至各端包括设计系统的宣讲网站。所以说Figma是为设计系统、协同而生真不是盖的。

所以……没了

本来想总结一下这几年建立或参与设计系统的一些些经验写这篇文章，写的时候也有借鉴一些最新的方法与技术手段，希望如果对需要接着做这件事的你能够多多少少起些帮助。

总的来讲，这依然是个在不停变化的行业，所以没有哪一套方法是能够算是被固化下来的：竞争环境的变化导致内部需求的变化，做事的方式就会由规整变得凌乱起来，然后时间又会慢慢沉淀出新规律。设计也罢设计管理也罢，本来就是需要永远解决新问题，而且会一直把认为自己已经懂了一切的人淘汰掉出圈。

设计的outcome也许会变得越来越无趣。但是让它继续有意思的应该是需要被解决的问题竟然具有越挖越复杂的被动属性。

作者：HaoH，公众号：haohuanggongzhonghao；个人网站：http://haosgoing.cn/

本文由 @HaoH 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议