Design systems are often seen as rigid rulebooks, but they function more like living languages. Just as English in Scotland differs from English in Sydney while remaining unmistakably English, design systems must support regional dialects—systematic adaptations that preserve core principles but allow flexibility for context. This Q&A explores why consistency can become a prison, how successful companies like Booking.com and Shopify navigated this tension, and what it means for your product teams.
\n\nWhat exactly is a design dialect?
\nA 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 (which break the system) or brand themes (which change visual identity), dialects preserve the system's essential grammar—its tokens, components, and patterns—while expanding its vocabulary to serve different users, environments, or constraints. Think of it like a regional accent: the words are the same, but the pronunciation and cadence adapt to local needs. For example, a warehouse app for pickers might use larger touch targets, high-contrast colors, and minimal text, while a merchant dashboard on a laptop uses standard buttons and dense layouts. Both are part of the same system, but each dialect optimizes for its context.
Why does perfect consistency become a prison?
\nThe original promise of design systems—consistent components accelerating development and unifying experiences—works well in early stages. But as products grow complex, rigid enforcement leads to problems. Teams file “exception” requests by the hundreds, products launch with workarounds instead of system components, and designers spend more time defending consistency than solving user problems. Consistency becomes a prison when it prioritizes visual uniformity over user outcomes. The key insight: consistency isn’t ROI; solved problems are. A design system’s value isn't in identical buttons everywhere—it's in enabling coherent, effective experiences across diverse contexts.
\n\nWhat did Booking.com teach about ignoring visual consistency?
\nAt Booking.com, the author learned a painful lesson. The company A/B-tested everything—color, copy, button shapes, even logo colors. Coming from a graphic design background with experience building strict brand style guides, this approach was shocking. While everyone admired Airbnb's pristine design system, Booking grew into a global giant without ever prioritizing visual consistency. The chaos taught something profound: user goals trump brand consistency. Booking tested what worked for conversion and usability, not what looked neat on a design mockup. The result? A massive, successful product that adapted to user behavior rather than forcing users into a visual straightjacket.
\n\nHow did Shopify's Polaris system fail warehouse pickers?
\nShopify's Polaris design language was a mature system, perfect for merchants on laptops. When the author’s fulfillment team needed to build an app for warehouse pickers, they hit an “Oh, Ship!” moment. The standard Polaris components were designed for desktop scenarios—small buttons, low contrast, touch targets for fine motor control. But pickers used shared, battered Android scanners in dim aisles, wearing thick gloves, scanning dozens of items per minute, many with limited English. Task completion with unadapted Polaris? 0%. This forced the team to create a dialect: larger tap targets, high-contrast colors, voice feedback, and simplified layouts. The core system remained intact, but contextual adaptation was the only path to success.
\n\nWhat's the difference between a component library and a living language?
\nA component library is a static collection of reusable UI elements—buttons, modals, cards. A living language, by contrast, treats design like a spoken system. Tokens (colors, spacing) are phonemes, components are words, patterns are phrases, layouts are sentences. The conversations we build with users become the stories products tell. Libraries break when every context demands a unique component; languages grow because they allow accents. The more fluently a language is spoken, the more accents it can support without losing meaning. Rigid adherence to visual rules creates brittle systems; fluent systems bend without breaking. See the design dialect definition above for how this works in practice.
\n\nHow can teams implement design dialects without chaos?
\nStart by defining a core grammar: tokens, fundamental components, and interaction principles that must apply everywhere. Then identify contextual factors that require adaptation—device type, user role, environment, performance constraints. For each dialect, create a lightweight set of overrides (not new components) that inherit core tokens but adjust for context. Use a decision tree: Is this a one-off customization or a recurring pattern? If recurring, formalize it as a dialect. Test with real users; if a dialect improves task completion without breaking the system, adopt it. Document the dialect as a variant in the design system, not an exception. This maintains coherence while allowing necessary flexibility—just like how Canadian English borrows from both British and American without losing identity.