【转】为什么 Figma 赢了

type

合作之弧

Figma 推出之初，其价值主张主要是使设计具有协作性。如果设计可以在浏览器中进行，那么设计师们就可以在同一个项目中合作。事实上，他们甚至可以同时进行设计。

2014 年，我在帮助 Figma （~~免责声明：我参与了 Greylock 对 Figma 的投资，但可悲的是，~~我~~个人在 Figma 并无股份。~~他们屏幕的右上角总是不停地循环播放 Dropbox 的通知。因为设计团队会将所有文件保存在 Dropbox 这样的共享文件夹中，所以同事每次修改文件都会收到通知。而且经常会有复杂的命名约定，以确保人们使用的是正确的版本。

Figma 解决了这个问题。Figma 中的设计不仅存储在云中，还可以在云中编辑。这意味着 Figma 用户始终在使用同一个设计。而 Dropbox 则不然。文件可能存储在云中，但编辑是在本地进行的--想象一下在 Dropbox 中共享 Word 文件与在 Google Docs 中进行编辑的区别。

用户在编辑设计时，实际上是在签出一个临时副本。这就是两个用户同时编辑一个文件会产生问题的原因。使用 Figma 编辑设计时，不会出现冲突。由于修订是 Figma 中每个设计的第一方功能，因此不需要使用名称为 "profile_design_v23_final_draft2 "的复杂文件。同样，设计师可以直接在对方的文件中发表评论，而不用发送电子邮件反馈。

循环越少越好。我知道，这是我第一次这么说

我曾经对 Figma 团队始终将 Figma 定义为浏览器优先感到困惑。浏览器优先和云优先有什么区别？随着时间的推移，我逐渐认识到这种区别有多么重要。当许多创意工具公司谈到云时，他们似乎将其视为存储文件的一个无定形的地方。但是，在他们的产品中进行创作的基本用户体验是通过桌面上的独立应用程序完成的。Figma 以浏览器为先，这得益于他们对 WebGL、Operational Transforms 和 CRDTs 等新技术的理解和使用（更重要的是性能）。

从用户的角度来看，没有文件，也不需要与其他编辑设计的人同步。在 Figma 中进行设计的实际*体验*是在互联网上实现的。即使在今天，竞争对手也经常谈论云计算，但却纠结于要将多少*体验移植到互联网上。提示："全部 "是正确答案，他们最终都会趋于一致。

设计师们喜欢 Figma，这吸引了最初的发行。有了团队库等功能，设计师们就有动力把团队中的其他设计师拉入 Figma。但是，设计师喜爱的工具虽然是成功的先决条件，但并不能完全反映 Figma 目前获得成功的根本原因。虽然 Figma 一直在为设计师打造理想的工具，但他们实际上打造了更重要的东西：一种让非设计师参与设计过程的方法。

必须滑入 DM 是件坏事

设计工具，不仅仅是设计师的工具

在 Figma 为设计师打造更好的工具的同时，他们的浏览器优先方法对非设计师产生了更彻底、更重要的影响。

我们常常忘记，我们在工作中使用工具的目的不是为了提高个人的工作效率，而是为了提高整个团队的工作效率。公司本身也经常忘记这一点。

对个人来说最好的工具可能也是对整个团队来说最好的工具。但重要的是后者。除了在一定程度上提高个人的工作效率之外，团队的工作效率也越来越重要。文字处理就是一个很好的例子。过去，人们需要围绕排版等个别功能进行大量的实验和定制。但当这已经足够好时，重点就转向了协作。而对于大多数用例来说，如今很少有人关心排版问题。我们的工具必须越来越了解我们的协作方式，并与之保持一致。当协作在后勤上困难重重、成本高昂时，这一点并不那么重要，但随着协作变得越来越容易，其重要性也随之上升。人们的工作不再各自为政，他们的工具也必须反映这一点。

最好的工具可以实现以前无法想象的协作。

一直以来，非设计人员很难**参与到设计过程中。如果项目经理、工程师甚至首席执行官想参与其中，就会有很多后勤方面的摩擦。如果他们想要完整的设计，设计师就需要把当前文件发给他们。然后，他们不仅需要下载文件，还要确保自己的电脑上安装了合适的 Adobe 产品或 Sketch。而且这些工具都是又大又慢的专业程序，对于不熟悉使用它们的人来说很不方便。如果没有设计师的指导，你很难驾驭一个项目。意见都是在单独的邮件中以不同的方式提出的。更糟糕的是，如果设计者在浏览者看完文件之前进行了更新，文件就会过时，而浏览者却毫无察觉。

设计人员的体验也同样糟糕。即使他们想让项目经理和工程师提供反馈，也需要在整个过程中手把手地教他们。设计师必须将设计导出为图片，发送截图，然后再想办法将反馈转化为实际设计中的修改。反馈循环非常缓慢，以至于他们在等待反馈时需要暂停流程。

当然，真正的情况是，大多数时候非设计师并不太参与设计过程。审阅设计的痛苦并不是主要问题，但由于存在足够多的摩擦，审阅工作往往无法进行。

Figma 解决了这个问题。

使用 Figma 共享设计就像发送链接一样简单。任何人都可以直接在浏览器中打开。这就像访问网站一样简单，因为......嗯......这就是访问网站。

一旦有了链接，非设计师就能随时获得最新设计。他们可以直接在设计中发表评论，而不会干扰设计者的工作流程。有了协同编辑功能，他们可以在会议上讨论修改意见，并实时观看修改的执行情况。

这些技术上的变化是更重要的社会规范转变的火种。Figma 让非设计师有可能更早地参与到整个流程中。

Figma 让公司意识到，非设计人员应该而且可以更多地参与到设计过程中来，而其他设计工具却没有考虑到非设计人员的体验和互动，这是多么疯狂的事情。

收紧反馈回路

Figma 让设计师和非设计师之间的合作更加紧密，但它对团队社会规范的第二阶影响要大得多。从历史上看，设计过程中的摩擦非常多，以至于大多数决策都是在做出 之后才引入设计。反过来说，一旦设计方案确定，非设计人员所能推动的改变也是有限的。收紧合作的反馈环路可以使流程获得非线性回报。设计可以与产品同时起草，从而在整个过程中实现双向反馈。将设计和工程使用的资产统一起来，可以实现更无缝的交接，并进行更多的无损和迭代交流。

全程无花果

设计师可以从团队中的工程师或项目经理那里不断获得反馈。有些人会对非设计人员过于深入设计流程感到敏感。在某些情况下，他们可能是对的，但这种代价与设计者的收益相比就显得微不足道了。

让非设计师参与到设计过程中，才能让设计师在产品和商业决策中占有一席之地。

长期以来，我们一直将设计、销售和客户服务等职能领域系统地分割开来。但现代企业正在认识到，如果核心循环是一个真正的迭代过程，那么设计等职能部门本身就必须成为公司反馈循环的一部分。设计决策不能完全抽象于企业的其他决策--它们与产品和工程决策一样相互交织。

从历史上看，设计作为一个业务单元一直是不透明的，这是因为要让其他人了解设计过程，在后勤和技术上都存在困难。但随着 Figma 等公司越来越多地解决了这些障碍，我们看到团队正在探索如何将设计与公司的其他流程进行最佳整合。这不足为奇，因为在过去的几十年中，我们在工程领域也看到了同样的发展历程。

上升途径

Figma 目前的成功在很大程度上得益于其在公司内部的传播能力。随着公司内使用 Figma 的人越来越多，Figma 的作用也越来越大，从而推动了其在公司内的渗透速度和规模。

Figma 很快就意识到，公司的设计限制往往不是像素问题，而是人的问题。

Figma 的许多竞争对手都是设计人员的好工具。但这正是它们的服务对象--设计师。

Figma 是团队设计的工具。而不是为设计师单独设计的。

现在你们都和我一起被困在橙色的盒子里了

通过将设计师和非设计师都带入 Figma，他们创造了一种交叉网络效应。在直接网络效应中，一个同质群体会随着加入人数的增加而从产品中获得更多价值。相比之下，交叉网络效应涉及两个（或更多）不同的群体，随着另一个群体的加入，他们的规模和价值也在增长。

Figma 在设计师和非设计师之间产生的交叉网络效应是其过去几年来取得复合式成功的主要原因之一，但这一原因未得到充分重视。

随着越来越多的设计师使用 Figma，他们也吸引了与之合作的非设计师。同样，当这些非设计师使用 Figma 时，他们也会鼓励与之合作的其他设计师使用 Figma。这是一个良性循环和强大的复合循环。

交叉网络效应

与直接网络效应相比，横向网络效应往往较少受到关注--部分原因是我们有关网络效应的词汇不够丰富，但主要原因是它们通常被视为市场的特有现象。虽然交叉网络效应确实最常见于市场，但认为它们只存在于市场的想法是错误的。供求关系是最著名的交叉网络效应，但并不是唯一的来源。

Figma 设计师之间的直接网络效应帮助它在早期发展壮大，但在帮助 Figma 传播方面也有局限性。设计师直接合作的设计师群体是有限的，而且不太可能经常变化。虽然他们可能会通过口口相传和社会推荐向许多其他设计师传播 Figma，但网络效应在传播上有一个渐近线。

Figma 的交叉网络效应提供了一个额外的载体。使用 Figma 的设计师与工程师和项目经理分享他们的设计，向他们介绍 Figma。当这些非设计师学会欣赏 Figma 时，他们就会向在不同项目中合作的其他设计师团队宣传 Figma。这些跨团队的网络效应有助于 Figma 在整个组织中的传播。

循环越多越好。呼，世界一切正常

这对公司的货币化和采购产生了影响。因为新设计工具为设计师提供了新功能而为其付费，可能不是最优先考虑的问题。但如果产品经理、工程师，甚至首席执行官本人都认为这对整个企业都很重要，那么它的优先级和定价杠杆就会高得多。

产品与分销的契合

正是这种交叉网络效应对 Figma 的发展起到了至关重要的作用。就像播种一样，Figma 可以从小规模开始，每个公司只有零星的几个人使用，但每个人都可以带动整个公司的发展。一旦 Figma 被几个设计师采用，他们的所有部门同事都会接触到这款产品，尤其是它的协作功能，并发现它为他们带来的体验有多好。然后，他们会鼓励其他团队和项目使用和采用 Figma，如此循环往复。

这就是 Figma 的复合增长率。虽然 Figma 花了一些时间来提高增长速度，但现在的可预测性和复合增长速度令人印象深刻。

Figma 产品的核心就是其分销循环的核心。这是非常罕见和强大的。产品和核心分销环路之间的真正一致，是催化离群企业复合增长能力的必要条件。

与这一代公司中的许多同行一样，Figma 也制定了两步销售计划：通过自下而上、产品驱动的方式实现落地和扩张，然后在产品的使用形成规模后再进行自上而下的销售。为此需要准备一系列企业功能、建立销售机器等等。在过去的几年里，Figma 已经开始构建这些功能，但仍有许多工作要做。

老兄，听说你喜欢循环......

这种新型企业公司既有以产品和增长为驱动力的消费者企业，也有以销售为驱动力的企业。当企业了解如何重新构建其组织结构、GTM 运动、定价模式等以最适合这种模式时，我们还处于早期阶段。就像之前的 SaaS 一样，这种自下而上到自上而下的模式将在未来几年内从艺术成熟为科学。尽管 Figma 要使其传统的企业销售流程变得强大，还有大量工作要做，但如果他们仅仅停留在简单地再现传统的企业销售流程上，那就太令人失望了。从业人员开始认识到，这些销售循环可以用与增长循环相同的方式来理解，而且有办法通过产品和运营推动具有显著优势的销售速度和规模。Figma 是走在这一前沿的公司之一，关于这一新兴领域的成熟，我们将撰写一系列完全不同的文章。

构建生态系统

Figma 的下一步是什么？

核心产品总有更多需要改进的地方。但总有一天，公司需要开始考虑下一步的发展顺序。

我们在不断地向上和向右发展！

竞争格局也已经成熟。竞争对手开始模仿和蚕食 Figma 的核心优势。当他们的观点与 Figma 在这一领域的观点趋同时，就会向 Figma 施压，迫使 Figma 向前推进。例如，Sketch 已将其定价模式转变为以团队为导向的订阅模式，并专注于将更多产品转移到 Sketch Cloud 中。在过去的一年里，他们从完全自力更生到从 Benchmark 募集到一轮风险投资。这些资金和支持推动 Figma 朝着更加积极的方向发展，并将重点放在协作上，尤其是将 Sketch 带入浏览器和构建团队协作。

Adobe 也有类似的举措。Photoshop 和 Illustrator 虽然功能强大、应用广泛，但对于数字产品设计师来说，它们并不是特别专业的产品。2019 年，他们推出了 Adobe XD，作为 Sketch 和 Figma 的直接竞争对手。

Figma 在过去几年中一直专注于其在公司 内部的价值和传播。Figma 的下一个挑战是在整个生态系统中提高其价值和在各公司间的传播。

全球网络效应

在使用 Figma 的公司内部，存在着推动复合价值的跨侧网络效应。但它是如何传播到新公司的呢？

从 Figma 的增长速度来看，显然是这样，但传播的方式并不那么明显。许多人跨公司工作，尤其是跨代理公司，并将 Figma 传播给他们的客户。同样，当人们离职并加入新公司时，他们也会把 Figma 带到新公司。当然，口口相传也有助于它的传播。这些都是 Figma 固有的合作优势所带来的效果和影响，但它们都是按照自己的自然节奏运作的。

由于 Figma 的努力工作，对于公司已经使用 Figma 的人来说，注册的价值要高得多。他们已经有了可以合作的队友。有专门针对其公司的资产和设计库。他们的团队已经构建了可以重复使用的组件。

但对于没有同事使用 Figma 的用户来说，这些价值都不存在。他们可以享受单人游戏带来的好处，却无法从 Figma 多年来为增加大量新用户所付出的艰苦努力中直接获得更多价值。

生活只是无休止地追求绘制向上和向右的图表

Figma 所面临的挑战不仅是在公司内部创造本地网络效应，而且要创造全球网络效应，使 Figma 在规模扩大时对所有用户都更有用。Figma 可以向很多方向扩展其范围*，但我们在这篇文章中的重点将放在他们已经开始采取的方向上。

现在一起说：循环越多越好！

2019 年，Figma 开始为跨公司的生态系统循环播下种子。去年 8 月，他们推出了 Figma Plugins，最近又推出了 Communities，开始推动跨公司协作和生产力的发展。

这是我最好的图形。从这里往下往右都是

通过社区增强创造力

社区允许用户和公司公开分享他们的设计，从而进一步推动了网络的发展。

一直以来，在 Dribbble 等网站上分享设计时，通常只分享输出的图像文件。其他人很难看到和使用完整的设计，包括图层和组件。即使共享了实际设计，在任何程序中打开它并解决任何依赖性问题也不是件容易的事。

共享 Figma 设计则消除了这种摩擦。任何人都可以立即打开设计，并开始将其用于自己的项目。这使得用户也能无障碍地成为创作者，而不仅仅是消费者。

一些设计师使用 Github 分享了他们的用户界面工具包、组件和设计系统。这样做的想法是对的，但 Github 并不适合设计。在工程设计中，分叉 repo 可能是无摩擦的，但对于设计来说却并非如此。设计仍然必须下载并加载到应用程序中。对于设计而言，Github 更像是一个下载文件的托管网站。Figma 的社区在很多方面都体现了 Github 的理念和意图，但在构建时更注重设计。复制一个共享设计，副本就会立即保存到您的工作区，随时可以编辑。

这种无摩擦的流程让人们可以轻松地共享和构建彼此的设计。但也许更重要的是，包含整个设计是一个更好的抽象层，可以带来新的好处。

情境为王

接收者可以看到设计中的底层组件和资产，以及围绕设计的更复杂的交互和动画，而不仅仅是接收最终输出。 Figma 的设计总监 Noah Levin 分享的 Figma 智能动画设计就是一个很好的例子。通过与社区共享整个设计，其他人不仅可以看到动画，还可以直接玩弄和调整实际设计和动画。这样，他们就可以更容易地学习如何使用智能动画，甚至可以将 Levin 演示的部分内容复制到自己的设计中。

插件的承诺

我一直在使用 Figma 制作非常小众的备忘录发送给朋友。Figma 非常棒，但随着我越来越挑剔，我开始在任何文字后面添加彩色矩形（圆角，因为我不是野蛮人），使其更易读。这是一系列小而繁琐的工作。最近，我发现了 Substrate for Text插件，它简化了这一过程。现在，我只需选择文字，激活插件，文字背景就会立即自动生成。这个插件是由居住在俄罗斯的设计师安德烈斯拉夫-科兹洛夫制作的。在世界的另一端，安德烈斯拉夫也遇到了我遇到的同样问题，他制作了一个插件来解决这个问题，并将其分享给了互联网。这对我来说提升了 Figma 的威力，让我更容易在与朋友交谈时立即创造出流行语。

不过，也许他也应该为我现在可以更快地嘲弄朋友而受到指责

这个备忘录也不是这么用的

这是插件承诺的一个小例子。Figma 的插件使其具有可扩展性，因此设计师可以增强他们的工作流程，获得新的能力，否则这些能力是不可能实现的，并且可以轻松地与他人分享。

我希望您能欣赏我在生产率曲线上所画的精确方块

如今，大多数 Figma 插件都能简化原本非常重复或费力的工作。如今，公司可以构建私人插件来满足其特定需求。例如，有些公司开发的插件可以自动生成暗模式设计，调入外部数据并提示常见的设计错误，或轻松生成正确方向的设计资产。这些插件提升了整个团队的水平。

然而，插件的真正威力在于让它们在整个生态系统中公开可用。插件是可供所有用户使用的集体进步。无论是创建图表、自定义地图、将数据拉入设计、为工程交接绘制红线，还是创建随机的 blob，插件都能提高设计师的工作效率。 Figma Chat 等插件表明，通过为设计师提供全新的能力，可以进一步拓展设计领域。

随着公司规模的扩大，为客户持续增加价值变得越来越难。客户越来越多，一家公司就很难满足所有独特的使用案例和需求。随着公司向核心客户以外的客户扩展，公司还必须为越来越多不那么理想的客户提供服务。对于那些没有与全部使用 Figma 的团队一起工作的复合优势的用户来说，尤其如此。

您的本地和全局效用曲线应该看起来像同步跳水。大家都这么说，对吗？

插件可以帮助 Figma 克服这种阻力。随着用户数量的增加，会有更多的插件被创建出来，从而使新用户可以更好地使用产品，并促进更多设计被创建出来。

构建平台

Sketch 等公司已经证明了一个强大的插件生态系统的重要性（当然，Adobe 之前也长期鼓励开发插件）。单个公司不可能开发出每个用户所需的所有功能和工具。当使用案例的多样性和规模超出了公司所能构建的范围，甚至往往超出了公司的理解范围时，就最需要平台。Sketch 的插件能让 Sketch 客户的价值以比 Sketch 推出新功能更快的速度增长。Figma 也可能会继续专注于一套通用的核心功能，为插件解决用户工作流程留下巨大的表面空间。

这幅图可能会有自己的文章

公司在了解成为平台的细微差别方面仍处于起步阶段。越来越多的公司已经达到了优先考虑的规模和动态范围，但在大多数情况下，它们都是在各自为战。十年后，将有明确的框架、衡量标准和支持生态系统来构建平台；而今天，这种框架、衡量标准和生态系统还很少。这是一个自然成熟的过程，也是所有商业模式都要经历的过程，比如过去十年中的 SaaS 和订阅模式。

它们成长得太快了。

由于我们在构建平台方面缺乏共同的词汇，许多人很难理解不同公司的方法之间微妙而重要的界限。例如，我们很容易认为所有插件系统都是一样的，但这种想法往往是不正确的。

Sketch 案例研究

以 Sketch 的插件生态系统为例。API 文档完备，插件覆盖率高。但是，插件不属于核心产品的范围。安装插件的用户通常会被引导到插件的 Github 页面，然后必须手动下载和安装。这是将产品置于云中的另一个渐变例子。即使 Sketch 位于云中，其插件也是本地文件。下载和安装时会有摩擦。在工作环境中，这种情况会更加复杂，因为团队必须手动确保员工在需要时使用相同的插件。

由于插件在 Sketch 产品中不是一等公民，不在其处理范围之内，因此插件管理非常分散。插件可以注册以便在 Sketch 网站上列出并启用自动更新，但除此之外 Sketch 是非常放手的。Sketch 官方并不提供插件受欢迎程度的信息，也不需要批准插件。相反，用户必须依赖 Github 上的星级或第三方网站上的评论。对于导致性能或稳定性问题的插件，也没有任何监督。

这不应被误认为是批评。Sketch 插件架构的弱点之所以暴露无遗，只是因为他们在鼓励围绕 Sketch 建立一个强大的插件社区方面做得非常成功。

平台是一个新兴的生态系统，它更类似于建立一个消费者社交网络，而不是一个传统的企业销售公司。这是构建平台的核心难题之一。它们是复杂的有机系统，必须精心培育（园艺思维与工程思维），而且很难事先预测它们的发展方向和规模。

斯凯奇功不可没。时至今日，我们仍不清楚插件能有多大的野心，也不清楚插件应该有多大的野心。通过默认采用相对放手的方式，他们允许社区不受阻碍地蓬勃发展。正是因为看到了 Sketch 在插件方面的成功，以及他们在插件方面的挣扎，Figma 和 Adobe XD 等其他公司才能够对插件生态系统的重要性、潜力和杠杆作用更有信心。

但是，虽然 Sketch 无可厚非，但他们的选择却阻碍了围绕其开发的插件潜力的充分发挥。Sketch 明白这一点。他们正在重新构建插件系统，使其完全云化，这是朝着正确方向迈出的必要一步。

复杂的系统并不能免除公司对其平台的架构、政策和规范做出明确选择的需要。如果说有什么区别的话，那就是复杂系统放大了其重要性。公司做出的结构性选择会随着其周围生态系统的出现而产生连锁反应。而由此产生的平台的方向和规模则是其初始条件所设定的物理功能。我们塑造了我们的抽象概念，随后它们也塑造了我们。

Figma：形成基础

Figma 的插件非常早期，但前景广阔。插件内置在浏览器中，当您点击安装插件时，插件立即可用。毕竟无需安装，只需激活访问权限即可。真是神奇。

附带棒状数字比例

就像所有好的魔法一样，让人感觉毫不费力的工作也相当艰巨。Figma 的插件必须安全、高效、稳定，尤其是因为他们正在为浏览器优先的系统创建一个插件生态系统。用户应该能够相信，使用插件不会让他们面临安全风险，也不会损害 Figma 的性能。开发者和用户都应该相信，插件所依赖的 API 不会突然过时或被破坏。如果没有这些先决条件，插件充其量只是 Figma 的一小部分。这种信任和稳定性是强大生态系统的基石。

我认为，插件就像彩虹蛋糕？

Figma 关于构建插件系统的工程博文最能体现这种困难。在他们发布关于如何决定插件架构的文章后不到一个月，他们就发现自己的方法存在漏洞，不得不更换。

确保平台的可信度不仅仅是技术架构的问题。Figma 不只是托管插件，他们还有一个集中的审批流程，与 Sketch 的做法相比，它更类似于苹果的应用商店。想要上市的插件必须通过 Figma 在安全、商业、可用性和法律方面的政策。

平台之路

商业政策尤其值得注意。安全、可用性和法律政策是为了维护平台的完整性和信任度，而 Figma 的商业政策则是为了塑造他们所认为的插件生态系统。例如，他们允许货币化，但希望所有用户都能使用插件。在多大程度上鼓励插件企业生态系统，在多大程度上鼓励开源社区，这些都是重要的选择。没有明显正确的答案，在一个平台的生命周期中，答案可能会改变，而且经常需要改变。我们只需看看 Uber 司机、WordPress 插件或 Airbnb 房东的构成就能明白这一点。

这也将是自己的一篇文章，哈哈

建立平台需要做出许多类似的艰难选择。你应该如何在鼓励当前增长和建立理想的长期愿景之间取得平衡？平台应该在多大程度上影响哪些插件的构建，甚至在早期应该自己构建哪些插件？如何决定哪些功能应该成为平台本身的一部分，而不是独立的插件？插件可以构建的范围有多大？这些只是核心问题中的几个。

Figma 最有趣的选择或许是非常注重插件创建的便捷性。Figma 插件系统的设计目的很明确，就是让设计师能够为自己的工作流程创建插件，从而将设计师转变为开发人员。在大多数平台和市场中，生态系统往往会随着时间的推移而分裂和专业化。这是生态系统*的自然引力。打赌平台的大量杠杆作用将来自于个人改进自己的工作流程是一个大胆的赌注。这是对诱导需求的赌注，而诱导需求永远是最有趣的赌注类型。

Figma 的插件生态系统刚刚起步。从他们的支持功能列表和即将推出的功能来看，要向更高级的插件开放他们的平台，显然还有很长的路要走。为插件生态系统选择正确的抽象层至关重要。到目前为止，他们在安全、性能和稳定性的核心技术决策和承诺方面采取了非常强硬的立场，但在插件的构建方面却非常放手。这在初期是意料之中的。在不清楚应该构建什么的情况下，看看社区的创造力会带来什么，也不失为一项好政策。这往往会带来令人惊叹的东西，比如这个插件演示。不过，随着时间的推移，我们应该会看到更多的关注点。现在，他们的插件页面除了受欢迎程度和一些特色插件外，没有其他分类。在插件数量足够少的情况下，这样做是可行的，但最终他们必须决定如何对插件进行分类，以及他们希望发现的插件是什么样子。

随着插件类别开始具体化，Figma 需要对以下问题形成清晰的看法：哪些领域应被纳入其核心产品；他们希望每个类别在成熟后是什么样子；哪些基本插件尚未存在而他们必须帮助催化；以及他们应允许插件使用哪些新的 API。如上所述，在多大程度上鼓励插件生态系统货币化的选择，就是 Figma 在建立插件平台时需要（反复）做出关键决策的一个完美例子。也许最重要的是，Figma 必须确定元框架，以便有意而非随意地做出这些决定。

推动进步

设计有进步吗？我们在设计方面是否越来越好，不是作为一门艺术，而是作为一种功能性实践？

答案当然是肯定的。我们拥有的工具在十年前是不可想象的，更不用说在计算机出现之前了。设计变得更容易了。开始设计更容易了。设计更具可扩展性。

但是，设计的改进速度与工程作为一个过程的改进速度相比又如何呢？从这个基准来看，设计作为一个元流程的表现并不突出。

工程学在将自身商品化和推动进步的速度上几乎是无与伦比的。框架、语言和基础架构中的最佳实践总是在快速地--有时甚至是翻天覆地地--演变。以前需要整个团队才能完成的工作，现在每年需要的人越来越少。

这是真正的向上和向右曲线。

随着学科的发展，他们会摸索出更好地运作所需的社会规范，建立可在整个行业共享的工具，并发明抽象概念，从而卸下越来越多的工作负担。他们学会如何更好地协作，不仅是相互之间的协作，还包括与所有其他职能部门的协作。学科本身并不是目的；学科对其所属的更大组织和生态系统的贡献程度，才是衡量学科进步的最终标准。

设计似乎正朝着工程学的方向发展。Figma 正处于推动这一演变的关键位置。作为一种工具，它打破了设计团队与其他团队之间的隔阂，使设计人员的工作效率更高，协作性更强。

梦想

但 Figma 真正的潜力在于它能否过渡成为一个平台。如果 Figma 能做到这一点，他们将推动设计作为 一门学科的进步。

哪个公司能在某个领域取得成功取决于很多因素，其中最重要的是运气。但是，当学科发生结构性变化时，那些茁壮成长的公司就会产生巨大的影响力。它们在抽象层、社会规范、架构等方面做出的选择，会对一代人产生巨大的影响。对于平台来说更是如此，因为平台的循环已成为其生态系统的核心。就像潮湿的粘土一样，它们所做的选择最终会凝固并成为决定整个生态系统成长方式的底层。这对 Figma 等公司来说，既是巨大的机遇，也是巨大的责任。