Design systems are often compared to languages—they have vocabulary, grammar, and syntax. But just as English varies from Edinburgh to Sydney, your design system needs regional dialects. A rigid system that demands perfect consistency everywhere becomes a prison, blocking the very problems it was meant to solve. By embracing systematic adaptations—what we call design dialects—you keep the core intact while serving different contexts. Below, we explore this idea through key questions, drawing lessons from Booking.com and Shopify.
1. How Are Design Systems Like Living Languages?
Think of your design system not as a static library but as a living language. Tokens are the phonemes—the smallest units of sound (color, spacing). Components are words (buttons, inputs). Patterns form phrases (search forms). Layouts become sentences. Just as a fluent English speaker can understand Scottish or Australian accents, a well-designed system should allow for dialects—variations that preserve core meaning while adapting to local context. The more fluently a language is spoken, the more accents it can support without losing coherence. Design systems that forbid variation break under contextual pressure; fluent ones bend.
2. Why Can the Quest for Perfect Consistency Become a Prison?
The original promise was simple: consistent components speed development and unify experiences. But as systems mature, that promise often traps teams. Product teams file hundreds of “exception” requests. Workarounds replace system components. Designers spend more energy defending consistency than solving real user problems. The result? A brittle system that stifles innovation. Instead of serving diverse user needs, the system demands that every experience fit a single mold. That’s unsustainable. The real goal shouldn’t be perfect visual consistency—it should be solved problems.
3. What Exactly Is a “Design Dialect”?
A design dialect is a systematic adaptation of your design system. It maintains the core principles—the grammar—but develops new patterns for specific contexts. Unlike a one-off customization (which breaks from the system entirely) or a brand theme (which only changes visuals), a dialect operates within the system’s logic. It expands the vocabulary to serve different users, environments, or constraints. For example, a dialect for warehouse pickers on rugged scanners might use larger touch targets, high contrast colors, and simplified copy—all while keeping the same button styles and navigation patterns. The essence stays the same; the expression shifts.
4. What Did the Author Learn at Booking.com About Consistency?
At Booking.com, the team A/B-tested everything—color, copy, button shapes, even logo colors. To someone trained in graphic design and brand guides, this felt shocking. Everyone admired Airbnb’s pristine design system, yet Booking grew into a travel giant with zero emphasis on visual consistency. The lesson? Consistency isn’t ROI. Solved problems are. The chaos taught us that rigid visual rules don’t drive business results; meeting user needs does. A/B testing revealed what actually worked for conversion, regardless of whether it matched a style guide. That pragmatic approach paved the way for thinking in dialects.
5. How Did the Shopify Polaris Case Illustrate the Need for Dialects?
Shopify’s Polaris design system was a mature, polished language—perfect for merchants on laptops. The fulfillment team was expected to adopt it as-is. Then they faced warehouse pickers using shared Android scanners in dim aisles, wearing thick gloves, scanning dozens of items per minute, many with limited English. Task completion with standard Polaris? 0%. The system simply didn’t fit the context. That “Oh, sheesh” moment showed that a single dialect can’t serve all users. They needed a warehouse dialect: bigger buttons, voice feedback, minimal text. Adapting Polaris without breaking its core—a classic design dialect.
6. What Is the Key Takeaway for Building Design Systems Today?
Design systems must learn to speak dialects. Instead of enforcing pixel-perfect consistency across every surface, design for fluency. Define core principles—the essential grammar—and allow variations that serve different contexts without losing meaning. Use tokens to manage shiftable parameters (size, contrast, language). Test with real users in each context. As the original article says, “Fluent systems bend without breaking.” The goal isn’t uniformity; it’s coherence across diverse experiences. By breaking the rules (but not the system), you create products that actually solve problems for the people using them.