Pekka Oskari Puhakka 反思设计系统变体膨胀与 LLM 治理潜力

大约八年前，我开始着手一个设计系统，几年后我有机会重新审视它。第二轮工作规模同样庞大，但人手却少得多。如今，在结束这项工作三年后，我终于准备好分享这段经历。

我的论点：

• 僵化的设计工具包是设计决策的缓存，随着需求不断演变，容易变得过时。
• 记录实践和边界使得维护一致性的责任落在设计师和开发人员身上，而他们往往缺乏权力。
• 管理 LLM 技能可能比仅依靠组件、代码或文档更能作为演进式设计系统的基础。

当我撰写第一篇关于设计系统的 Medium 文章时，我正处于一年期的工作中，致力于将设计系统扩展到更多以消费者为导向的业务领域。此后，我转去设计其他类型的产品和服务，也包括一些设计语言。在两次更换雇主之后，我获得了重返同一个设计系统下一版本工作的机会，而我在几年前曾停止参与该项目。这项额外的工作持续了 12–18 个月，此后它在我不太了解的情况下继续发展。几乎从那时起，我就一直保留着这篇文章的早期草稿，现在我已准备好将其完善。直到最近，借助最新的技术进步，我才认为找到了解决交付工作中最大挑战的方法：由于需要满足支撑性要求，导致变体过多，项目规模变得过于庞大。

我的第一阶段工作是关于将设计语言扩展到新的细分市场，第二阶段的任务则是将各种设计工具包整合为单一工具包。先扩展，再收敛。对于像我这样的设计顾问来说，这并不新鲜。

我之前为该客户工作所形成的概念帮助设计核心团队编制了一本“风格演进”手册，用于指导未来的项目，随后公司重组，该核心团队解散。此后，各业务部门在此基础上形成了各自的设计工具包，其中一些比其他更为先进。实际上，设计已分裂为多个设计工具包，每个业务部门都独自面向未来的基于云的软件。每个设计工具包都依赖于相同的早期核心令牌和设计驱动因素。与之前不同的是，现在有一个由来自各业务部门的代表组成的设计委员会负责设计决策，而不是单一的中央集权小组。

我个人很高兴看到第一阶段的成果得以延续。但与之前不同，似乎拥有单一代码基础真相的目标已被放弃，转而通过设计阶段来对齐工作。这感觉有些奇怪，因为他们转向基于浏览器的云应用程序，相较于之前基于 WPF、Angular 和 React 三种代码框架构建的嵌入式软件特性，本应更倾向于共享代码库。鉴于其规模和量级，仅仅关注设计方面可能看似是一条更容易走通的路径。但回顾起来，复杂的变体和复杂性如果在代码中管理会容易得多。尤其是现在，LLM 可以帮助起草其中的许多内容。

当我们于 2022 年开始整合工作时，时机尚未成熟。我们的任务是将各个独立的工具包手动整合为一个全公司统一的设计工具包。在不到一年的制作过程中，借助 DK&A 几位同事的帮助，我们最终设计并记录了约 40 个组件，这些组件可通过原生 Figma 库切换来实现主题化和模式切换。核心组件的结构被分发到每个设计工具包文件中，使整个系统更易于管理，但也容易出错。随着所有部分连接完毕，交付的整体结构虽然全面，但治理起来要求很高。我们甚至提供了组件的骨架模型，以便通过库切换进行类似处理。最终结果是组件数量可观，但每个组件都包含大量变体和属性（例如 Focus）。不是数百个变体，而是总共近两千个。

变体本身从一开始就是系统的支柱。要在 Figma 中处理多种不同的尺寸变体，你仍然需要多个资产来可行地应用这些值。这是导致工具包庞大的主要原因，而在代码组件中，这可以通过一组简单的令牌变量来解决。当我们启动项目时，Figma 已经具备布尔组件属性，可以简单地开启或关闭组件内的项目。在工作文件最臃肿的时候，它包含了约 4,000 个变体，而交付的设计工具包包含 1,786 个变体。减少了略超一半。随着排版变量于 2024 年 4 月推出（即在我们项目结束不到一年后），大多数尺寸变体本可以像令牌一样进行处理。仅通过使用变量来处理尺寸和排版变化，1,786 个变体本可以减少至五分之一左右。

在所有交付的组件中，最荒谬的例子是按钮。总共有 260 个变体。三种行为：默认、拆分和切换，全部分为 5 种不同尺寸，且每种尺寸具有不同数量的属性。其中只有 15 个需要真正思考：文本大小、间距、比例。其余 245 个只是算术运算。算术可以表达一个决策，但不能做出 决策。

并非所有约 40 个组件都同样背负着沉重的变体负担。有些主要可以通过布尔组件属性来处理，另一些则为了将 Figma 推向极限而变得复杂。我们甚至尝试了一个卡片组件，但由于子组件结构，最终被认为不适合扩展。回顾过去，如果将所需功能描述为提示词会容易得多，但这肯定会让我们错过一些在解决问题过程中令人难忘的时刻。

尽管如此，自那以后，我大幅精简了我所使用的设计工具包。从精益、渐进的角度进行思考，而不是试图将所有需求都硬编码进去。如今，组件可能非常粗糙，但其简单性使其能够容纳许多变体而不牺牲基本功能。Figma 随后推出了插槽（slots）：组件内几乎完全可编辑的框架，用户可以自由操作而无需干预核心组件。即使是之前被认为不切实际的卡片组件，也在几年后变得可行。

在项目期间，Figma 插槽（slots）还只是设想，子组件是当时的标准做法。这更多是一种技术限制，而非设计决策。如果当时能够采用更轻量的结构和更少的变量来处理这项任务，我那时也会倾向于这样的结构。这将要求文档在界定编辑边界方面承担更多责任，也要求利益相关者在管理这些边界时付出更多努力。有了 LLM 的参与，你可以将限制条件内置到某个技能中，但测试这些限制是否会比制作所需的变体更轻松？也许吧，但这需要验证。

用 Figma 原生的变量主题功能替代原生的 Figma 库切换，本可以大大减少系统文件的总数。我们之所以知道这一点，是因为 Figma 在流程中途发布了变量主题功能。我们对其进行了测试，但无法将系统转向使用该功能。此时已太晚，无法掉头并重新开始重构所有内容。在第三次迭代中，变量主题将是一个显而易见的选择。不过，骨架组件届时可能需要以不同的方式应用。我在质疑它们是否真的需要在 Figma 中得到支持。

对于设计委员会而言，真正的跨组织所有权对各个利益相关者及其沟通技巧提出了很高的要求。需要一种近乎利他主义的心态来做出决策，以克服否则自然形成的群体动态。全球设计委员会有效运作的另一个关键，是拥有一种共享文化，充分考虑不同时区、文化环境或日历惯例下团队成员的多样性。民主决策需要时间，因此不应将较慢的节奏视为问题。过快的行动和非整体性的设计选择随着时间推移会变成一团糟。由群体主导的设计始终是一个微妙的过程，因为设计师往往对自己的创作情有独钟。我也不例外。

我们是受雇进行实际整合工作的人，因此大部分决策最终掌握在我们手中。你需要深入解决挑战，才能拥有话语权。并且需要进行大量的游说，让利益相关者投入到设计决策中。尽管如此，这毕竟是整合工作，而在 2023 年，单一的设计套件只能以有限的方式进行调整。

尽管整合任务是一项挑战，但我绝不后悔做了这件事。从那以后，它塑造了我处理类似任务的方法，这一点我在之前的文章中提到过。凭借如今的技术可能性，我能够将所学应用到我的设计流程中。

事后已经有大量文章对此进行了论述，但我想用一个“如果……会怎样”来结束本文。从技术层面来说，我已经提到了几个 Figma 特有的更新，这些更新使得如今可以以不同的方式构建事物。但必须提出质疑：还有人使用 Figma 吗？阅读几乎任何设计师的 LinkedIn都会让人倾向于认为还有人在用。我长期以来一直认为，真正的设计系统只存在于代码格式中。其他任何东西都只是中间件。但如今，当代码和设计都可以即时生成时，代码是否只是众多输出格式中的一种？与 Figma 资产相比，它仍然更接近最终用户。但它还是唯一的事实来源吗？如果可以通过 MCP 使用 LLM 为任何给定的设计软件生成组件、布局以及设计资产，那么 LLM 是否应该被视为唯一的事实来源？需要另一个项目来重建现有系统以适应 LLM 时代，才能证明上述观点。如果不是为了同一个设计系统，也可以是任何其他规模相似的系统。你可以给我打电话。

接下来，我将回顾我的第一篇 Medium 文章，探讨设计系统如何成为最好的赋能者，而不是限制设计师解决问题的自由度。感谢我的前同事 Konrad Wysokinski 对本文进行事实核查，并感谢 Claude 进行的校对和思路碰撞。