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

设计系统作为活语言

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

但我们忘记了一点：语言说得越流利，它就能支持越多的口音而不丢失含义。苏格兰的英语与悉尼的英语不同，但两者都无疑是英语。语言在适应语境的同时保留了核心意义。

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

一致性成为牢笼

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

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

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

当完美一致性失败时

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

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

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

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

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

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

一种方言的诞生

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

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

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

灵活性框架

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

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

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

决策阶梯

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

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

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

规则是工具，不是遗物。

统一胜过一致

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

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

无门治理

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

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

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

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

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

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

超越组件库

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

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

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