Embracing Design Dialects: Flexibility in Design Systems

"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 is rich with accents, and our design systems should reflect that diversity.

Reframing Design Systems as Dynamic Languages

Design systems transcend the notion of static component libraries; they function as dynamic languages. Within these languages, tokens serve as phonemes, components act as words, patterns become phrases, and layouts form sentences. The exchanges created with users weave the narratives that our products tell.

The Necessity of Dialects in Design

One essential aspect of language that has often been overlooked entails the allowance of various accents. Just as English retains its identity while manifesting distinct accents in different locales, design systems must similarly adapt to diverse contexts without sacrificing fundamental meaning. Rigid adherence to design standards often leads to fragile systems that crumble under contextual pressures. The most effective systems exhibit flexibility, bending instead of breaking.

Initially, design systems promised consistency that would enhance development speed and unify experiences. However, as these systems evolved alongside increasingly complex products, that promise transformed into constraint. Many teams submit exception requests by the hundreds, causing products to apply workarounds rather than using defined system components. As a result, designers find themselves defending inflexible adherence to these standards instead of focusing on actual user needs.

Lessons from Experience: When Consistency Falls Short

Booking.com provided a crucial lesson in this arena. The company's commitment to rigorous A/B testing across countless aspects—color, copy, and button designs—highlighted that consistency alone does not assure success. While the industry admired Airbnb’s polished design approach, Booking.com grew into its vast structure without fully recognizing the significance of consistency.

This chaotic environment reinforced a pivotal realization: solving user problems takes precedence over inflexible consistency.

At Shopify, the Polaris design framework (https://polaris-react.shopify.com/) stood as a beacon of mature design language. However, when tasked with an application meant for warehouse pickers utilizing shared, battered Android scanners in dimly lit spaces, it became evident that Polaris's application failed to address the realities of the users in this context.

The result was disheartening: task completion rates with standard Polaris standards were at 0%.

Components that worked harmoniously for merchants fell drastically short for warehouse pickers. The glaring white backgrounds caused visibility issues, the touch targets were too small for gloved fingers, and sentence-case labels burdened those with limited English comprehension.

Faced with this dilemma, the teams seized the opportunity to evolve rather than dismiss Polaris altogether. They aimed to teach it to communicate in the "warehouse dialect."

Creating a Flexible Design Dialect

Choosing evolution, they retained Polaris's core principles of clarity and efficiency while crafting what became known as a design dialect:

Outcome: Task completion surged from 0% to 100%, while onboarding dropped from three weeks to merely one shift.

This wasn’t an act of customization; it was the emergence of a dialect—a systematic adaptation that retained core grammar while enhancing vocabulary for specific environments. Polaris didn't fail; it successfully learned to engage in the warehouse context.

Institutionalizing Flexibility: The Framework Approach

Drawing insights from such experiences, Atlassian sought to formalize a flexible approach to design systems within its Jira platform. In a context where multiple products shared a design language across diverse codebases, they recognized a need for systematic flexibility. The previous protocol of exception requests fell short as the system scaled.

The team developed the Flexibility Framework, enabling designers to articulate desired flexibility levels for components:

In a recent navigation redesign, the team classified elements accordingly, ensuring that elements capturing brand identity were treated as Consistent, while areas open to innovation received a Flexible designation. This approach provided clarity on where to maintain uniformity and where creative latitude was acceptable.

Making Decisions Around Flexibility

Flexibility requires boundaries. To facilitate clear decision-making regarding when to relax rules, the team devised a straightforward “decision ladder”:

Good: Ship with existing system components—quick, consistent, proven.

Better: Slightly adjust a component; document the change and contribute it back for broader system use.

Best: Prototype the ideal experience. If user testing validates improvements, update the system accordingly.

The determining question should be: “Which approach allows users to succeed most swiftly?” Rules should serve the users, not constrain them.

The Balance of Unity versus Uniformity

Services like Gmail, Drive, and Maps exude a coherent Google identity while each retains its unique voice. This balance manifests through adherence to shared principles rather than identical components. In large organizations, prolonged debates about design elements can swiftly incur significant costs in engineering resources.

Ultimately, unity is an outcome of branding while fluency centers around user experience. When tensions surface between the two, user needs should take precedence.

Governance in a Flexible Framework

How does one nurture coherence while accommodating dialects? Viewing the system as an evolving vocabulary proves effective:

• Document deviations—for instance, dialects/warehouse.md should include before/after snapshots along with rationales.
• Encourage shared patterns—if several teams independently adopt a dialect, assess its potential for core inclusion.
• Deprecate outdated components thoughtfully—phase out old design elements with caution and context, rather than via abrupt purges.

A living vocabulary adapts better than an inflexible playbook.

Starting Small with Dialects

Ready to initiate dialect incorporation? Begin with one challenging experience:

This week: Identify a user flow impeded by rigid consistency. This could involve mobile users facing difficulties with desktop-sized components or accessibility challenges overlooked by standard procedures.

Document the context: Analyze why established patterns fail. Consider environmental factors, user capabilities, and the urgency of tasks at hand.

Design a systematic change: Prioritize behavior modifications over aesthetics. If the challenge involves gloved users, increasing target sizes isn’t “disrupting the system,” it’s enhancing user experience. Earn your variations with intention.

Test and evaluate: Measure whether the adjustment boosts task completion rates, productivity time, and overall user satisfaction.

Demonstrate the savings: Even minor efficiencies can yield substantial returns in user satisfaction and productivity for the development team.

Cultivating Design Languages Beyond Component Libraries

We must shift our mindset from merely managing design systems to actively nurturing design languages that grow and evolve with their users. These languages should express their unique accents while retaining clarity and meaning, prioritizing human needs over aesthetic constraints.

The warehouse workers who transformed from 0% to 100% task completion weren’t concerned that the design strayed from the style guide; they were focused on functionality. Your users deserve the same respect and understanding—allow your system the freedom to communicate in their language.