工程师最爱的Figma设计，反而不是“好看”的那种

在Figma Config 2022上，一位做了5年前端、刚转行6个月的设计师抛出一个反直觉观点：真正被工程师喜欢的设计，核心不是美，而是“结构”。这场演讲把设计与代码的边界拆开重组，对所有做AI产品、工具型软件的人尤其刺耳又受用。

工程师讨厌的不是设计，而是“无法落地的美”

演讲一开始，Kazuya Seki就亮出了自己的“非典型”背景：5年前端工程师，6个月设计师。这不是自我介绍，而是立场声明——他站在工程师这边看设计。他抛出的第一个反直觉点是：很多设计看起来很棒，但工程师并不喜欢，因为它们只解决了“看起来对”，没有解决“怎么实现、怎么改”。在工程世界里，最致命的不是不好看，而是不可维护。设计如果只服务视觉，而没有清晰结构，本质上就是在给工程团队制造设计债。

自由设计 vs 结构化设计：两个目标，完全不同的命运

Kazuya引用了Figma Schema Conference的一个重要区分：自由设计（Free-form）和结构化设计（Structured）。自由设计的目标只有一个——验证UI想法，快、灵活、不考虑后果；而结构化设计的目标是传递设计意图，并且能被长期维护。很多团队的问题在于：用自由设计的方式，去做需要长期维护的产品设计。结果就是设计稿好看，但没人敢动。对AI产品来说尤其危险，因为模型、交互、策略都在高速迭代，如果设计本身不结构化，每一次小改动都会引发连锁灾难。

设计意图不是一句话，而是四个“可被读取的信号”

Kazuya把“设计意图”拆成了四个工程师真正关心的部分：视觉属性、布局、响应式和状态。第一，视觉属性必须精确到可读，哪怕一个行高不一致，都会在实现时引发边距冲突。第二，布局要像代码一样分层，避免反模式，比如没有逻辑的间距。第三，响应式不是事后补丁，而是通过约束和自动布局提前表达。第四，状态——空态、加载态、错误态——如果不在设计中明确，工程师只能靠猜。这里有个金句值得记住：设计不是让人“看懂”，而是让工程师“不用问”。

不会写代码的设计师，正在错过Figma的一半价值

演讲中最“刺”的观点之一是：学习写代码，是成为好设计师的捷径。原因不是要你转行，而是Figma和前端共享大量心智模型——Auto Layout就是Flexbox，约束就是响应式规则。真正验证设计清不清晰的方式，是你能不能自己实现它。即便不亲自写代码，也要通过工程师反馈不断校准。对AI从业者来说，这点格外重要：当你的产品逻辑高度依赖状态流转和系统行为，设计如果不系统化，模型能力再强也会被糟糕的交互拖垮。

设计系统不是装饰品，而是对抗变化的武器

为了“好改”，Kazuya把话题引向设计系统。核心不是组件库有多全，而是设计是否被拆解成可复用的设计Token：颜色、间距、字体这些不可再分的最小单元。通过像Figma Tokens这样的工具，把Token以JSON形式导出，设计和代码才能真正同步。组件和Variants的设计方式，也应该像前端组件一样，有明确职责和可预期行为。最重要的一点是：不要试图把一切都画进设计稿。有些东西，用注释、用当面沟通，比复杂原型更高效。

总结

这场演讲的价值不在于技巧，而在于视角的转变：设计不是交付物，而是系统的一部分。对AI从业者来说，这意味着三件事：第一，把设计当成“可维护资产”，而不是一次性展示；第二，用系统化思维对抗产品和模型的高速变化；第三，尽早、持续地和工程师共建设计，而不是在交付时才“扔稿子”。如果你的设计改一次就让团队头疼，那问题不在执行力，而在结构。真正让人爱不释手的设计，往往安静、克制，但极其耐用。

关键词： Figma， 结构化设计， 设计系统， 工程师体验， AI产品设计

事实核查备注： 需要核查：演讲者姓名Kazuya Seki拼写；Figma Config 2022时间；Schema Conference对Free-form与Structured设计的定义；Figma Tokens插件是否支持JSON导出。