连UX文案都需要设计系统？Figma Config给所有AI产品人上了一课

大多数人以为设计系统只管颜色、组件和字号，但在Figma Config上，一位UX Writer抛出了一个更激进的观点：如果没有“文案设计系统”，你的产品体验从根上就是乱的。这场演讲，正在悄悄改变AI产品、复杂系统和平台型应用对“文字”的看法。

最反直觉的事实：真正拖垮体验的，往往不是UI，而是文字

Pinda一上来就戳破了一个行业幻觉：我们为按钮、组件、颜色建立了极其精细的设计系统，却默认“文案靠人记”。结果是什么？在一个大型应用里，成百上千条文本各自为政——同样的动作有不同说法，同样的错误弹窗语气完全不一样。

她点出了UX Writing最容易被忽视的一点：文字直接作用于用户的“理解成本”。哪怕只是“保存成功”和“已成功保存”的差异，在规模化产品里都会不断累积，变成真实的认知负担。更残酷的是，这些问题不会在Design Review里被轻易发现，却会在真实用户那里持续放大。

这也是她的核心判断：当产品复杂度上升，文案一致性不是“加分项”，而是“生存条件”。

没有系统的UX文案工作，本质上是不可扩展的

Pinda描述的日常状态，对很多团队来说并不陌生：

• 写一个按钮文案，要先问：“以前是不是写过类似的？”
• 改一个弹窗，要去翻旧稿、翻Figma、翻历史版本
• 新人加入团队，全靠口口相传的“经验记忆”

她毫不留情地总结：这个过程“完全低效，而且不可扩展”。问题不在于UX Writer不专业，而在于工具和系统根本没为他们准备。

于是他们提出了一个关键概念：Copy System。不是文档，不是写作指南，而是一个“所有产品文案的唯一事实来源”。你不需要到处问人，只需要去系统里查：这句话有没有存在过？在哪个场景下用？语气是什么？

这个转变非常重要——它把UX Writing从“个人能力活”变成了“系统工程”。

真正的创新：让文案像组件一样被调用

在演示中，Pinda展示了这个系统如何在Figma里运作：当她从设计库里拖一个按钮组件时，不只是样式出现，文案的“注册状态”也会同步出现。

如果文案不存在，系统会提示你创建新文案；如果已经存在，你可以直接选择。这意味着：

• 文案第一次被写，就进入系统
• 之后每一次复用，都是“调用”，不是“重写”

更关键的是，这套系统让视觉系统、排版系统、文案系统彼此独立又能协同。改字体，不会影响文案逻辑；改文案，也不会破坏UI结构。

对AI产品团队来说，这一点尤其致命：当同一个模型输出被用在不同界面、不同流程、不同用户阶段时，没有文案系统，几乎必然导致语义和语气失控。

对AI和复杂产品团队的真正启示

在演讲后半段，Pinda坦诚地说：这套系统还只是“preliminary”。它仍然面临挑战，比如如何同时支持“浏览模式”和“搜索模式”，如何按写作场景筛选合适文案。

但她抛出的方向已经足够明确：设计系统如果只服务设计师，就已经落后于产品复杂度了。

当你的产品开始依赖AI决策、多轮对话、状态反馈时，文案不再是“润色”，而是用户理解系统行为的唯一窗口。没有系统化管理的文案，就像没有约束的模型输出——短期能跑，长期一定翻车。

这也是为什么她最后强调：设计系统、工具和流程，必须开始“为UX Writer而设计”。

总结

这场演讲真正厉害的地方，不在于展示了一个多精巧的Figma方案，而在于重新定义了“文字在产品里的地位”。如果你正在做AI产品、平台型系统或高复杂度应用，可以立刻自问三个问题：我们的关键文案有没有唯一来源？新人能不能在一天内找到“该怎么写”？同一句系统反馈，在不同地方是不是说法不一？

如果答案不理想，那你遇到的不是写作问题，而是系统问题。下一代设计系统的竞争，不只是UI，而是谁先把“语言”也纳入工程化。

关键词： UX Writing， 设计系统， Copy System， Figma Config， AI产品体验

事实核查备注： 需要核查：演讲人Pinda Phisitbutra的职位与公司；演讲时间与场合（Figma Config 2022）；Copy System是否为其团队内部方案而非Figma官方功能