Design Systems That Speak Your Users' Language

From Component Libraries to Living Languages

"Language is not merely a set of unrelated sounds, clauses, rules, and meanings; it is a totally coherent system bound to context and behavior." — Kenneth L. Pike

This insight, drawn from the world of linguistics, challenges how we think about design systems. For too long, we've treated them as static libraries of buttons, inputs, and modals. But a design system is far more dynamic: it's a living language. Tokens become phonemes, components become words, patterns become phrases, and layouts become sentences. The conversations we build with users become the stories our products tell.

However, we've overlooked a critical nuance: the most fluent languages naturally develop accents. English spoken in Scotland differs from English in Sydney, yet both remain unmistakably English. The language adapts to context while preserving its core meaning. This truth is deeply personal for me — a Brazilian Portuguese speaker who learned English with an American accent and now lives in Sydney. Our design systems must work the same way. Rigid adherence to visual rules creates brittle systems that break under contextual pressure. Fluent systems bend without breaking.

When Consistency Becomes a Prison

The original promise of design systems was straightforward: consistent components would accelerate development and unify user experiences. But as systems matured and products grew more complex, that promise has become a prison. Teams file "exception" requests by the hundreds. Products launch with workarounds instead of system components. Designers spend more time defending consistency than solving user problems.

This is where design dialects come in. 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.

Real-World Lessons: When Perfect Consistency Fails

Booking.com: Testing Everything

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

Shopify Polaris: The Warehouse Reality

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: users working on shared, battered Android scanners in dim aisles, wearing thick gloves, scanning dozens of items per minute, many with limited English understanding.

Task completion with standard Polaris? Zero percent.

Every component we had carefully crafted for desktop merchants was useless in that context. We needed a dialect of Polaris — one that prioritized large tap targets, high-contrast text, simplified navigation, and voice-based interactions. We weren't breaking the system; we were translating it for a new audience.

How to Build Design Dialects That Work

To create effective dialects without fracturing your system, follow these principles:

• Identify core vs. contextual. Decide what is inviolable (your brand's emotional tone, accessibility baselines) versus what can adapt (spacing, typography scale, component complexity).
• Set boundaries with tokens. Use design tokens to encode allowed variations. For example, a spacing-scale token might have a "compact" dialect for mobile or industrial contexts.
• Test for meaning, not consistency. A/B test whether the dialect improves task completion, satisfaction, or business goals. If it does, embrace the variation.
• Document the dialect just as you would the main system. Include guidelines on when to use the dialect, what changes are allowed, and how to request extensions.

Conclusion: Solve Problems, Not Consistency Grids

Design systems are not ends in themselves; they are tools for solving user problems. When consistency becomes an obstacle to usability, it's time to embrace dialects. The goal is not visual uniformity across every touchpoint — it's coherent, effective communication across diverse contexts. Just as languages thrive through regional accents, design systems become more powerful when they adapt to the real environments where people use them.

So next time a team requests an exception, ask: "Is this a unique case, or does it signal a new dialect we should formally support?" Your design system will grow stronger, and your users will thank you.