Introduction

Introduction

Overview

Overview

Problem Breakdown

Problem Breakdown

Research & Ideation

Research & Ideation

Strategy

Strategy

Foundations

Foundations

Component System

Component System

RTL & Theming

RTL & Theming

Results

Results

Reflection

Reflection

fLYDUBAI · design system · ✅ implemented

Building a scalable, multilingual design system for flydubai

Building a scalable, multilingual design system for flydubai

In 4 months, I led the design systems track to unify fragmented UI patterns into one token-driven, RTL-ready foundation teams could scale and maintain.

In 4 months, I led the design systems track to unify fragmented UI patterns into one token-driven, RTL-ready foundation teams could scale and maintain.
Design Time Per Screen

Reduced from 6 hours to 2 hours

Dev Handoff Cycle

Reduced from 3 days to 1 days

Dev QA Issues

Dropped from avg. 14 to 4 per screen

  • Enabled seamless Desktop-to-Tablet responsiveness through template variations
  • Localized designs from English to Russian using Figma tokens and translator
  • Adapted English interfaces into Arabic RTL experiences using scalable design system templates and components.
  • Enabled seamless Desktop-to-Tablet responsiveness through template variations
  • Localized designs from English to Russian using Figma tokens and translator
  • Adapted English interfaces into Arabic RTL experiences using scalable design system templates and components.

Achievements

✅ Enabled seamless Desktop-to-Tablet responsiveness through template variations.

✅ Reduced multilingual screen conversion time to 1–2 mins using tokens, themes, and variants.

✅ Achieved 1–2 min product-to-product screen conversion with reusable templates.

✅ Minimized manual effort with scalable, reusable design system components.

✈️ ABOUT FLYDUBAI

flydubai is a Dubai-based, government owned Emirati airline focused on making travel easier, connecting people, and providing a reliable, comfortable experience.

flydubai is a Dubai-based, government owned Emirati airline focused on making travel easier, connecting people, and providing a reliable, comfortable experience.

Overview

Overview

As the product designer leading this project, my primary responsibility was to establish a unified design system for the client’s growing suite of digital products. The client’s teams were working in silos with inconsistent style libraries, disconnected components, and limited adoption of design tools, which led to inefficiencies, duplicated work, and slower product releases. The primary challenge was to create a scalable, accessible, and well-documented design system that enabled consistency across multiple products and supported multilingual requirements including right-to-left (RTL) languages like Arabic.

As the product designer leading this project, my primary responsibility was to establish a unified design system for the client’s growing suite of digital products. The client’s teams were working in silos with inconsistent style libraries, disconnected components, and limited adoption of design tools, which led to inefficiencies, duplicated work, and slower product releases. The primary challenge was to create a scalable, accessible, and well-documented design system that enabled consistency across multiple products and supported multilingual requirements including right-to-left (RTL) languages like Arabic.
Industry

Aviation

Year

2024 . 4 months

Platform

Web . Responsive

Role

Senior Product Designer (DS)

Team

2 Designers, 1 Team Lead & 2 Engineers (Client-side)

Deliverables

Foundations . Tokens . Components . Theming Architecture . RTL Support . Page Templates . Documentation . Training

⛓️‍💥Problem Breakdown

One airline, multiple products, no shared design language.

One airline, multiple products, no shared design language.

As digital products expanded across booking, loyalty, and operations, teams evolved UI patterns independently. Similar components looked and behaved differently, reducing consistency and increasing delivery effort.

As digital products expanded across booking, loyalty, and operations, teams evolved UI patterns independently. Similar components looked and behaved differently, reducing consistency and increasing delivery effort.

  • Outdated style library and low adoption

  • No shared spacing, type, elevation, or grid system

  • Duplicate components rebuilt across products

  • No scalable RTL strategy for Arabic interfaces

  • Tooling migration, Adobe to Figma was an unspoken dependency of any system effort.

🔍Research & Ideation

Inventory what existed first, then align teams around what matters.

Inventory what existed first, then align teams around what matters.

I audited recurring UI patterns, ran cross-functional workshops, and mapped workflow constraints to identify where inconsistency was creating the highest design and engineering friction.

I audited recurring UI patterns, ran cross-functional workshops, and mapped workflow constraints to identify where inconsistency was creating the highest design and engineering friction.
01. Audit Design Assets

Audited every active product screen, cataloging recurring UI patterns, behaviors, and accessibility considerations across products.

200+ Unique visual treatments needs conversion to fully functional components

01. Audit Design Assets

Audited every active product screen, cataloging recurring UI patterns, behaviors, and accessibility considerations across products.

200+ Unique visual treatments needs conversion to fully functional components

Audit Design Assets

Audited every active product screen, cataloging recurring UI patterns, behaviors, and accessibility considerations across products.

200+ Unique visual treatments needs conversion to fully functional components

02. Cross Functional Workshops

Mapped high-friction inconsistencies in delivery workflows

Identified rework causing inconsistencies

02. Cross Functional Workshops

Mapped high-friction inconsistencies in delivery workflows

Identified rework causing inconsistencies

03. Tooling and workflow assessment

The team wasn’t using Figma yet, so understanding their workflow was key to creating an adoptable system

Limited Figma expertise during the transition from Adobe tools

03. Tooling and workflow assessment

The team wasn’t using Figma yet, so understanding their workflow was key to creating an adoptable system

Limited Figma expertise during the transition from Adobe tools

📊 Strategy & Key decisions

The project was defined by architectural decisions, not just outputs.

The project was defined by architectural decisions, not just outputs.

🧩 Foundations

Consistency became automatic through system foundations.

Consistency became automatic through system foundations.

Color, typography, spacing, and elevation were standardized through semantic tokens and variable frameworks, enabling reusable components that adapt to product and language context.

  • Semantic color roles with accessibility in mind

  • Script-aware typography for Russian and Arabic

  • Shared spacing and grid logic for LTR and RTL

  • Token-based elevation system, no ad hoc shadows

Color, typography, spacing, and elevation were standardized through semantic tokens and variable frameworks, enabling reusable components that adapt to product and language context.
  • Semantic color roles with accessibility in mind
  • Script-aware typography for Russian and Arabic
  • Shared spacing and grid logic for LTR and RTL
  • Token-based elevation system, no ad hoc shadows

📈 Component system & scaling

Reusable architecture with behavior built in.

Reusable architecture with behavior built in.

A library is only as alive as the team that maintains it.

Component Architecture - l built the library in Figma using a strict pattern: one component, one source, with variants for state and properties for configuration. Each component shipped with:

  • Documented anatomy (parts, slots, tokens consumed)

  • Full state matrix (default, hover, focus, active, disabled, loading, error)

  • LTR and RTL layout behaviour

  • Engineering handoff notes with mapped token names

A library is only as alive as the team that maintains it.

Component Architecture - l built the library in Figma using a strict pattern: one component, one source, with variants for state and properties for configuration. Each component shipped with:

  • Documented anatomy (parts, slots, tokens consumed)

  • Full state matrix (default, hover, focus, active, disabled, loading, error)

  • LTR and RTL layout behaviour

  • Engineering handoff notes with mapped token names

Iterative delivery with feedback loops - Components were released in batches and validated in real workflows to uncover edge cases and adoption friction early.

Scaling across products & languages - A single token-driven system supported multi-brand theming, RTL layouts, and reusable templates across flydubai’s ecosystem.

Documentation & governance - Clear guidelines and contribution rules ensured the system remained scalable, maintainable, and sustainable long-term.

Training & enablement - Hands-on workshops enabled teams to confidently adopt, maintain, and extend the system independently.

🪏 Deep Dive — RTL & Multi-Brand Theming

The two hardest problems in this system, and the ones that make it genuinely scalable.

The two hardest problems in this system, and the ones that make it genuinely scalable.

Most design systems support one language direction and one brand. This system had to scale across Arabic + English experiences and multiple flydubai product brands — without creating parallel libraries.

  • RTL was built as a component-level behavior, not a visual flip - layouts, icons, typography, inputs, and alignment rules adapted intelligently based on language direction.

  • Multi-brand theming was handled entirely through semantic tokens - the same components and templates powered multiple brands by swapping token values, not rebuilding UI.

  • RTL was built as a component-level behavior, not a visual flip - layouts, icons, typography, inputs, and alignment rules adapted intelligently based on language direction.

  • Multi-brand theming was handled entirely through semantic tokens - the same components and templates powered multiple brands by swapping token values, not rebuilding UI.

Result - Designers could switch brand and language at the start of a project, while the system automatically handled layout mirroring, typography behavior, icon direction, and visual identity consistently across the experience.

Result - Designers could switch brand and language at the start of a project, while the system automatically handled layout mirroring, typography behavior, icon direction, and visual identity consistently across the experience.

Most design systems support one language direction and one brand. This system had to scale across Arabic + English experiences and multiple flydubai product brands — without creating parallel libraries.

  • RTL was built as a component-level behavior, not a visual flip - layouts, icons, typography, inputs, and alignment rules adapted intelligently based on language direction.

  • Multi-brand theming was handled entirely through semantic tokens - the same components and templates powered multiple brands by swapping token values, not rebuilding UI.

Result - Designers could switch brand and language at the start of a project, while the system automatically handled layout mirroring, typography behavior, icon direction, and visual identity consistently across the experience.

🎖️RESULTS

What the system shipped and how it changed delivery.

What the system shipped and how it changed delivery.

"I had the pleasure of working with Tanu on implementing our design system, and her contribution was truly invaluable. She brought a clear vision and deep expertise to our brand principles, transforming them into scalable components, design tokens, and intuitive guidelines that will greatly improve consistency across our digital products."

Jeswin Lopez

Head of Products/Ancillary at flydubai

🪞Reflection

🏁Conclusion

What I would do differently.

What I would do differently.

  • Track adoption from day one - I’d launch usage analytics alongside the first library release to measure adoption earlier.

  • Align token naming with engineering sooner - Earlier collaboration could have avoided a mid-project taxonomy refactor.

  • Define accessibility criteria upfront - Documenting per-component accessibility testing earlier would have strengthened handoff quality.

What this project shaped in me

This project strengthened my ability to design for future scale, build systems that outlast their creators, and treat team enablement as a core part of delivery — not an afterthought.