设计方言：打破规则，而非系统

“语言不仅仅是一组无关的声音、从句、规则和意义；它是一个与上下文和行为完全绑定的连贯系统。”——肯尼斯·L·派克

网络有口音，我们的设计系统也应该有

作为活语言的设计系统

设计系统不是组件库——它们是活语言。标记是音素，组件是单词，模式是短语，布局是句子。我们与用户建立的对话成为产品讲述的故事。

但我们忘记的是：语言说得越流利，它就能支持越多的口音而不丢失意义。苏格兰的英语与悉尼的英语不同，但两者都无疑是英语。语言适应上下文同时保留核心意义。这对作为巴西葡萄牙语使用者的我来说再明显不过，我带着美国口音学习英语，并居住在悉尼。

我们的设计系统必须以同样的方式工作。严格遵守视觉规则会创建脆弱的系统，在上下文压力下崩溃。流利的系统弯曲而不折断。

一致性成为牢笼

设计系统的承诺很简单：一致的组件将加速开发并统一体验。但随着系统成熟和产品变得更加复杂，这一承诺已成为牢笼。团队提交数百个“例外”请求。产品发布时使用变通方案而不是系统组件。设计师花费更多时间捍卫一致性而不是解决用户问题。

我们的设计系统必须学会说方言。

设计方言是设计系统的系统性适应，在维护核心原则的同时为特定上下文开发新模式。与一次性定制或品牌主题不同，方言保留系统的基本语法，同时扩展其词汇以服务不同的用户、环境或约束。

当完美一致性失败时

在Booking.com，我艰难地学到了这一课。我们对所有内容进行A/B测试——颜色、文案、按钮形状，甚至徽标颜色。作为拥有平面设计教育背景和构建品牌风格指南经验的专业人士，我发现这令人震惊。当每个人都爱上Airbnb的原始设计系统时，Booking在不考虑视觉一致性的情况下成长为巨头。

混乱教会了我深刻的东西：一致性不是投资回报率；解决的问题才是。

在Shopify，Polaris（https://polaris-react.shopify.com/）是我们的瑰宝——一个适用于笔记本电脑商家的成熟设计语言。作为产品团队，我们被期望原样采用Polaris。然后我的履约团队遇到了一个“哦，发货！”时刻，因为我们面临挑战，要为仓库拣货员构建一个应用程序，在昏暗的通道中使用共享、破旧的安卓扫描仪，戴着厚手套，每分钟扫描数十件物品，许多人英语理解水平有限。

使用标准Polaris的任务完成率：0%。

每个对商家运行良好的组件对拣货员完全失败。白色背景产生眩光。44像素的点击目标对戴手套的手指不可见。句子大小写标签解析时间过长。多步骤流程混淆非母语使用者。

我们面临选择：完全放弃Polaris，或教它说仓库语言。

方言的诞生

我们选择进化而非革命。在Polaris的核心原则——清晰、效率、一致性——内工作，我们开发了现在称为设计方言的内容：

结果：任务完成率从0%跃升至100%。上岗时间从三周降至一个班次。

这不是定制或主题——这是方言：一种系统性适应，在维护Polaris核心语法的同时为特定上下文开发新词汇。Polaris没有失败；它学会了说仓库语言。

灵活性框架

在Atlassian，致力于Jira平台——本身是更大Atlassian系统内的一个系统——我推动将这一见解正式化。随着数十个产品在不同代码库间共享设计语言，我们需要系统性灵活性，因此我们直接构建到工作方式中。旧模型——例外请求和特殊批准——在规模上失败。

我们开发了灵活性框架，以帮助设计师定义他们希望组件有多灵活：

在导航重新设计期间，我们对每个元素分层。徽标和全局搜索保持一致。面包屑和上下文操作变得灵活。产品团队可以立即看到哪里欢迎创新，哪里一致性重要。

决策阶梯

灵活性需要边界。我们创建了一个简单的阶梯来评估何时规则应该弯曲：

• 良好：使用现有系统组件发布。快速、一致、经过验证。
• 更好：稍微拉伸组件。记录更改。将改进贡献回系统供所有人使用。
• 最佳：首先原型化理想体验。如果用户测试验证了好处，更新系统以支持它。

关键问题：“哪个选项让用户最快成功？”

规则是工具，不是遗物。

统一击败 uniformity

Gmail、Drive和 Maps无疑是Google的——但每个都有自己的口音说话。它们通过共享原则实现统一，而不是克隆组件。关于按钮颜色的额外一周辩论大约花费3万美元的工程师时间。

统一是品牌结果；流利是用户结果。当两者冲突时，站在用户一边。

无门治理

如何在启用方言的同时保持连贯性？将您的系统视为活词汇：

• 记录每个偏差——例如，dialects/warehouse.md带有前后截图和原理。
• 推广共享模式——当三个团队独立采用方言时，审查它以纳入核心。
• 有上下文地弃用——通过标志和迁移说明淘汰旧习语，永远不要大爆炸清除。

活字典比冻结的规则手册扩展得更好。

从小开始：您的第一个方言

准备好引入方言了吗？从一个破碎的体验开始：

• 本周：找到一个完美一致性阻碍任务完成的用户流程。可能是移动用户与桌面大小组件斗争，或可访问性需求您的标准模式未解决。
• 记录上下文：什么使标准模式在这里失败？环境约束？用户能力？任务紧迫性？
• 设计一个系统性更改：关注行为而非美学。如果手套是问题，更大的目标不是“破坏系统”——它们是在服务用户。赢得变化并使它们有意为之。
• 测试和测量：更改是否提高任务完成率？达到生产力的时间？用户满意度？
• 显示节省：如果该方言释放甚至半个冲刺，流利性已收回成本。

超越组件库

我们不再管理设计系统——我们正在培育设计语言。与说话者一起成长的语言。发展口音而不丢失意义的语言。服务人类需求而非美学理想的语言。

从0%到100%任务完成率的仓库工人不关心我们的按钮打破了风格指南。他们关心按钮终于工作了。

您的用户有同样的感受。给您的系统许可说他们的语言。