现在市面上的公司无论规模如何，都或多或少有设计系统或者组件库。 今天这篇文章属于吐槽，咱们来聊一聊关设计系统的那些糟心事儿。
举个例子，假如说我们是景德烧陶瓷的工匠，咱们设计师负责画瓷瓶的设计图，下游工匠负责做出来。一开始订单少，设计师在纸上画好瓷瓶的三视图然后工匠手工拉胚做瓶子，所以做出来的瓶子大小、高度、薄厚都不一样。但后来厂子效益好，订单激增，于是工匠就来商量：我看你们设计师画来画去，画出来的瓷瓶器型差异也不大，就那两三种。与其一个个手工拉胚，不如咱确定几个器型做成模具，咱们工匠直接灌模，这样既做得快。
这几个瓷瓶模具就是我们的组件库。把常用的几种花瓶样式做成模具，也就是我们把设计模式打包成组件，开发可以用灌模（代码复用）的形式提高产出效率。
构建组件库：
之后这个瓷器厂又继续经营，老板一看几个设计师天天加班，效率也挺低啊。那些低质量生产线的瓷器就不要占用设计师的时间，让设计师出几个简单花样教给工匠，工匠自己看着做就行，匀出来的空闲设计师就专心设计几个精品器卖高价。另一边，设计师的技能水平差异很大，没经验的设计学徒设计的瓶子总是把手位置不合理、瓶子薄厚也不合理，导致受热不均匀也不好用。因此老板让老设计师把自己的设计思路总结出来，集合成册，方便设计学徒照葫芦画瓢、检查自己的瓶子是否好用。
老设计师总结出来的花样图纸，就是我们的设计系统。把花瓶图案（也就是App开发中的颜色/字号/间距…）、设计思路（也就是交互规则）总结出来，既是为了方便设计内部或缺少设计经验的其他角色快速产出设计，也是为了瓶子的用户能获得品质稳定的产品。
从上面的案例可以看出来，设计系统的目的有二：
- 设计系统（或者组件库）首当其冲的、最基本的目标是提效，并且是研发提效。
- 另一个目标则是：统一设计决策、帮助用户建立稳定的用户心智。这个目标是设计经常吹嘘自己达到了、但往往很难做到的。
针对第一点，首先我们要清楚新组件的设计周期和开发周期都很长。假如暂时不考虑开发上的事情，大家可以试试在没有组件库的情况下写清楚一个下拉菜单的所有用例试试。
- 字段最长怎么展示？
- 最短怎么展示？/为空怎么展示？/不能选什么样式？
- 最多选几个？
- 加载中什么样式？
- 一次加载多少个？
- hover/选中/禁用/focus 怎么展示？支不支持键控？
- 哪里是选中热区？
- 按什么顺序展示？选中了的顺序是不是会变？
- 没选怎么报错？
- 状态切换什么动效？
……
正是因为在没有组件库的情况下调用组件这么麻烦，所以应用了组件库以后，最立竿见影的效果就体现在开发效率提升上。在设计师没有额外说明的情况下，开发可以直接拖组件库组件，组件什么样交互设计出来就是什么样子。一个需要 50PD 的项目在接入组件库以后，25PD 就可以完成，开发需要的时间大大缩短，设计-开发之间的沟通效率也大大提高。因此从这个角度来说，组件库的建立是绝对有必要的。
然而做到这一步充其量只能证明在开发实现的角度上来说有组件库比没有更快，作为产品设计，我们更关心的是从用户的角度上来说，一致的设计系统是否对用户体验更好？或者换句话说，假如用户就是喜欢每个页面都不一样，那么开发实现也一定会顺应用户诉求——我们肯定就不做组件库了。
针对设计系统与用户心智的讨论在 70～80 年代就有了成型结论。引用 1985 年版的苹果人机交互手册，标准的、一致的用户界面一方面可以减少用户记忆、提高软件的易学性：“…假如用户已经知道了一些功能是如何运作的，那他们就不需要去记忆一个新功能的用法。通过使用标准的人机交互界面，你的用户可以不需要记住界面上的任何东西。”
另一方面，用户在逐步探索产品的途中，会逐渐形成一套关于如何操作产品、产品会产生什么样反馈的心智模型，然后用户就会用这个模型去预测产品中其他功能的用法。比如你的用户一上来使用了“增加”功能，那么他就会推测“修改”功能和“增加”功能的操作方法是一致的。因此，一套稳定的概念模型或者说设计系统可以很好地辅助用户形成稳定的心智模型，对于一些操作复杂的产品来说，稳定的心智模型就代表着更好的易学性甚至用户粘性。
所以这就引出了设计系统的第二个目标：统一设计决策，建立用户心智。这个目标虽然不如提升开发效率一样立竿见影、可测量，但我认为它是我们做设计系统的终极目的。既然我们知道了做设计系统，短期是为了提效，长期是为了用户价值，那么接下来我们就可以去讨论一个没能达到这些目标的系统都踩了什么大坑。
大多数组件库或设计系统之所以“糟糕”，是因为没有达成第一个“提效”目标，这主要是由两方面原因导致的：缺乏前期沟通和缺乏反馈机制。
1. 缺乏前期沟通
假如我们将“设计的工作范围”作为我们这个“设计系统”的边界，那么我们就需要注意到设计系统的信息输入是来源于设计部之外的，输出也是应用于设计部之外的。因此我们需要意识到，设计系统的产生绝对不可能是一个设计一头热就能完成的事情。与业务方（这里的业务方可能是产品，也可能是将来会使用设计系统的其他设计师）与开发仔细地沟通设计场景，是一件和设计执行同样重要的事。
组件库的搭建不能一步到位，除了字阶/主题色/间距这种非常基础的样式规则，我们需要优先支持哪个组件样式？能够覆盖哪些最基础的场景？这些东西需要提前归纳和沟通。换个说法，设计系统或者组件库的搭建，不是一个借鉴/移植的过程，这个过程不仅需要一些经验判断，更需要项目组织推进的能力。我见过的失败项目中，总是在组件库 1.0 阶段派两个实习生把 ant design 重新描一遍，这样做会导致组件库上线后要用的组件没有，没用的画了一大堆。
2. 缺乏反馈机制
严谨的设计系统和千奇百怪的业务需求之间的关系有点像一个具有反馈回路的系统，设计系统的健全、设计效率的提升当然能促进业务发展，业务发展又带来了不同的尝试方向和需求，这些需求又不断推动着设计系统的不断完善。或者咱们用更浅显一点的比方，业务需求和设计系统之间的关系就像“小孩穿鞋”，小孩在成长期时，鞋总是稍微大点/小点没什么关系；但本质上来说只有鞋适应脚，没有脚适应鞋的道理。你给小孩买鞋，不可能只买一个码数就解决了，肯定得随着小孩的成长不停地买新的鞋。
做设计系统也是一样的，它不是一个做一次刷完 KPI 就万事大吉的任务，也不是给其他的设计定规矩/用规矩划分地盘，而是一套需要不断迭代更新的动态规范。业务发展中出现了什么共性的东西，或者之前规范中没有覆盖的、不允许覆盖的东西，都应该及时地评估测量。这就需要在 1.0 阶段的基础组件库完成后，及时建立合理的反馈机制。这种机制可以落实为每周讨论设计系统的一些细节的对齐会，也可以考虑做成 ant design 那样开放收集反馈的交流群。在建立完基础库之后，根据业务诉求持续迭代、扩充“业务组件”，也是比较好的工作方式。
一套能够提效的组件库已经达到了及格线，但距离设计系统的终极目的：体验价值，还要走很远。我认为国内的大多数设计系统暂时还没有做到，所以在这里更多的探讨我们未来能够怎么做，希望做到些什么。
1. 缺乏交互说明
大部分设计系统是从 UI 做起的，因为视觉元素上的一致对体验一致性的贡献很大，效果也很显著。但是不是我们停留在视觉样式上就可以了呢？对于一些形态简单、核心功能突出的产品来说也许是的，因为它们的学习曲线很平滑，有些不一致也不影响用户当场就学会了。但对于很多功能复杂的产品大家庭来说，视觉样式一致是远远不够的，除了视觉一致性之外，还需要考虑控件应用场景的一致性、流程的一致性、概念的一致性等等，而这些东西都需要设计师去整理、定义。
初学交互的人可能对于控件缺乏理解，感觉“控件”就好像是界面设计中固有的一些规矩，微软/苹果这样的平台级规范说的就绝对正确，直接日常遵守即可。但实际上从我之前几篇文章中也能看出来，互联网/软件设计中控件的产生和应用也是有潮流、有趋势、有变化的，存在很多暧昧的、模糊的地方，不是黑白分明的。所以咱们看一些开发企业级软件/对技能要求很高的工具型软件的公司，比如我们熟悉的微软/IBM，那个设计系统都写得啰啰嗦嗦、逻辑极多，这也是为了在复杂场景下保证体验的一致性。
2. 缺乏价值观
缺乏价值观的设计系统不过是一个控件超市。“价值观”是个很主观的事情，我说得没有别人好，所以引用一句话：“（设计价值观是）系统地思考产品的价值系统和理念原则，抵御各种削弱产品价值和理念的尝试”。这句话出自我很喜欢的一本书，叫《硅谷设计之道》。非常推荐大家看一看。
日常工作中总是会有一些设计团队容易在一些细节问题上争议很久，美其名曰“打磨设计”，但我认为就是一种设计价值观的缺失。比如假如用户没有填写完表单，那么表单的提交按钮能不能按？是置灰好，还是按了以后再报错好？大表格里的批量操作到底是露出来还是收起来？文案里到底是称呼用户为“你”还是“您”？
这些问题都不是对与错的问题，而是我们的设计系统到底认为什么东西重要、什么东西没那么重要的问题。比如说加入我们做一个主要用户为老年人的系统，“明确/易理解”一定比“简洁”重要。映射到界面上，那就是界面肯定丑，字大颜色艳，保证用户能看懂。因此我觉得大家在做设计的时候也可以跳脱单点的设计体验点，从产品的层面来说设计的价值观是什么？设计系统也是一种系统，而从系统角度得出的解决方案是偏长期的、综合的方案，它在单个设计细节中也许不是最优解，但从整体体验上来说是一致性更好的。
