为什么“按钮”会毁掉你的系统：Dan Mall 在 Config 的反直觉一课

在 Figma Config 的舞台上，Dan Mall 抛出了一个让全场愣住的观点：做设计系统，最不该先做的就是按钮。这场演讲不讲炫技，而是拆解一个残酷现实——大多数系统不是失败在能力，而是死于没人用。对 AI 产品和平台团队来说，这几乎是一记当头棒喝。

最危险的第一步：为什么“按钮”是个糟糕的起点

几乎所有团队在做设计系统时，都会从按钮开始。原因很简单：按钮小、通用、看起来进展快。但 Dan Mall 在台上直接泼冷水——按钮是“最糟糕的早期组件”。

原因并不在技术，而在组织行为。按钮太基础，几乎没有团队会因为“少了一个按钮组件”而改变工作方式。它无法制造依赖，也无法逼迫团队迁移。结果就是：设计系统上线了，按钮也做完了，但没有人真正需要它。

这个判断对 AI 从业者尤其刺耳。我们太习惯从‘最基础的模型能力’或‘最通用的 API’开始，却忽略了一个现实：不能改变用户行为的能力，再优雅也只是摆设。

设计系统的墓地：那些“看起来完成了”的失败项目

Dan 把这种状态称为“设计系统墓地”：系统还在，文档还在，甚至组件也在持续更新，但团队已经悄悄绕开它。

他回顾了自己在 Super Friendly（一家设计系统咨询公司）时期接到的大量求助请求。从 2014 年开始，客户问的不是“怎么做系统”，而是“怎么让大家用起来”。这不是设计问题，而是采用（adoption）问题。

如果你在做 AI 平台、内部工具或模型中台，这个画面一定很熟悉：平台功能齐全，使用率却低得可怜。问题往往不在‘做得不够好’，而在‘做的东西不痛不痒’。

真正该先做的组件：从“没人能绕开的地方”下手

那应该从什么开始？Dan 给出的答案是：从那些“高复杂度、强依赖、真实痛点”的组件开始。

他举了 autocomplete（自动补全）作为例子。这类组件有几个关键特征：实现成本高、每个团队都会遇到、而且自己做几乎一定会踩坑。一旦系统提供了一个好用的版本，团队会主动来用——不是因为你要求，而是因为他们需要。

这对 AI 产品的启示非常直接：不要先做‘展示型能力’，而要做‘替代型能力’。真正能推动 adoption 的，是那些如果不用你，就必须付出巨大代价自己造轮子的地方。

采用不是发布那一刻，而是一连串持续的活动

在演讲中，Dan 明确区分了三类活动：构建、采用、演进。大多数团队只擅长第一步。

他强调，采用不是一次性事件，而是持续的协作：和真实团队一起用组件、做可用性测试、快速迭代、修 Bug、复盘哪里有效、哪里失败。这些工作看起来不“高大上”，却决定了系统的生死。

对 AI 团队来说，这几乎是在否定‘发模型即完成’的幻想。真正的工作发生在发布之后：提示词怎么被误用？接口在哪些场景下崩溃？用户为什么不用你预想的方式使用模型？

文档不是说明书，而是“系统成长史”

演讲后半段，Dan 提出了一个容易被忽略但极其重要的观点：不要把文档当成说明书，而要当成编年史（chronicling）。

与其写‘你应该怎么用’，不如记录‘我们是怎么一步步走到今天的’，包括失败的尝试、被否定的方案、暂时的妥协。哪怕现在的组件还是个“雪花”（不够通用），也值得被记录。

这对 AI 组织尤其关键。模型决策、数据取舍、能力边界，如果只存在于少数人脑中，系统永远无法规模化。能被继承的不是代码，而是决策逻辑。

总结

Dan Mall 这场演讲的真正价值，不在设计系统本身，而在于它揭示了一条普适规律：系统的成功，取决于是否改变了人的行为。对 AI 从业者来说，这意味着重新审视你的‘第一个能力’、你的 adoption 策略，以及你是否把发布当成了终点。一个可行动的建议是：回头看看你正在做的产品或平台，问自己一个问题——如果明天不用它，用户会真正痛吗？如果答案是否定的，也许你该换一个起点了。

关键词： Dan Mall， 设计系统， 组件策略， 产品采用率， AI 平台

事实核查备注： 1. 演讲者姓名拼写：Dan Mall（视频字幕中可能误识别为 Dan Maul）
2. Super Friendly 为 Dan Mall 运营的设计系统咨询公司（截至去年已不再运营）
3. 提及时间点：2014 年开始收到设计系统相关咨询
4. 核心观点：按钮不是好的早期组件、autocomplete 作为示例组件
5. 演讲场合：Figma Config 2023