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

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

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

作为活语言的设计系统

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

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

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

一致性成为牢笼

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

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

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

当完美一致性失败时

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

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

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

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

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

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

一种方言的诞生

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

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

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

灵活性框架

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

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

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

决策阶梯

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

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

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

规则是工具，不是遗物。

统一胜过一致

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

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

无门控的治理

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

• 记录每一个偏差 – 例如，dialects/warehouse.md，包含前后截图和原理说明。
• 推广共享模式 – 当三个团队独立采用一种方言时，审查它以考虑纳入核心。
• 有上下文地弃用 – 通过标志和迁移说明淘汰旧习语，绝不搞一刀切的清除。

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

从小处着手：你的第一个方言

准备好引入方言了吗？从一个出问题的体验开始：

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

超越组件库

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

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

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