Design Dialects: Breaking the Rules, Not the System

Published on March 29, 2026

“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

The web has accents. So should our design systems.

Design Systems as Living Languages

Design systems aren’t just component libraries—they’re living languages. Tokens are phonemes, components are words, patterns are phrases, and layouts are sentences. The conversations we build with users become the stories our products tell.

But here’s what we’ve forgotten: the more fluently a language is spoken, the more accents it can support without losing meaning. English in Scotland differs from English in Sydney, yet both are unmistakably English. The language adapts to context while preserving core meaning. This couldn’t be more obvious to me, a Brazilian Portuguese speaker, who learned English with an American accent and lives in Sydney.

Our design systems must work the same way. Rigid adherence to visual rules creates brittle systems that can break under contextual pressure. Fluent systems bend without breaking.

Consistency becomes a prison

The promise of design systems was simple: consistent components would accelerate development and unify experiences. However, as systems matured and products grew more complex, that promise has become a prison. Teams file “exception” requests . Products launch with workarounds instead of system components. Designers often spend more time defending consistency than actually solving user problems.

Our design systems must learn to speak dialects.

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 cater to different users, environments, or constraints.

When Perfect Consistency Fails

At Booking.com, I learned this lesson the hard way. We A/B-tested every aspect—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 admired Airbnb’s pristine design system, Booking grew into a giant without ever prioritizing visual consistency.

The chaos taught me something profound: consistency isn’t ROI; solved problems are.

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 it was. Then my fulfillment team faced an “Oh, Ship!” moment, as we needed to build an app for warehouse pickers using our interface on shared, battered Android scanners in dim aisles, while wearing thick gloves and scanning dozens of items per minute, many with limited levels of English proficiency.

Task completion with standard Polaris: 0%.

Every component that worked beautifully for merchants failed completely for pickers. White backgrounds created glare. Forty-four-pixel tap targets were invisible to gloved fingers. Sentence-case labels took too long to parse. Multi-step flows confused non-native speakers.

We faced a choice: abandon Polaris entirely or *teach it to speak warehouse*.

The Birth of a Dialect

We chose evolution over revolution. Working within Polaris’s core principles—clarity, efficiency, consistency—we developed what we now call a design dialect:

Result: Task completion jumped from 0% to 100%. Onboarding time dropped from three weeks to one shift.

This wasn’t customization or theming—this was a dialect: a systematic adaptation that maintained Polaris’s core grammar while developing new vocabulary for a specific context. Polaris hadn’t failed; it had learned to speak warehouse.

The Flexibility Framework

At Atlassian, working on the Jira platform—a system within the larger Atlassian ecosystem—I pushed for formalizing this insight. With dozens of products sharing a design language across different codebases, we needed systematic flexibility, so we built this directly into our workflow. The old model of exception requests and special approvals was failing at scale.

We developed the Flexibility Framework to help designers define how flexible they wanted their components to be:

During a navigation redesign, we tiered every element. The logo and global search stayed Consistent, while breadcrumbs and contextual actions became Flexible. Product teams could immediately see where innovation was welcome and where consistency mattered.

The Decision Ladder

Flexibility needs boundaries. We created a simple ladder for evaluating when rules should bend:

Good: Ship with existing system components. Fast, consistent, proven.

Better: Stretch a component slightly. Document the change. Contribute improvements back to the system for all to use.

Best: Prototype the ideal experience first. If user testing validates the benefit, update the system to support it.

The key question: “Which option allows users to succeed fastest?”

Rules are tools, not relics.

Unity Beats Uniformity

Gmail, Drive, and Maps are unmistakably Google—yet each speaks with its own accent. They achieve unity through shared principles, not cloned components. One extra week of debate over button color costs roughly $30K in engineer time.

Unity is a brand outcome; **fluency is

Design Dialects: Breaking the Rules, Not the System

Related News

Related Articles