「所向披靡」的设计系统
你做过设计系统吗？
如今，“设计系统”这一名词在圈里很火。 而大约七八年前（2013年左右），”设计系统“还默默无闻。
当时，以软件为服务（SaaS）的企业已逐渐意识到体验和用户界面对其商业的影响力，开始重视用户体验设计师的招募，“设计指南（design guidelines）”、“样式指南（style guidelines）”已开始进驻企业，将设计原则于前端代码相结合，让产品的设计及开发团队在用户界面的元素、样式、结构、组件及前端代码实现的一致性上达成统一。 这样的由设计师和工程师共同创立及维护，为产品团队成员在用户界面使用及应用上形成共识的“设计指南”和“样式指南”是“设计系统”吗？
我觉得是，只是那些年还没有人用“设计系统”称呼他们。
那些年，我们建立的“设计系统”
当时，自己正在给某企业级在线学习及绩效管理平台做用户体验设计及用户界面设计。 为了能快速让开发团队和新加入的设计师对产品用户界面构造达成一致，我和开发的一位 tech lead 协作，一起用 HTML、CSS、JavaScript（jQuery）构造了一套该平台核心产品的可用性指南“Usability Guidelines”，内容结构参考了当时的 Bootstrap。 这套指南当时是完全开放给公众，虽然主要是由核心开发团队使用，不过也会给到负责定制化服务的其他团队甚至是售前给产品加分。
曾经设计及维护的某企业产品可用性指南
那么，这样一套未被命名为“设计系统（design system）“ 的可用性指南就不是设计系统了吗？
大厂的设计系统
以 Google Material Design 为例
过去这十几年，大厂们诸如 Google 的各项产品的用户界面已经历了一轮又一轮的变革。这些年，直到 Google 的设计团队推出了 Material Design 并耗费数年强势应用在其所有产品之中，谷歌的用户界面设计语言才步入又一轮的稳定发期。记得当年 Gmail 的一版界面一度已十分成熟好用，但因为 Material Design 的强力应用，刚发生改变时的界面一度遭受批评。Material Design 的设计语言也伴随着产品的应用不断演化及微调以尽可能适应及平衡所有类型的产品，让他们在 Google Material Design 的语言风格下又散发着各个产品独特的味道。
2020年的 Gmail 收件箱界面
2011年时期的Gmail 界面，这个版本一度深入人心，后来应用了早期 Material Design 版本的Gmail界面一度遭受用户的强烈批评。图片来源：Official Gmail Blog: Changing information density in Gmail’s new look
2008年是 Gmail 收件箱部分界面及聊天窗口。图片来源：Official Gmail Blog: Tip: Edit contacts right from your chat list
单看 Gmail
就单一产品视角来看，一款产品在一个时期内始终都拥有着产品自身的设计系统。 无论这套设计系统是否被可视化成一份文档和各种格式的界面设计文档，这套设计语言及其应用的共识是存在于产品设计师、开发者、测试人员、产品经理等产品团队成员之间的。
就Gmail而言，我们能不能说早在2008年，Gmail 就有了一套自己的设计系统，只是随着 Google 这一品牌视觉的演进和平台层面的设计体系 Material Design 的建立，Gmail 将自己原有的设计系统和平台定义的新一套的设计系统重新进行了联结。
Gmail 一方面保留了其以用户需求为核心的网页界面布局和核心交互，一方面主要在品牌视觉和交互细节层面引入 Material Design，以期强化用户对 Google 这一品牌的品牌印象，又避免影响 Gmail 其已得到验证了的对用户友好的核心界面布局（例如将所有对话以聊天的形式叠加，以及星标记号的位置等）。
就 Gmail 自2007年至2020年的用户界面设计语言的演化来看，他们的区别更多的是在于品牌视觉传达及界面的视觉语言层面。而从真正影响用户是否使用这款产品的那些具有价值的功能来看，显然 Gmail 最核心的那些功能可谓始终如一。对于国人来说，QQ聊天软件也是如此。
对比 Google Material Design 体系下的其他产品
同为 Material Design，Google 家的其他产品界面可能有着很不一样的界面布局，但又秉承了同一套的设计理念和品牌界面视觉风格。
例如2020年的Google Maps，右上角的用户账号和产品切换入口与其他产品保持一致，但地图本身的用户的布局与 Gmail 大不相同
站在平台或者品牌的角度看，Google Material Design 这套设计系统不要求前端框架的一致，不要求页面布局统一，而是首先以用户使用需求和产品实现上来构思界面布局和框架，在更顶层（high-level）的角度去跟进这套设计体系，而不会就具体的组件样式要求达成一致。例如，2020年版的 Google Maps 的主搜索框和 Gmail 的主搜索框的界面样式及交互流程并不统一。
2020年8月 Google Map 的搜索框样式
2020年8月 Gmail 的搜索框样式
注：不看不知道，Gmail 的搜索框在前端实现上竟然还用了一个大 <table> 框住其主输入框。
然而，Google Map 和 Gmail 都应用了基于 Google 品牌视觉风格的 Material Design 设计系统。那么有没有哪些界面语言是一致的呢？ 有的，例如但看搜索框样式，我们可以发现两款产品在图标样式、字体选择和 input 的圆角度数上是统一的。
即便有如此的不统一，作为 Gmail 和 Google Maps 的老用户，在使用产品的过程中并不察觉同一UI设计模式在视觉和布局上的不一致为我的使用带来了不便。
若你是 Google Material Design 的设计负责人，你是否觉得值得花时间要求 Gmail 和 Google Map 设计团队将搜索框的搜索图标位置加以统一？抑或是你觉得既然当前的界面大体上符合品牌视觉规范，用户在使用不同产品时都能顺利完成任务，大可以给产品各自的设计系统以足够的灵活度。
设计系统宣扬的一致性是否会抑制创造力和灵活性？
就设计系统宣扬的一致性是否会抑制创造力和灵活性，前阵子读到了设计师 Mark Boulton 写的一篇批判性思考文章 The Ugly Truth about Design Systems 让我印象深刻：
“… once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. “
“的确，许多设计系统是制造和大规模应用的蓝图。但在我能想到的几乎每一个例子中，一旦你从设计转到制造，马就已经跑了。因为体系的结果是在野外，所以很难再进入设计。越是严格的系统，你越是无法改变它。这就是为什么宽泛的原则、足够的治理和方向性的例子远比锁死的饼干要好得多。当然，后者会让你在短期内走得更远更快，但前者会给你留下评估、迭代和创造的空间。”（硬翻）
-Mark Boulton
Ethan Marcotte 的文章 The design system we swim in by Ethan Marcotte 也能引发相关的思考。
Derek Shirk 整理了相关批判和思考，整理了避免rigid死板的设计系统的一些可能性：Less rigid design systems - Cloud Four
- 使用类似 TailwindCSS 那样的 sprinkling in a utility library 而非给 component 名字命名的 So you need a CSS utility library? | CSS-Tricks
创建一套设计系统模版作为其他产品设计系统的 starter kit？
想做一套类似 AntDesign 那样的通用设计系统及组件库，目的是解决其他产品设计和开发过程中设计系统从零开始导致的效率问题？
如果只是纯粹的UI设计练习或基于特定语言的组件开发，自己从零开始一套组件系统的设计并制定一套自己的设计语言规范确实是很好的一种练习方法。
然而，如果不是为了设计和开发练习，而是假设一两个月后你从零开始设计开发的一套设计体系能为开源世界中其他的设计开发团队用于新产品启动， 通过一套带有基础设计元素、UI组建的设计搞及特定框架语言的代码以期能减少流程中的工作量，这种假设能通过目标用户的验证吗？我对此表示担忧。
再回忆 Google Material Design 刚应用到 Gmail 时遭到的批评，及其之后数年持续快速的优化改进才获得了一个能够适应用户的版本。 即使是大厂推出的设计系统，一开始在真实的产品中应用测试也会出现反而影响了用户完成目标任务的问题。 那么一套缺少产品基础的设计系统，未经真实产品的使用验证来帮助自己认识到系统存在的问题，又怎么能够期望这一套壳就能节省另一款产品在设计层面的启动时间能？ 不过开发的部分在相关产品使用同一套框架时有可能有用，毕竟前端框架常常有坑。
再参考 Gmail 和 Goolge Maps 对 Material Design 的应用可以发现，这两款产品的用户界面核心布局并不依赖 Material Design，其UI设计模式的选择是基于产品对用户提供的价值以最大限度满足用户需求。 而在选择 UI 设计模式，例如 Google Map 的可展开收起悬浮面板时，还没到参考具体设计系统的时候。这个过程的关注点还是用户是否能够顺利完成任务的可用性验证。
也可以这么理解，如果今天 Google 放弃了 Material Design，而决定所有产品改用 BootStrap 5 的默认 UI 风格，Gmail 和 Google Map 依然可以像换主题一样把那些图标、字体、圆角度数和交互链接按钮的主色换掉。
也就是说，如果两个月后隔壁公司希望能够开始新产品的设计和开发，设计一开始要选择的不是一套通用的设计系统，而是用户界面设计模式（UI Design Patterns）来使其产品满足用户的使用需求以最大化其产品价值。 这个阶段的产出可以是手绘的线框图，也可以是低保真的原型。如果这时候你做了一套所谓的通用”设计系统“的设计稿，并附有 Figma 或 Sketch 版本，那么这套系统确实可以用于快速构建中底保真度的原型。但这样的系统是不是叫“模版”或“UI kick-off starter kit”更合适？
这个世界上已经有那么多的开源设计系统，比如 Material Design，你本就不必从零开始。 世界上本就已经有那么多没有版权问题免费使用的 UI Kits，你本就可以选择不从零开始。
而 UI Kit 的市场是一片红海，网上有大量耗费了许多心力时间构建的高质量的设计系统，如果走的是这片海，那就只有世界一流水平的 UI Kit 才能脱颖而出。如果产出物不够世界一流水平，那么它的影响力肯定很有限。
设计系统是用来达成共识的
数字化产品领域的设计系统就像传统图形设计行业的品牌视觉指南。 传统图形设计行业中的设计指南主要是让图形设计师和印刷工匠达成共识，即使一个老工匠生病了，那么新工匠接手统一项目时，只要参照这份指南，就能印刷出和老工匠一样质量一样标准的成品。
数字世界的设计系统也是一样，它让设计师和工程师以及与构建同一产品相关的其他角色都能对构建方法和指导思想达成共识。就好像室内设计装修，设计师定制好会议室需要哪些家具陈设及物件，装修师傅定好这些家具物件具体的组装方法，还可以给不同的房间一些个性化的主题，这样，即使几个设计装修小组同时开工，最后呈现出来的会议室也都照着业主一开始的预期进行及交付，保质又保量。
未来
如何正确理解设计系统的作用。若要提升产品设计开发的效率，我们需要的是是另一本设计系统模版，还是全新的能带来流程变革的工具和方法？我觉得是后者。
曾经构想过未来也许我们只需通过定义一组变量参数，就可以完成对核心组件设计规范的定义。这也是不少设计师曾经提出的 Design API 的思路。也许有那么一个平台，你只需要选择用色的色值，字体、字号的组合，即可预览全套UI 元素、组件并选择对应框架到出相关UI样式定制文件方便前端开发快速应用。
未来，对于设计师来说，可能需要更多的计算机式（computational）的技能来带来变革。无论 Figma 还是 Sketch，当那天到来时，他们可能都会成为曾经的 Photoshop。
希望你我能成为那个引领变革的人，而非依赖当下的那个人。
推荐阅读
关于设计系统和未来设计的思考
- The Ugly Truth about Design Systems by Mark Boulton (2019)
- Design systems and Postel’s law by Mark Boulton (2016)
- Building a design system… not just a UI kit by Christian Slegtenhorst - UX Collective (2018)
- The Renaissance Of No-Code For Web Designers by Uri Paz - Smashing Magazine (2020)
