「人人都是产品经理」了解 Design System，看这篇就够了( 二 )

设计系统真做起来了之后怎么办？多出来的人力怎么办，难道裁掉吗？在这一步之前，还有很多让员工如沐春风朝气蓬勃并且对产品有大裨益的事可以做的，例如多出来的设计人力做用户调研，前端技术日新月异随时掌握了个降维打击的新展现层技术让你的产品鹤立鸡群也不是没可能。
但是设计系统不是一个解决了有和无就完事儿了的组织层面任务，如果不因地制宜去做肯定是无用功。我保证牢骚发到这一行字为止。
这几年新的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的今天，不靠插件强大不起来的它是不是显得有点落后？