Capital One 在 Figma Config 扔出一个反直觉结论：设计系统失败，不是因为设计不够好

在 Figma Config 2023 上，Capital One 的设计系统负责人 Jana Choi 抛出了一个让人警醒的观点：大多数设计系统不是死在组件，而是死在“没人会用”。他们为此做了一件极不常见的事——给设计系统造了一个“飞行模拟器”。这场分享，对所有做 AI 平台、内部工具和技术产品的人都极具启发。

最反直觉的一刀：组件齐全 ≠ 设计系统成功

如果你问大多数团队，什么是“最小可用的设计系统（MVP）”，答案几乎是条件反射式的：组件、代码、规范、文档。Jana Choi 在台上直接否定了这个共识。

她的判断很直接：这些东西“只是资产，不是产品”。真正决定设计系统能不能活下来的，不是你做了多少组件，而是有没有人愿意、敢于、持续地使用它。

在 Capital One 推进企业级设计系统的过程中，他们很快撞上了三堵墙：代码交付是分批的、采用路径异常复杂、还要推动团队从旧工作模式迁移到新的现代模式。结果是——设计系统客观存在，但用户主观逃离。

这对 AI 从业者来说几乎是照妖镜式的一幕。我们也在不停地交付模型、SDK、API、Demo，却默认“内部用户自己会学”。Jana 点破了这个行业迷思：内部用户不是超人，他们同样需要被认真对待的用户体验。

把设计系统当“星系”，而不是组件仓库

Jana 用了一个非常有画面感的隐喻：她把 Capital One 的数字产品生态看成一个“太阳系”。

在这个系统里，设计系统不是一个静态资源库，而是位于中心、提供“引力”的恒星。它的任务不是规定每个行星长什么样，而是让所有体验能在同一轨道上运行。

但问题也随之而来：如果引力存在，却没人感受到，它就等于不存在。文档就是这种“理论上的引力”——逻辑自洽，却无法让人真正进入轨道。

这也是她反复强调的一点：设计系统的成败，取决于社区，而不是控制。没有社区参与的系统，只是一个被动下载的工具包；有社区的系统，才会演化成组织能力。

这个视角放到 AI 平台上同样成立。一个模型如果没有被嵌入真实工作流、没有共同语言、没有学习路径，它再强，也只会停留在 PPT 里。

真正的转折点：他们给设计师造了一个“飞行模拟器”

最精彩的部分来了。

Jana 的团队问了一个关键问题：为什么设计师总是在“压力最大的时候”才第一次用设计系统？

答案显而易见，也异常荒谬——就像让飞行员在第一次驾驶飞机时，直接起飞载客。于是他们借用了航空业的经典做法：飞行模拟器。

这个“设计系统模拟器”不是文档，也不是一次性培训，而是一个让设计师在无风险环境中反复练习的空间。在这里，他们可以理解系统的设计逻辑、组件组合方式、设计质量标准，而不用担心交付失败。

效果非常明确：文档访问量上升、系统认知度提高、组件使用不再碎片化。更重要的是，设计师第一次是在“上下文”中学习系统，而不是在概念层面记规则。

这对 AI 工具建设是一个极其重要的启示：真正的学习，不发生在说明书里，而发生在可控的练习场中。

一套可复制的方法论，而不是灵感表演

Jana 并没有把这件事包装成一次天才式创新，而是拆解成了一套清晰的步骤。

第一，定义学习议程：不仅是工具怎么用，还包括设计质量判断，以及“只有这个系统才有”的核心概念。

第二，选择媒介：他们同时使用基于 Figma 的动手训练和直播式教学，前者解决技能，后者建立人和人的连接。

第三，打造培训的品牌身份：命名、视觉、术语、里程碑一个不少，让学习本身成为一种体验。

最后，才是“把东西做出来”。并且这远没结束——他们持续投入沟通、像产品一样做推广、收集反馈、反复迭代。

Jana 在结尾点明：这些经验不只属于设计系统，而是所有内部平台的通用解法。

总结

Jana Choi 的分享本质上在提醒所有技术从业者一件事：你交付的不是工具，而是一种“被使用的能力”。

对 AI 团队、平台团队来说，这意味着一个明确的行动方向——不要再指望用户“看文档自学”，而是为他们设计低风险的练习场、清晰的学习路径和可感知的成长反馈。

可以问自己三个问题：如果这是飞行员，你敢不敢让他只看说明书就起飞？你的系统，有没有一个“模拟器”？如果没有，也许问题从来不在技术本身。

关键词： 设计系统， 内部工具体验， 设计系统培训， 平台型产品， 用户采用

事实核查备注： 需要核查：Jana Choi 的职位描述（Capital One Enterprise Design System Design Tools Lead）；演讲发生在 Figma Config 2023；核心比喻包括“太阳系”“飞行模拟器”；结论如文档不足以完成培训、模拟器提升采用度均来自演讲内容。