Figma 最成功的产品，竟然是在“混乱失控”中做出来的

三天三次部署、工程师在 Uber 里写代码、设计流程被彻底打碎——这是 Figma 团队亲口承认的“灾难现场”。但正是这种不体面的混乱，做出了 Community 和 Design System Analytics 两个关键产品。这场分享，几乎颠覆了我们对“好产品=好流程”的想象。

双钻石流程？在 Figma，几乎从来没发生过

如果你学过设计，大概率见过那张“完美”的双钻石流程图：先发散定义问题，再收敛；再发散找方案，再收敛落地。但 Figma 的工程师 Lizzie 和设计师 Jenny 上来就泼了盆冷水——“它在 Figma 几乎从来没长这样。”

现实是：没有充裕时间做完整流程，没有清晰边界让设计和工程依次接力。设计和工程同时在动，问题和方案一起变化。她们甚至直接把这场分享命名为《A Beautiful Mess》——一场“美丽的混乱”。

这个反差本身就很值得 AI 从业者警惕：当模型、需求、用户反馈都在快速变化时，执着于线性流程，可能反而是效率最低的选择。

8 周上线 Community：一场差点失控的“大型事故”

Figma Community 是一次重量级发布：用户终于可以有公开主页、发布文件、被全世界复制和二次创作。听起来理所当然，但整个项目从 8 月开始，到 10 月上线——只有 8 周。

Jenny 的形容非常直接：后期“真的很糟”。一天三次部署、工程师在 Uber 里写代码、所有人都在和时间赛跑。问题出在哪？不是技术，而是“东西越做越多，却突然发现：根本没地方放”。

他们低估了一个看似基础的问题：信息架构。最终不得不临时重做文件浏览器，把所有新能力硬塞进去。事后复盘时，Jenny 很坦诚：如果能重来，她宁愿先把搜索和浏览做好，而不是一口气把所有功能推给用户。

对 AI 产品来说，这几乎是教科书级的提醒：能力本身不等于可用性，尤其当内容和规模开始爆炸时。

Design System Analytics：在“不知道该做什么”里硬走出来

另一个项目 Design System Analytics，问题恰恰相反：不是做太快，而是卡在“不知道该做什么”。

这个产品的目标是帮助组织理解设计系统的健康度——组件被怎么用、在哪里用、是否被滥用。但一开始，设计、工程、指标全部高度耦合，没有清晰规格，也没有现成范式。

Lizzie 说，他们能走出来，靠的是一个残酷的决定：放弃“一开始就做完整产品”的幻想。先承认模糊，先做最小可行的理解。

更有意思的是角色的混用：数据科学家做定性研究，偏销售背景的设计师深度参与产品定义，基础架构工程师第一次密切和设计师结对。这种“角色越界”，在流程上看是混乱的，但在认知上反而让问题更快被看清。

为什么前面越乱，后面反而越顺？

Design System Analytics 的发布当天，Lizzie 一整天都在刷 Twitter——但不是因为出事故，而是因为一切异常顺利。

原因恰恰在于：前期卡得足够久。那些痛苦的、不确定的、反复拉扯的讨论，提前把最大的分歧和技术风险消耗掉了。

这与 Community 的经历形成鲜明对比：一个是“先冲刺，后补洞”，一个是“先混乱，后平滑”。两者都成功了，但代价完全不同。

对正在做 AI 产品的团队来说，这是一个非常现实的启示：当问题本身高度不确定时，过早追求速度，可能只是把复杂性推迟到发布前一刻爆炸。

总结

Figma 这场分享最重要的价值，并不在于具体功能，而在于它对“混乱”的态度：混乱不是失败，而是复杂问题的真实形态。关键不在于消灭混乱，而在于什么时候接受它、什么时候收敛它。

如果你在做 AI 产品：当需求、模型能力和用户认知都在变，或许应该允许一段“难看但高密度”的混乱期；同时警惕把信息架构、可发现性这些基础问题留到最后。真正成熟的团队，不是流程最漂亮的，而是最清楚“此刻该乱，还是该稳”的。

关键词： Figma， 产品开发， 设计工程协作， 混乱式创新， AI产品方法论

事实核查备注： 视频标题与来源：A Beautiful Mess： How We Build Products at Figma（Figma Config，2020-02-27）；Community 项目周期约 8 周（8 月至 10 月）；Design System Analytics 发布时间为 11 月 20 日；发言者为 Figma 工程师 Lizzie Fan 与设计师 Jenny Wen