Figma 团队揭秘快速原型3个迷思，AI产品反而更该慢一点

很多人以为“快速原型=快速得到答案”，但 Figma 团队在 Config 大会上直接泼了三盆冷水：原型不会告诉你真相、越完整越糟、迭代一定很慢。更反直觉的是，这些结论对今天的 AI 产品团队杀伤力最大。

第一个被戳破的幻想：快速原型不会给你“答案”

在台上，Christa Simon 和 Heather Tompkins 一上来就抛出一个让人不舒服的事实：快速原型并不会告诉你该怎么做。它只能告诉你，用户在这个设定下“做了什么”。

很多团队把原型测试当成“投票器”——用户喜欢，就做；用户不喜欢，就砍。但她们强调，真正有价值的不是“喜欢/不喜欢”，而是行为轨迹：用户卡在哪、犹豫多久、用错了几次。

这对 AI 产品尤其致命。因为当系统背后是模型推理而不是确定逻辑时，用户的反馈往往是情绪化的，比如“感觉不太聪明”。如果你只盯着反馈文本，而不看用户在原型中的实际行为路径，你会得到一堆看似有用、实际上无法指导模型或交互改进的噪声。

她们的做法是：把原型当成记录工具，而不是裁判。原型的任务不是下结论，而是帮你持续追踪同一个问题在多轮迭代中的变化。

原型越完整，测试效果越差

第二个迷思更反直觉：原型并不是越像真实产品越好。

很多团队在测试前拼命补功能、补状态、补异常路径，生怕用户“测得不真实”。但在 Figma 团队的经验里，这种“过度真实”的原型反而会掩盖问题。因为用户会被细节牵着走，忽略核心体验。

她们更倾向于用“不完整但聚焦”的原型，只验证一个关键假设。比如：用户是否意识到这里可以说话？是否理解系统在“听”？一旦发现问题，就立刻记录、回去修改，而不是等一个“完美版本”。

放到 AI 场景，这一点尤其重要。你不需要一个真正智能的模型，才能测试“用户是否信任这个回答”。你需要的只是一个足够可信的假设载体。否则，你会把时间花在打磨模型细节上，却错过了交互层面最致命的误解。

迭代并不慢，是你把资源用错了地方

第三个迷思直指管理层常见抱怨：迭代原型太花时间、太花资源。

Figma 团队的回应很直接：慢不是因为迭代，而是因为每一轮你都试图解决太多问题。她们主张极小步快跑，把一次测试压缩到只验证一个判断。

更关键的是，迭代不应该只发生在设计师和研究员之间。她们反复强调“让所有人参与”：工程、产品、研究一起看测试，一起听用户说什么。这样做的结果不是会议变多，而是返工变少。

对于 AI 团队来说，这几乎是一条铁律。如果模型、产品和设计是割裂的，原型测试的结论永远落不了地。反之，只要团队共享同一手观察素材，哪怕模型还很粗糙，也能对齐下一步方向。

为什么这套方法，正在成为 AI 产品的隐形门槛

这场分享表面上讲的是“快速原型测试”，但真正的含金量在于：它重新定义了“快”。

快不是尽早上线功能，而是尽早暴露错误假设。尤其在 AI 产品中，错误往往不在模型指标，而在用户理解：他们以为系统懂什么、会什么、不会什么。

Figma 团队用音频功能的探索提醒我们：当交互范式本身是新的时候，原型的价值不在于预测成功，而在于持续缩小误解。对 AI 从业者来说，这意味着你不该等模型成熟再测体验，而是越早用粗糙原型测试认知边界越好。

总结

这场 Config 分享真正想告诉你的只有一件事：快速原型不是为了更快做决定，而是为了更早发现自己想错了。如果你在做 AI 产品，试着把下一次原型测试的目标砍到只剩一个问题，并拉上整个团队一起看真实用户的行为。别追求完整、别迷信反馈文本、别等模型“准备好”。真正的竞争力，来自你比别人更早修正方向。

关键词： 快速原型， 用户研究， Figma Config， AI 产品设计， 原型测试

事实核查备注： 需要核查：1）演讲者姓名 Christa Simon、Heather Tompkins；2）活动为 Config 2021；3）主题为 rapid prototype testing 与 Figma 音频相关探索；4）视频发布时间 2021-05-24。