设计系统如此例行公事，却又如此困难，真有点奇怪
用于软件 UI 的设计系统通常被视为在一致性和规模化方面必不可少，但许多团队发现它们出人意料地难以定义、构建和有效采用。评论者指出了反复出现的问题：对设计系统是什么缺乏清晰一致的认知、过度为未来灵活性做优化、把它当作静态产物而非不断演进的、由代码支撑的流程，以及维持其可用所需的组织政治与治理。有些人认为，当系统由经验丰富、跨职能团队领导，并以“强烈主张，弱持己见”的方式应用时，它们会很有价值；另一些人则认为，对许多公司来说，它们会变成官僚化、利用率低的负担，甚至可能限制优秀的产品设计。
什么是设计系统（以及不是什么）
- 很多人区分：
- 设计语言（视觉风格、品牌、规则）
- 设计系统（用于在规模化 UI 中进行管理的可复用实现与标准）
- 组件库（UI 代码）
- 有些人认为，设计系统是一种流程（“系统化地设计”），而不是一个固定的产物。
- 也有人批评那种含糊、抽象的定义，并更具体地把它看作是关于外观、内容和组件的规则。
为什么设计系统很难
- 核心问题是人和对齐，而不是工具。团队常常对设计系统是什么、它解决什么问题、以及它如何创造价值存在分歧。
- 经典权衡：优化灵活性 → 过于复杂、臃肿；优化速度 → 之后后悔并重写。
- 新产品总会碰到系统未覆盖的情况，从而产生例外和临时扩展。
- 治理和维护比最初创建更难；系统永远不会“完成”。
流程、治理与采用
- 当以下情况出现时，采用会失败：设计与系统不一致、贡献者不读或不信任文档，或文档已经过时。
- 有人表示，“贡献回去”的模式很少奏效；一个规模较小、资深且协同一致的团队往往能产出更好的系统。
- 过于僵硬的系统会变成官僚工具，扼杀创造力，并被用作一种粗暴手段去否定在具体情境下更好的设计。
- 也有人认为，约束和统一性恰恰是重点，尤其是在多个产品之间。
设计与工程视角
- 设计师和工程师都意识到，他们是在重新发现相似的系统设计问题（API 设计、微服务、网格、品牌）。
- 围绕代码还是设计文件才是真正“事实来源”存在张力；有几位认为，已发布的组件必须是主要来源。
- 一些设计师将设计系统视为“更差即更好”和为了节省成本而不是做“正确的事”的象征，因此心怀不满。
工具与实现方式
- Figma 因变体/变量而受到赞扬，但也被视为本质上仍然传统。
- Tailwind 在一些人看来是“几乎没有代价却拿到了大部分收益”，但也有人说它只是一个 CSS 框架，不是设计系统。
- 强烈建议基于健壮、以无障碍为重点的基础原语（例如 Radix/React-Aria 的对应方案）来构建，而不是重新发明基础组件。
- 将系统集成到遗留产品中被描述为尤其痛苦。
何时需要设计系统
- 有些人认为，设计系统只有在较大的组织或多个活跃产品中才真正必要；在小团队里，它们可能是一种“组织异味”。
- 成功似乎需要资深人才、跨学科所有权（设计/工程/产品）、可访问的默认方案，以及文化变革。