什么是 Design System？
- 文章發表於
前言
还记得那是我大学刚毕业不久，进入职场的第一份工作。当时公司前端团队还在草创阶段，整个团队就只有主管和我这个刚入行的菜鸟，两人得一起应付四面八方涌来的需求。那时的我对产品开发几乎一无所知，连“套件”和“前端基础建设”是什么都搞不太清楚。没想到入职场的第一个任务，就是开发一套后台发券系统，对当时的我来说，简直是一场地狱级的试炼。
拿到设计稿后，我没多想就埋头开始“刻画面”，反正画面能跑出来就好。那时的我复制粘贴的功力堪称炉火纯青，完全没意识到 JavaScript 早就支持模块化（import / export）。自信满满地完成第一页后，我把程序交给主管审阅，只见他脸色瞬间铁青。心里可能在想：“我是不是招错人进来了？”
所幸当时主管没有直接请我回家吃自己，仍不厌其烦地耐心指导。他建议我在项目的代码中建立一个 /components 文件夹，将像按钮、输入栏这类会重复使用的界面组件拆开模块化，方便统一管理。再通过组件展示工具 Storybook，集中呈现这些组件，让设计师在对稿时也能更方便地检视确认，省去了比对相同组件的时间。
项目完成后有种升级的感觉，当下真的觉得超酷！这是我第一次接触模块化，也第一次学会使用 Storybook。虽然整个过程在 UI 对稿上踩了不少雷，进度硬是拖了两倍时间，还被测试团队抓出上百个 bug……但那又是另一段荒谬又精彩的故事了。
几个月后，我参与了团队的组件库建置，从原本只有四、五个共用组件，扩展到二十多个。这段经历让我真正理解，一个“好用的组件”不是写完就好，它需要反复与设计师协作调整，更重要的是，其他工程师要能够无痛使用，才能真正发挥它的价值。
当然，要说服产品经理和设计师不要每个项目都从头设计，同时又要让组件具备弹性与可扩充性，是另一项挑战。而设计系统，正是解决这些问题的解方。
什么是设计系统？
"A design system offers a library of visual style, components, and other concerns documented and released by an individual, team or community as code and design tools so that adopting products can be more efficient and cohesive.
这段出自 Nathan Curtis 对于设计系统的解释，也是最贴近我对设计系统的定义，Design System 包含了品牌价值、设计原则 (Design Principles)、设计标签 (Design Token)、组件库 (UI Library)、设计模式（Design Pattern）以及可访问性，而最终的目的是为了让产品的开发更有效率，并且提供一致的用户体验。
如何设计一个设计系统？
| 没有一个设计系统可以解决所有问题，只有适合自己团队的设计系统。
设计系统从来不是一蹴可几，它往往需要经历多次迭代与调整。对于初创企业来说，设计系统甚至可能根本不是当下的必要，除了文化上倾向快速迭代，更多时候是因为产品规模尚未成熟。如果在这个阶段就贸然投入设计系统的建置，往往会因应产品需求不断修改设计系统本身，反而拉高了人力维护成本。
设计系统真正的价值，通常会在公司发展到一定规模后才逐渐显现。想象一下，当团队人数增加，不同工程师可能在不同页面上实作出风格不一致的按钮或组件，不仅造成视觉上的混乱，也会让后续品牌更新变得更加困难，甚至需要额外投入大量人力重新整理样式。
虽然每间公司或团队所需要的设计系统架构都不尽相同，但仍有一些共通的基础可以参考。根据 InVision Design System Handbook 中的建议，我们可以从以下几个角色与步骤着手：
- 谁应该参与设计系统的建置？
- 设计师：负责定义整体视觉语言，从色彩、字体到按钮、输入框等界面组件的样式。
- 前端工程师：负责将设计转化为可重用的组件，并封装成模块供团队使用。
- 产品经理：负责掌握产品方向，确保设计系统能够支持实际业务需求。
- 无障碍设计专家（Accessibility Specialist）：确保所有组件皆符合可访问性标准，提升整体使用体验。
团队要如何设置？
根据 Jina Anne 的 The Salesforce Team Model for Scaling a Design System 的文章提到，
设计系统的团队可以分成三种模型，分别是孤立式 (isolated model)，集中式 (centralized model) 以及分布式 (distributed model)。
孤立式: 团队刚成立时，这种模型最为常见，因为通常人力只够有一个人负责开发设计系统，优点是快速以及不用太多讨论就可以弹性的调整，缺点是可能会因为人力不足而忽略设计系统的维护。
集中式: 这种模型是将设计系统的维护交给一个专门的团队（通常是前端基础设施团队)，优点是可以专注在设计系统的维护，缺点是不像那些直接参与产品开发的人那样了解客户的需求。
分布式: 最后是分布式，让不同团队的人员一起参与设计系统的维护，优点是产品端的开发者通常有更好的用户洞察力，可以建立更符合用户需求与体验的组件，缺点是可能会因为不同团队的人员不一定会有足够的时间贡献在设计系统上。
让设计系统可以符合公司的品牌价值
大多数的公司都会有该公司的品牌价值，而这个品牌价值就会反映在设计系统的视觉元素上，其通常包括颜色、字体、间距与动画。
例如 Shopify 的 Polaris Design System
又或是 AWS 的 Cloudscape Design System
如果有时间，不妨实际看看这些设计系统的展示，会更清楚“视觉元素”与“品牌价值”如何构成设计系统的基础。设计师会根据这些视觉规范设计各种组件，前端工程师则负责将它们落实在产品中。
建立 UI Library 以及建立设计系统的文件
在完成前置作业后，下一步就是建置 UI 组件库，将可重复使用的组件模块化。其中“原子设计（Atomic Design）”是业界常用的架构方法之一，从最小、不可再分的组件出发，逐步组合出更高层级的结构。这些小组件就像乐高积木一样，最终组合出完整的页面。
原子设计就是将组件分成五个层级，分别是原子 (atoms), 分子 (molecules), 组织 (organisms), 模板 (templates) 以及页面 (pages)。
最后，需将设计系统完整文件化，明确记录设计规范、设计标签（Design Tokens）以及现有组件。有了这些文件，团队成员能在开发过程中快速对齐，加快实作效率，并维持一致的用户体验。
延伸阅读
