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

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

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

作为活语言的设计系统

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

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

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

一致性成为监狱

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

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

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

当完美一致性失败时

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

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

在Shopify，Polaris是我们的皇冠上的明珠——一个成熟的、完美适用于笔记本电脑商家的设计语言。作为一个产品团队，我们被期望按原样采用Polaris。然后我的履行团队遇到了一个“哦，船！”的时刻，因为我们面临挑战，要为仓库拣货员构建一个应用程序，在昏暗的过道中使用共享、破旧的安卓扫描仪，戴着厚手套，每分钟扫描数十件物品，许多人英语理解水平有限。

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

每个对商家完美工作的组件对拣货员完全失败。白色背景产生眩光。44px的点击目标对戴手套的手指不可见。句子大小写标签解析时间过长。多步骤流程混淆了非母语人士。

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

方言的诞生

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

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

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

灵活性框架

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

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

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

决策阶梯

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

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

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

规则是工具，不是遗物。

统一胜过一致

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

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

无门的治理

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

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

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

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

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

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

超越组件库

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

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

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