Speaking in Dialects: How Design Systems Can Bend Without Breaking

Design systems are often treated as rigid rulebooks, but the best ones function like living languages. They have a core grammar—tokens, components, patterns—but they also need to adapt to different contexts, just as English spoken in Scotland differs from English in Sydney. This is where the concept of design dialects comes in. A design dialect is a systematic adaptation that preserves core principles while allowing new patterns to emerge for specific users, environments, or constraints. Instead of choking teams with exception requests, a fluent design system bends without breaking. Below, we explore key questions about this approach, drawing on real-world lessons from Booking.com and Shopify.

What is a design dialect and why does it matter?

A design dialect is a context-specific adaptation of a design system that keeps the system’s essential grammar while expanding its vocabulary. For example, a button in your global component library might have a specific color and padding, but in a warehouse scanner app used by workers wearing thick gloves, that button needs to be larger and more touchable. Instead of submitting an exception request, a design dialect allows that variation without breaking the core visual language. Why does this matter? Because rigid consistency often becomes a prison. Teams spend more time defending rules than solving real user problems. By speaking dialects, you prioritize solved problems over perfect uniformity. As the article points out, consistency isn’t ROI; solved problems are. Dialects let you stay aligned with the system while adapting to reality.

How do design systems resemble living languages?

Think of design systems as complete languages: tokens are phonemes, components are words, patterns are phrases, and layouts are sentences. Just as languages evolve with accents and dialects, design systems must be flexible enough to support variations without losing core meaning. The author, a Brazilian Portuguese speaker who learned English with an American accent and now lives in Sydney, notes that English remains unmistakably English across these contexts. Similarly, a well-designed system should be able to produce a dialect for a warehouse app or a mobile banking interface without becoming unrecognizable. The key is fluency: the more fluently a language is spoken, the more accents it can support. A rigid system breaks under contextual pressure; a fluent one bends.

What did the author learn from Booking.com’s approach?

At Booking.com, the author witnessed a radically different philosophy: they A/B-tested everything—color, copy, button shapes, even logo colors. Coming from a graphic design background where brand consistency was sacred, this was shocking. Yet while everyone admired Airbnb’s pristine design system, Booking.com grew into a giant without ever striving for visual consistency. The chaos taught a profound lesson: consistency is not ROI; solved problems are. By testing every element against real user behavior, Booking prioritized outcomes over rigid rules. This doesn’t mean abandoning all system thinking—it means letting context drive adaptation. A design dialect approach would have given them a structured way to vary components while still maintaining a coherent brand.

What happened with Shopify Polaris and the fulfillment team?

Shopify’s Polaris design system was a crown jewel—perfect for merchants on laptops. But when the fulfillment team tried to build an app for warehouse pickers using shared, battered Android scanners in dim aisles, wearing thick gloves and scanning dozens of items per minute (many with limited English), task completion with standard Polaris was 0%. The system failed because it wasn’t designed for that context. This “Oh, Ship!” moment drove home the need for design dialects. The team had to adapt: larger buttons, high-contrast text, voice commands, and simplified navigation—all while keeping the core Polaris logic intact. A dialect let them serve a completely different user without rebuilding the entire system from scratch.

How do design dialects differ from one-off customizations?

One-off customizations are isolated hacks—they solve a local problem but don’t feed back into the system. Over time, they create technical debt and visual chaos. Design dialects, in contrast, are systematic. They share the same underlying tokens, components, and interaction patterns, but they override or extend those patterns for a specific context. Think of it like building a special accent for a region: you keep the same vocabulary, but you adjust pronunciation where needed. A dialect is documented, maintained, and versioned alongside the core system, so it doesn’t become an orphan. It also follows the same design principles, just applied differently. This ensures that when the system evolves, the dialect can evolve with it, not against it.

How can design teams balance consistency with flexibility?

Balance starts by defining what consistency truly means—often it’s about core principles (e.g., our brand feels trustworthy) rather than pixel-perfect replicas. A practical way is to establish a core and dialect tier: the core contains mandatory tokens and components (like color palette, typography scale, and accessibility standards). Dialects then define overrides for specific contexts (like larger tap targets for warehouse scanners). Use feature flags or theming mechanisms in code to swap dialects conditionally. Also, treat dialects as living documents: test them with users, iterate, and periodically review whether they can be merged back into the core. The goal is a system that bends but never breaks, and that solves real user problems while keeping the brand coherent.

What is the core principle of a fluent design system?

The core principle is that fluency enables adaptation. A fluent design system is not a static library but a set of relationships and rules that can stretch without snapping. It respects the hierarchy: tokens inform components, components form patterns, patterns build layouts, and all are united by design principles. When a new context arises, you don’t start from scratch; you ask which layer needs to shift. Sometimes it’s just a token (e.g., color for contrast), sometimes a component (e.g., a button size), or a full pattern (e.g., a new navigation flow). The system should have built-in mechanisms—like design tokens with variable values, or component slots for customization—to support these shifts. Ultimately, a fluent system recognizes that language is not a set of unrelated rules; it is a coherent system bound to context and behavior.