90个工程师只有1个设计师，他靠“会计学设计”把设计规模化了

一家服务14万用户的欧洲SaaS公司，设计团队却长期只有一个人。更反直觉的是，拯救设计瓶颈的不是招更多设计师，而是一群前会计。Figma这场分享，讲清了一个被严重低估的事实：设计不是职业，而是一种可以被“普及”的能力。

最反直觉的真相：设计规模化，靠的不是设计师

如果你管理过产品或设计团队，一定听过这句话：设计人手永远不够。但在这场 Figma Config 的分享里，Vision Planner 的设计经理 Boro 给了一个几乎“冒犯行业”的答案：设计规模化，靠的不是更多设计师，而是让非设计师学会设计。

背景很极端——2018 年，他加入这家荷兰 SaaS 公司时，团队配置是 1 个设计师 + 30 个工程师；几年后，公司扩张到 90 个工程师，设计师还是他一个。需求却从一个核心产品，变成多个全新的 Web 应用。传统设计流程开始全面崩溃：文件反复拷贝、版本混乱、沟通成本指数级上升。

关键转折点并不是“招人”，而是一次几乎随意的尝试：Boro 把一个 Figma 文件分享给了一位产品经理——而这位产品经理，之前是会计。

“会计能不能做设计？”这个问题本身就问错了

这场分享最有记忆点的标题来自一句话：Can an accountant be a designer？ Boro 的答案很直接：Yes。

他讲了一个真实人物：Vivek，一位来自印度的会计，后来成为产品负责人。Vivek 没有设计背景，却在实际工作中完整学会了在 Figma 里参与设计决策。不是画花哨界面，而是围绕业务逻辑、信息结构、用户路径，和设计师在同一个文件里讨论。

这里的关键洞察是：会计并不缺设计能力，他们缺的是“可进入设计流程的工具”。 当设计工具复杂、封闭、以“专业门槛”为荣时，非设计师天然被排除；而当工具足够直观、协作成本足够低，领域专家反而能做出更贴近真实需求的设计判断。

Boro 说，他只做了一件很小的事：给这些前会计、产品负责人做了一次非常短的 Figma 培训。结果是，一旦他们“上手”了工具，就会主动参与设计，而不是在需求评审会上被动提意见。

一个巨大 Figma 文件，反而成了组织的“公共大脑”

在分享中，Boro 展示了一个“看起来有点吓人”的画面：一个包含大量页面的超大 Figma 文件。

在很多团队里，这是反面教材——文件太大、太乱、不可维护。但在 Vision Planner，这个文件反而成了核心协作空间。原因很简单：所有人都在同一个地方思考。

产品、设计、前会计出身的 PO，甚至分布在不同国家的成员，都在同一套设计语境下工作。没有“这是设计稿、这是 PRD、这是评审 PPT”的割裂，而是围绕真实界面持续演化。

这点对 AI 从业者尤其值得警惕：我们常常讨论“模型能力”“算法架构”，却低估了协作载体本身对系统复杂度的影响。当知识被拆散在文档、原型、代码仓库里，理解成本会指数级增长；而当它们在一个可视、可协作的环境中，系统反而更容易被“非专家”理解和改进。

当市场团队开始“自己设计”，组织结构被悄悄改写

分享的下半场，另一位嘉宾 Matt Sochipko 讲了一个看似不同、但本质相同的故事：Figma 不只被设计师用，还被市场团队“拿走了”。

他们直接在 Figma 里构建落地页、广告创意，实时迭代。结果不是混乱，而是角色边界的重新划分：
- 市场人员获得设计自主权
- 设计师从“执行者”变成“系统维护者”
- 开发者不再被零碎需求打断

Matt 总结这套流程的结果时，用了一句话：Productivity unlocks creativity.

这对 AI 团队同样成立。当工具足够高效，创意才会被释放；当创意被释放，组织结构就会发生变化。真正的变革，往往不是来自一个“更聪明的人”，而是一个“让更多人变聪明的系统”。

总结

这场分享表面上讲的是 Figma，实际上讲的是一个更大的趋势：专业能力正在从“岗位专属”，变成“组织可扩散”。 对 AI 从业者来说，这意味着三件事：第一，不要低估非技术角色的判断力；第二，工具选择会深刻影响协作上限；第三，真正可规模化的能力，一定能被“非专家”使用。下一个问题是：在你的团队里，有没有一种能力，其实也该被“普及”了？

关键词： Figma， 设计协作， 非设计师参与设计， 组织效率， 跨职能团队

事实核查备注： 需要核查：Vision Planner 服务用户数约 140，000；Boro 加入公司时间为 2018 年；设计师与工程师比例（1：30 到 1：90）；分享发生于 Figma Config 2021；人物名称 Boro、Vivek、Matt Sochipko 拼写