Figma 创始人 Dylan Field：探索创意迷宫、氛围编程与"锁定"的力量

摘要

本期 YC 对话邀请了 Figma 联合创始人兼 CEO Dylan Field，深入探讨了 AI 时代设计的未来、Figma 的创业历程以及从零到一的关键决策。Dylan 认为，随着 AI 让软件构建变得更加容易，设计的重要性反而上升——设计将成为软件差异化的关键。目前 AI 仍属于工具范畴，其作用是"降低门槛、提升上限" (Lower the Floor, Raise the Ceiling)，让更多人参与设计的同时也让专业设计师能做到更多。他提出了"创意迷宫" (Idea Maze) 的概念：AI 带来更广的探索面，但深入探索仍需人类判断力和共情力。对话还回顾了 Figma 从 2011 年构思、历经迷因生成器、照片编辑器等多次试错到最终聚焦设计工具的曲折历程；分享了首个客户的故事、实时协作功能引发的社区争议与最终认可；以及在产品市场契合 (Product-Market Fit) 后应加速招聘等关键经验。Dylan 强调，创业者的核心循环是：自我觉察当前最常做的事，然后用资源替换自己，不断迭代。

正文

AI 时代的设计：工具而非替代

对话开篇，Dylan Field 与主持人探讨了 AI 对设计领域的影响。Dylan 认为，当前 AI 仍属于工具 (Tool) 的范畴。无论是设计师、开发者还是其他角色，人们都在用 AI 做更多的事、探索更多的可能性。Figma 的理念是"降低门槛、提升上限" (Lower the Floor, Raise the Ceiling)——让更多人能参与设计过程，同时提升专业设计师能做到的上限。

Dylan 提出了"创意迷宫" (Idea Maze) 的意象：在设计过程中，你沿不同的分支路径探索，在产品旅程中不断构思和迭代。AI 现在带来的是更广的探索面，但完全深入探索仍需要大量的深度。目前我们仍处于"恐怖谷" (Uncanny Valley) 阶段——你可以做"提示词到应用" (Prompt to App)，但生成的应用在设计上并不出色。

"锁定"与"氛围编程"：快速迭代的心流状态

Dylan 注意到人们正在使用一种新的语言："你锁定了吗" (You're locked in)、"我在烹饪" (I'm cooking)、"氛围编程" (Vibe Coding)。他意识到，这些词汇反映了快速开发时的一种特定感受——与工具之间始终存在一种呼应关系，你试图把脑海中的东西呈现到屏幕上，快速迭代。反馈循环越快，你就越容易进入心流状态 (Flow State)，也越有趣。Figma 的公司价值观之一就是"玩" (Play)——无论作为文化还是产品，都要让 Figma 使用起来有趣，让人能创造性表达。

但 Dylan 也指出了关键的脱节：当前的工具让你能快速开始和原型化，却不一定能帮你到达终点。这种脱节不仅存在于设计，也存在于编程——你可以"锁定"三小时做出一个很酷的东西，但它是否是你想要的设计？大概率不是。而且从原型到可扩展的产品，还需要理清代码库中"意大利面条"般的混乱。

设计的重要性不降反升

主持人担忧 AI 时代创始人可能不再足够重视设计。Dylan 分享了他的观察：年复一年，人们对设计的重视程度不断上升，也越来越理解设计的价值。这不仅仅是"能不能让它工作"的问题——能让它工作的人太多了。当人们能更快地制作东西时，"它如何工作" (How it works) 才是真正重要的。

Dylan 还分享了一个有趣的观察：如今自称开发者的人，在不久的将来可能会自称设计师。这不意味着他们不写代码，而是他们会更全面地思考产品体验。

图像扩散 vs 代码生成：设计模型为何仍未突破

当被问及图像扩散模型 (Image Diffusion Models) 与代码生成 (Code Gen) 两种路径哪个更可行时，Dylan 援引了他喜欢的设计定义："设计是应用于问题解决的艺术。" (Art as it applies to problem solving.) 在"艺术"一侧有扩散模型，在"问题解决"一侧有大型语言模型 (LLMs)，目前还不清楚如何将两种技术有效结合。

设计师的工作远不止解决一个两维问题——他们进行大量用户研究，从第一性原理思考用户的需求和感受，考虑当下的文化时刻 (Cultural Moment)、用户所处的情境和体验阶段，将所有因素整合映射。Dylan 目前还没有看到模型能够将所有这些不同组件整合在一起——它们缺失了设计师的"共情" (Empathy) 这一块。

"超级智能烤面包机"与人类主体性

Dylan 提到，他与一些 AI 研究人员交流后了解到，尽管在扩展定律 (Scaling Laws) 上不断攀登，模型仍未展现出类似人类的主体性 (Agency)。研究人员形容模型更像"超级智能烤面包机" (Hyper Intelligent Toasters)。Dylan 认为这正是机遇所在——人类设计师需要理解人的需求、目标和奖励函数 (Reward Function)，然后创建与之匹配的用户界面和用户体验，完成待办任务 (Jobs to be Done)。工具的作用是赋能设计师，移除摩擦，让他们拥有快速反馈循环。

交互界面的未来：超越提示词

Dylan 表示他目前看到了各种各样的交互方式，这是令人兴奋的。他预测可能性空间将继续扩大，人们会尝试不同的工具模式和交互方式。他认为，单纯的提示词 (Prompting) 有些像"AI 的 Telnet 时代"——通过不同界面与工具协作的能力远不止于此。他还期待在 AR/VR/XR 以及脑机接口 (BCI, Brain-Computer Interface) 等领域看到全新的动态界面。

对于代码生成是否能实现为每个用户"定制化设计的垂直软件"，Dylan 持谨慎态度。他以 Snapchat 为例：这是一款需要别人教你的消费级产品，界面相当复杂。如果你不断改变界面，用户就越难原生地学习和传递这种学习。这里存在一个重要的权衡——低门槛高上限 (Low Floor, High Ceiling) 的设计原则。

Figma 的创业起源：从无人机到 WebGL

Dylan 回顾了 Figma 的起源。2011 年底，他和联合创始人 Evan Wallace 开始讨论未来的创业方向，首先考虑的是哪些技术正在发生变化并创造机遇。当时有两个方向：无人机 (Drones) 和 WebGL。Dylan 更倾向于无人机，但 Evan 很快否决了这个方向——他认为无人机将受到监管或涉及国防，而且硬件开发中的运行-调试-修复循环太慢。于是两人转向了 Evan 有丰富专业知识的 WebGL。

接下来面临的选择是游戏还是工具软件。两人评估后认为游戏是"命中驱动型业务" (Hit-driven Business)，必须做出令人惊叹且引起共鸣的产品——难度太高。于是决定做工具和软件。

Dylan 离开布朗大学，开始了他以为只是一个间隔学期 (Gap Semester) 的旅程，去 Flipboard 实习。Evan 则在 2012 年春完成学业，两人开始一起探索和尝试各种方向。

迷因生成器：Figma 的最低点

探索过程中，他们尝试了迷因生成 (Meme Generation)——Dylan 后来形容这大概是 Figma 历史上的最低点。Dylan 当时非常确信迷因就是未来，他研究了迷因和迷因生成的搜索趋势，认为市面上没有好的迷因生成器，他们可以做最好的。他们花了一周时间做了出来，然后意识到"这真的是我们想做的事吗？"Evan 准备退出，Dylan 准备回学校——这是明确的信号：方向不对。不过 Evan 作为技术天才，在迷因生成器中实现了当时最先进的画布文本渲染，这段代码后来被复用于 Figma V1。

从照片编辑到设计工具：找到正确方向

他们还尝试了照片编辑器，构建了一个很酷的浏览器端照片编辑工具。但很快意识到，最好的相机就是你口袋里的那个——在手机上。为什么要在浏览器里编辑手机拍的照片？那应该是原生应用。而且照片编辑应用市场已经拥挤不堪，将成为大宗商品 (Commodity)。

然后他们尝试了存储、搜索、有趣的机器学习以及组合摄影 (Combinational Photography)，但发现这些要么依赖平台，要么为时过早——组合摄影方向早了十多年。

转折点出现在 Adobe Fireworks 被终止时。他们意识到可能存在机会，开始形成核心论点："随着软件变得越来越容易构建，设计变得越来越重要。" (As software gets easier to build, design becomes more important.) 当时设计看起来是一个微小的市场，但回顾来看，那是一个正在快速增长的市场。设计人员比例发生了巨大变化，即使在他们开始专注设计工具后的五年内也是如此。

反 VC 思维：不应以市场规模决定方向

主持人指出，这是一个深刻的例子，说明不应该用风险投资思维 (VC Thinking) 来决定做什么。很多人可能看全国有多少设计师，乘以他们的消费能力，得出市场太小的结论。Dylan 表示同意但也指出，事后回顾当然清晰，但现实中的种子轮融资 (Seed Pitch) 文档其实是五花八门的——2013 年 6 月的种子路演中，他们说要做一百万件事，一切都非常模糊。他很佩服 Index Ventures 的 Danny Rimer 当时的决断力。

产品范围：从创意到生产的完整流程

Dylan 透露，Figma 最终进入的流程是软件创作的完整过程：从创意或头脑风暴（Figma Jam/FigJam），到演示文稿 (Figma Slides)，再到设计、原型和开发交付 (Dev Mode)，以及上线后的学习反馈——形成持续的循环。FigJam 的头脑风暴功能源于用户在 Figma 中已有的行为，尤其是疫情爆发后更加显著，于是成为独立产品。Slides 也是如此——用户在 Figma Design 中创建了大量演示文稿，团队看到了就做出新产品。Dev Mode 同样如此。这些产品都是被用户"拉"出来的。

首个客户的故事：字体崩溃与调头返回

Figma 的第一个真正的付费客户是 Notion 和 Coda（当时叫 Krypton）。Dylan 回忆他花了几个月时间终于让 Coda CEO Shashi 和他的设计师对 Figma 产生了兴趣。当他们终于同意试用时，Dylan 和 Evan 兴奋地走出办公室，开车回旧金山。然而大约 20-30 分钟后，收到一封邮件："非常感谢你们来，但字体坏了，我们无法阅读。"原来这是 Dylan 搭建的一个有缺陷的本地字体功能。客户说"几个月后再试试吧"。Dylan 和 Evan 直接调头返回："不不不，我们还在，我们帮你设置。"但当时他们并没有告诉客户他们是第一个客户。几年后 Shashi 来 Figma 参加全员会议时，Dylan 告诉他这个事实，Shashi 非常惊讶。

实时协作：从质疑到认可

Figma 的封闭测试版 (Closed Beta) 于 2015 年 12 月上线，但正式版 (GA) 直到 2016 年 10 月才发布。封闭测试版上线时还没有多人协作 (Multiplayer) 功能，只是一个浏览器端的高质量但功能最少的设计工具。在测试版上线后的几个月里，Evan 开始构建实时协作引擎。

正式版发布时，设计社区的评论令人震惊。有人说"如果这就是设计的未来，我要转行了"。还有人引用"骆驼是委员会设计的马"这一典故，表达了典型的设计师心态——"我要独自在角落做我惊艳的作品，最后做盛大揭晓"这种个人主义心态，与产品团队的协作方式形成鲜明对比。

一个早期用户在推特上半开玩笑地说要办一场"设计派对" (Design Party)，邀请所有人进入同一个 Figma 文件。当时 Figma 没有人数限制，有公开链接分享，而且直到 2017 年中都是免费的。服务器几乎崩溃，上线后 48 小时内团队和 Evan 全力救火，确保那个设计派对文件不崩溃。虽然这始于人们对 Figma 的调侃，但最终成为了绝佳的广告——人们开始一起创作，甚至互不相识的人也在协作。这表明，即使人们当时还不买账 Figma 的理念，但协作的威力已经展现。

产品市场契合信号：一瓶葡萄酒换来的 12 页需求

Dylan 分享了一个关键的产品市场契合 (Product-Market Fit) 信号。他去 Corsair 找一个朋友做用户测试，下班后 6 点钟赴约，还带了一瓶葡萄酒——因为 Figma 的文本编辑体验和流程太慢了，写东西需要很长时间，他知道必须喝点酒才能撑过用户测试。他们喝完了整瓶酒。一两天后，那位朋友发来了一份 12 页的文档，列出了所有他希望 Figma 构建的功能和原因。Dylan 反思，他当时应该把这样的信号当作明确的产品市场拉力 (Product-Market Pull)——市场正在把产品从他们手中拉出来。他应该更快地招聘、加速内部团队增长。然而他当时仍非常谨慎，这是他希望回到过去改变的。

设计文化的核心：平衡简洁与强大

谈到 Figma 内部的设计文化，Dylan 表示他们有幸与优秀的设计师合作。核心张力之一是：为了给用户想要的功能，我们愿意让产品多复杂？如何在让简单的事情保持简单的同时，让复杂的事情成为可能 (Make the simple thing simple but the complex things possible)？Figma 不仅要服务资深设计师，还要服务那些只用过一次或从未用过 Figma 的用户。如何让他们也能立刻创建并获得好的体验？

Dylan 强调，当你要解决困难的设计和工程挑战时，就能吸引到最优秀的人才。Figma 很多创新来自团队，而非自上而下的指令。公司有"创客周" (Maker Week) 的概念——唯一的规则是"让 Figma 变得更好"，而且不只是开发者和工程师参与，而是整个公司。Figma Slides 就是创客周的产物。

从零到一再到规模化：自我替换循环

对于从零到一再到规模化 (Scaling) 的建议，Dylan 给出了一个抽象但实用的循环：时刻自我觉察——你现在做最多的事情是什么？然后用资源替换你自己。如果你有资源，就去获取；如果没有，就想办法——通过盈利、融资或巧妙的方式。持续这个循环，它将引导你正确地组建团队、正确地分配工作。危险在于过于被动反应，永远无法进入这个循环，永远无法自我改善组织——这很容易发生，因为总有做不完的事。

给今天创业者的建议

Dylan 的核心建议是：尽可能快地行动。现在有了新模型，你可以比以往快得多。当团队拿长路线图来找他时，他的第一反应是"我们怎么缩减范围、更快地把东西展示给用户？"很多人问他"我是否应该做两年的构建期"——作为曾经这样做过的人，Dylan 的回答是："如果不必，就不要这样做。"少数硬科技公司确实需要长期构建，但大多数事情不需要如此。如果能更快地推进，就应该这样做。