Beyond Consistency: Why Design Systems Need Dialects

Introduction: Design Systems as Living Languages

Kenneth L. Pike once wrote, "Language is not merely a set of unrelated sounds, clauses, rules, and meanings; it is a totally coherent system bound to context and behavior." This insight applies perfectly to modern design systems. They are not static component libraries—they are living languages. Tokens function as phonemes, components as words, patterns as phrases, and layouts as sentences. The interactions we build become the stories our products tell.

Yet, many teams forget a crucial linguistic principle: the more fluently a language is spoken, the more accents it can support without losing meaning. English spoken in Scotland differs from English in Sydney, yet both remain unmistakably English. As a Brazilian Portuguese speaker who learned English with an American accent and now lives in Sydney, this is obvious to me. Design systems must work the same way. Rigid rules create brittle systems that break under contextual pressure. Fluent systems bend without breaking.

The Flaw of Perfect Consistency

Design systems were initially promised to accelerate development and unify experiences through consistent components. But as systems matured and products grew more complex, that promise became a prison. Teams file hundreds of exception requests. Products launch with workarounds instead of system components. Designers spend more time defending consistency than solving user problems.

Lessons from Booking.com

At Booking.com, I learned this lesson the hard way. The company A/B-tested everything—color, copy, button shapes, even logo colors. As a professional with a graphic design education and experience building brand style guides, I found this shocking. While everyone admired Airbnb’s pristine design system, Booking grew into a giant without ever prioritizing visual consistency. The chaos taught me something profound: consistency isn’t ROI; solved problems are.

Shopify Polaris Failure

At Shopify, Polaris was our crown jewel—a mature design language perfect for merchants on laptops. As a product team, we were expected to adopt Polaris as-is. Then my fulfillment team faced an "Oh, Ship!" moment. We needed to build an app for warehouse pickers using our interface on shared, battered Android scanners in dim aisles, with thick gloves, scanning dozens of items per minute—many workers had limited English understanding.

Task completion with standard Polaris: 0%. Every single interaction failed because the interface assumed perfect vision, fine motor control, and a stable environment. The system’s rigid consistency made it unusable in context.

Understanding Design Dialects

A design dialect is a systematic adaptation of a design system that maintains core principles while developing new patterns for specific contexts. Unlike one-off customizations or brand themes, dialects preserve the system’s essential grammar while expanding its vocabulary to serve different users, environments, or constraints. Dialects are not exceptions; they are intentional variations that extend the system’s reach.

Think of it like regional accents within a language. The core vocabulary and grammar remain, but pronunciation, word choice, and even sentence structure adapt to local needs. A design dialect for warehouse scanners might use larger touch targets, high-contrast colors, voice feedback, and simplified navigation—while still respecting the same token system, component library, and interaction principles as the desktop version.

Implementing Dialects in Your System

To adopt design dialects without chaos, follow these guidelines:

• Define a core grammar: Establish non-negotiable principles (accessibility, responsiveness, data integrity) that all dialects must adhere to.
• Identify context vectors: Map where dialects are needed—device types, environments, user roles, or cultural contexts.
• Create dialect documentation: For each dialect, document the adaptations made, the rationale, and the boundaries (what cannot change).
• Govern through patterns, not rules: Instead of approving every exception, design a process for evolving the system’s vocabulary when new contexts emerge.

For instance, the warehouse scanner dialect would include a new pattern called "glove-friendly interaction"—with larger hit areas, reduced gesture complexity, and voice input support. That pattern becomes part of the design system’s growing vocabulary, available for any future context that needs it.

Conclusion: Systems That Bend Without Breaking

The web has accents, and so should our design systems. Rigid consistency may look good in a design review, but it fails real users in real contexts. A design system that speaks dialects remains coherent yet flexible. It lets the team adapt quickly to new challenges without sacrificing core identity.

If you’re maintaining a design system today, ask yourself: Are we building a prison of consistency, or a living language that evolves with context? The answer will determine whether your system thrives or breaks under pressure.