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

不是。请见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最近的升级。嗯嗯嗯我知道这些你知道，但是细读过了吗？暗暗告诉你，很多面试中的“必答题” ，有正确答案的那些，都是就那几个题库里面来的。
在建立设计系统时，平衡好吃现的吃相与妥协的程度，最终保证产出有你的产品特色不是一件容易的事。我建议尽量使用开源资源让你能够保证带给公司与团队的价值最大化。差异化产品特色，来自于你通过调研与产品规划，不是你的设计（又有金句了）；可行性落地性？来自于你和前端工程师的沟通与合作程度。
六、建立好维护与修改机制
维护、修改机制比起设计库与代码库本身更加重要，甚至在建立好设计系统之后，维护、扩展，让设计系统活起来应该由专门的人员（设计+前端）共同负责，作为整个设计团队的核心工作，保证这套系统在产品开发过程中顺畅的使用而非給产品落地带来阻力。
这样的话就牵涉到这套系统需要有管理机制与负责人（组织）。设计系统的维护说来容易做来难，参考多少公司希望借鉴阿里巴巴建立强大的中台系统最后都落得只有假把式。殊不知阿里的中台系统背后是组织的上下变革的结果，能够让设计系统活起来其实也是要求能够在系统建立之后，一套落实到开发管理流程里面去的强管控机制。在为设计系统设定落地机制与流程之前，可以从搞清楚以下几个问题为起点：这是一套中心化管理的设计系统还是分布到各部组独自管理比较合适？里面的设计规范哪些是需要严守的、哪些是有宽容度的？设计系统不同部分的维护责任落在谁身上？设计师/前端工程师找不到需要的组件时，是否有快速先解决版本落地的机制？当需要增加组件甚至修改规范，审核机制如何？个人建议如果希望设计系统越有主导权，修改机制越应该严密。最后也是最重要，验收机制是如何落实的？