Embrace design dialects: improve user experience

“Language is not simply a set of unrelated sounds, clauses, rules and meanings; it is a fully coherent system linked to context and behavior.” —Kenneth L. Pike

Article continues below

The website has accents. So should our design systems.

Design systems as living languages#section2

Design systems are not libraries of components: they are living languages. Tokens They are phonemes, components They are words, patterns They are phrases, designs They are prayers. The conversations we have 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 handle without losing meaning. English in Scotland differs from English in Sydney, but both are unmistakably English. Language adapts to the context while preserving the central 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 fragile systems that break under contextual pressure. Fluid systems bend without breaking.

Coherence becomes a prison.

The promise of design systems was simple: consistent components would speed development and unify experiences. But as systems matured and products became more complex, that promise became a prison. Teams submit hundreds of “exception” requests. Products are launched with workarounds instead of system components. Designers spend more time defending consistency than solving user problems.

Our design systems must learn to speak. dialects.

A design dialect is a systematic adaptation of a design system that maintains basic principles while developing new patterns for specific contexts. Unlike one-off customizations or branded themes, dialects preserve the system’s essential grammar while expanding its vocabulary to serve different users, environments, or limitations.

When perfect consistency fails#section3

In Reserva.comI learned this lesson the hard way. We A/B tested everything: color, text, button shapes, and even logo colors. As a professional with a background in graphic design and experience creating brand style guides, I found this shocking. While everyone fell in love with Airbnb’s impeccable design system, Booking grew into a giant without even considering visual consistency.

Chaos taught me something profound: consistency is not return on investment; The solved problems are.

On Shopify. polar star (https://polaris-react.shopify.com/) was our crown jewel: a mature design language perfect for laptop-based merchants. As a product team, we were expected to adopt Polaris as-is. Then my compliance team issued an “Oh, ship!” Right now, we’re faced with the challenge of creating an app for warehouse pickers using our interface on battered, shared Android scanners in dark hallways, wearing thick gloves, scanning dozens of items per minute, many with limited levels of English comprehension.

Completing tasks with standard Polaris: 0%.

Every component that worked wonderfully for traders failed completely for collectors. The white backgrounds created reflections. The 44-pixel touch targets were invisible to gloved fingers. Sentence case tags took too long to parse. Multi-step flows confused non-native speakers.

We face a choice: abandon Polaris completely or teach him to speak warehouse.

The birth of a dialect#section4

We choose evolution over revolution. Working within the core Polaris principles (clarity, efficiency and consistency), we developed what we now call a design dialect:

Restriction	fluid movement	Rationale
Glare and low light	Dark surfaces + light text	Reduce brightness on low DPI screens
Gloves and hurry	90px (~2cm) touch targets	Accommodates thick gloves
Multilingual	Single task screens, plain language	Reduce cognitive load

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

This was not customization or theming: it was a dialect– A systematic adaptation that maintained the core grammar of Polaris while developing new vocabulary for a specific context. Polaris had not failed; I had learned to speak warehouse.

The flexibility framework#section5

In Atlassianworking on the Jira platform, itself a system within the larger Atlassian system, I pushed to formalize this idea. With dozens of products sharing a design language across different code bases, we needed systematic flexibility, so we built directly into our ways of working. The old model (exception requests and special approvals) was failing on a massive scale.

We develop the Flexibility framework to help designers define how flexible they wanted their components to be:

Level	Action	Property
Consistent	Adopt without changes	Platform lock design and code.
Dogmatic	Adapt within limits	Platform provides smart defaults and custom products
Flexible	Extend freely	The platform defines the behavior, the very presentation of the products.

During a navigation redesign, we organize each element into levels. The logo and global search remained consistent. Navigation paths and contextual actions became flexible. Product teams could immediately see where innovation was welcome and where consistency mattered.

The decision ladder#section6

Flexibility needs limits. We created a simple ladder to evaluate when to bend the rules:

Good: Ships with existing system components. Fast, consistent, tested.

Better: Slightly stretch a component. Document the change. Contribute improvements to the system for everyone to use.

Better: First, create a prototype of the ideal experience. If user testing validates the benefit, update the system to support it.

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

Rules are tools, not relics.

Unity defeats uniformity#section7

Gmail, Drive and Maps are undoubtedly Google, but each speaks with its own accent. They achieve unity through shared principles, not cloned components. An extra week of debate over button color costs approximately $30,000 in engineer time.

Unity is a result of the brand; fluency is a result of the user. When the two collide, side with the user.

Governance without doors#section8

How do you maintain consistency while enabling dialects? Treat your system like a living vocabulary:

Document every deviation – e.g. dialects/warehouse.md with before/after screenshots and justification.

Promote shared patterns – when three teams adopt a dialect independently, review it for basic inclusion.

Disapprove with context – remove old idioms through flags and immigration notes, never a great purge.

A living dictionary scales better than a frozen rulebook.

Start small: your first dialect#section9

Ready to introduce dialects? Start with a broken experience:

This week: Find a user flow where perfect consistency blocks task completion. They could be mobile users who have issues with desktop-sized components or accessibility needs that their standard patterns don’t address.

Document the context: What causes standard patterns to fail here? Environmental limitations? User capabilities? Urgency of the task?

Design a systematic change: Focus on behavior over aesthetics. If the problem is the gloves, the most important goals are not “breaking the system,” but serving the user. Win the variations and make them intentional.

Test and measure: Does the change improve task completion? Time for productivity? User satisfaction?

Show the savings: If that dialect frees even half a sprint, fluency has paid for itself.

Beyond the component library#section10

We no longer manage design systems.We are cultivating design languages. Languages ​​that grow with their speakers. Languages ​​that develop accents without losing meaning. Languages ​​that serve human needs above aesthetic ideals.

The warehouse workers who went from 0% to 100% task completion didn’t care that our buttons broke the style guide. They worried that the buttons would finally work.

Your users feel the same. Give your system permission to speak its language.