10 Rules for Designing Systems That Speak in Dialects
Design systems are not static libraries of components; they are living languages. Just as English has accents from Scotland to Sydney, design systems must adapt to context while preserving core meaning. The original article "Design Dialects: Breaking the Rules, Not the System" explores how rigid consistency can become a prison. Here are 10 key insights to help your design system speak fluid dialects—so it bends without breaking.
1. Treat Design Systems as Living Languages
Think of tokens as phonemes, components as words, patterns as phrases, and layouts as sentences. This linguistic analogy reminds us that meaning is not fixed—it emerges from context. A system that only permits one pronunciation will fail when users speak a different dialect. Embrace the idea that your design language must evolve, just as spoken languages do. The goal is fluent communication, not rigid grammar enforcement.
2. Consistency Is Not ROI—Solved Problems Are
At Booking.com, A/B testing everything—color, copy, button shapes, even logo colors—revealed a painful truth: visual consistency alone doesn't solve user problems. While admirers praised Airbnb's pristine system, Booking grew by prioritizing contextual effectiveness over uniform appearance. The lesson: focus on measurable outcomes, not on how components look side by side. Consistency is a tool, not an end.
3. Dialects Preserve Core Grammar While Expanding Vocabulary
A design dialect adapts the system for specific contexts without discarding essential principles. Unlike one-off hacks or brand themes, dialects maintain the system's underlying logic. For example, a warehouse app for pickers may use larger touch targets and high contrast—yet still follow the same spacing and color tokens. The grammar stays; the vocabulary grows.
4. Perfect Consistency Can Be the Enemy of Usability
The original article shares a dramatic case from Shopify Polaris. On shared Android scanners in dim aisles, with thick gloves and limited English, standard Polaris achieved 0% task completion. The system was perfectly consistent—but perfectly useless. To serve real users, the team had to bend the rules: bigger buttons, voice input, simplified copy. Consistency became a prison until they broke out.
5. Design Systems Need "Exception-Friendly" Governance
When teams file hundreds of exception requests, something is broken. A healthy system has built-in mechanisms for dialect creation. Instead of a rigid approval gate, provide guidelines for when and how to create a dialect. Empower teams to define local rules that still reference the global system. This turns exceptions into intentional adaptations.
6. Accents Are Not Errors—They're Strengths
English spoken in Glasgow and in Sydney are both valid; neither is a "mistake." Similarly, a design system used in a dark factory vs. a bright office will naturally differ. Treat these variations as evidence of fluency, not of non-compliance. Celebrate accents that improve user experience, and learn from them to evolve the core.
7. Context Is the Ultimate Arbiter of Design Decisions
All design choices are context-dependent. The same button that works on a laptop with a mouse fails on a touchscreen in rain. The original article highlights how context—device, environment, user skill—must override abstract consistency. A dialect is not a loophole; it's a necessary response to context. Build context-awareness into your system from the start.
8. Tokens Should Be Semantic, Not Visual
Instead of "blue-500" (a visual value), name tokens like "primary-action" (a semantic role). This allows dialects to remap colors and sizes based on context while preserving meaning. In a low-light warehouse, "primary-action" might trigger a high-contrast orange rather than the standard blue. The token stays constant; the visual output adapts.
9. Test Dialects Early and Often—Just Like Components
Don't wait until a dialect is fully built to validate it. Run quick A/B tests on variations, just as Booking.com did. Use prototypes with real users in the actual environment. The 0% completion rate was only discovered by testing under real conditions. Dialects must be proven effective, not just designed theoretically.
10. The Best Design Systems Are Bilingual
Successful systems speak both the standard language and the dialects. They have a core that is stable and universal, plus a flexible layer that local teams can adapt. The original article argues that fluency—not rigidity—is the goal. A system that speaks many dialects tells richer stories for diverse users. Build a system that bends, not breaks.
In conclusion, design systems must evolve from consistency prisons into living, adaptive languages. By embracing dialects, we solve real problems rather than defend abstract rules. The web has accents—make sure your system can speak them all.