当 Figma 开始为我们设计

我第一次接触 Figma 是在 2013 年，当时 Dylan Field 在 O’Reilly 的 Foo Camp 上向我演示了一个早期原型。我记得钢笔工具感觉很出人意料地优雅，但我错过了大局：一个在浏览器中运行的工具对设计产生的深远影响。十年后，Figma 成了我们创意流程的核心部分，没有它，我们不可能建立一套完全远程的设计实践。这或许就是为什么 Dylan 成了近乎亿万富翁，而我却没有。

然而，在过去五年里，我越来越担心 Figma 正在通过推动设计师以工程为中心的工作方式来改变设计领域。这一点可以从他们的功能发布中看出：智能组件、变量、自动布局和交互原型。这些功能通常被赞誉为向工程领域看齐的步骤，但在实践中，它们鼓励一种工作模式，这种模式在应该扩展可能性的时刻反而缩小了可能性。

一个具体的例子是 Auto Layout。最初在设计工具中引入类似 DOM 的布局机制似乎并无害处，而且对于结构很少变化成熟的 design 文件来说，它确实有优势。但如今，许多设计团队从一开始就使用 Auto Layout 来创建其数字产品的全页设计。实际上，这会固定设计并严重限制可能的表达方式。你无法自由地拖动元素或尝试不同的布局组合。你无法简单地将某物粘贴到框架中而不让它自动吸附到底部。结果是，设计师在探索的最初阶段被迫像工程师一样思考，而此时他们本应自由、随意地工作。起初可能会觉得方便，但它是有代价的。你有没有打开过 Figma 文件，试图做一个小改变，结果却要和布局搏斗？我遇到这种情况的次数比我愿意的要多，而且这似乎越来越频繁。

另一个功能是开发者模式，理论上它是设计规范和技术实现之间的缺失桥梁。然而，它强制了一种思维模式，即设计师远离他们所设计的技术来打磨设计，并花费大量时间构建复杂的原型，而这些原型最终会被丢弃并在代码中重新构建。所有这些都是在为开发做好准备的名义下完成的。这与我的信念相悖，即任何数字设计过程都应从粗略草图开始，但迅速进入代码并从那里迭代。这些草图甚至可能是在代码中完成的。设计永远不会“准备好开发”，因为我们所认为的设计决策——交互、动画、数据加载——实际上只能通过代码进行原型设计。“准备好开发”意味着创作已完成，而开发者仅仅是执行设计师的愿景，这隐含地阻止他们在实际操作时质疑任何决策。

这些都是两个例子，但它说明了令人担忧的趋势走向 设计过早优化。这些功能鼓励设计师进行 过早做决定，在想法有机会之前就过度结构化它们 展开。结果是设计空间的缩小，灵活性 用于创意发现的需求被强制的统一所取代 结构。这除了令人难以置信的数量之外，还带来了 structured tasks 大多数现代设计团队都遵循这一点。这不可避免地导致 数字设计领域日益增长的单一文化，其中所有事物开始看起来和感觉 相同，不是因为共同的意图，而是因为共同的限制。

我过去15年里一直倡导设计师和工程师之间更深入的协作，因此批评一个能拉近这两个学科距离的工具似乎有些矛盾。但跨学科工作并不意味着思维方式的单一化。目标不是让设计师采用工程实践，而是通过跨学科协作方式带来不同的视角。

Figma 非常强大，但它正将我们引向一种优先考虑结构而非灵感的协作方式。作为设计师，我们应当警惕这种转变，并非因为 Figma 本身不好，而是因为它所蕴含的价值观可能在潜移默化中重塑我们的工作方式。最好的设计工作很少从秩序开始。它始于问题、始于探索、始于大量的混乱。我们需要能容纳这种混乱的工具。因为如果从一开始一切都被整齐排列，我们或许永远无法发现网格之外隐藏的奥秘。