Atlas Design System

The Problem

When I joined Alibaba Travels in late 2019, rapid growth had created a design mess. Six different business verticals (flights, hotels, tours, insurance, trains, buses) each had their own patterns, components, and ways of doing things. What started as reasonable autonomy had turned into fragmentation.

The symptoms were obvious. Designers spending 60% more time than they should on routine work. Engineers rebuilding the same patterns over and over across different products. Users getting a disjointed experience even though everything was supposed to be one platform.

But the real problem was organizational. We didn't have the infrastructure or processes to scale design work systematically. We needed to transform design from a service function into a strategic capability.

Understanding the Situation

I started with a diagnostic using Nielsen Norman Group's UX maturity framework. After interviewing stakeholders across product, engineering, and leadership, it was clear we were at Stage 2 (Emergent). Inconsistent processes, ad-hoc quality, limited executive understanding of what design could actually do.

The audit revealed deeper issues. Twelve designers serving 20+ product squads with no shared workflow, no version control discipline, limited cross-functional collaboration. Engineers frequently interpreted designs differently. Product managers treated design as late-stage polish. We were hemorrhaging efficiency.

I established three principles for Atlas. First, accessibility as foundation. WCAG 2.1 AA built into every component, not added later. Second, RTL-native architecture. Persian and Arabic as first-class concerns, not afterthoughts. Third, performance-conscious defaults. Optimized for users on slower connections and older devices.

Building the System

Building Atlas required working on two fronts simultaneously: technical and organizational. On the technical side, we needed components, tokens, documentation, and tooling. On the organizational side, we needed governance, workflows, and cultural buy-in.

I broke the technical work into three phases. Phase one established foundations: design tokens for color, typography, spacing, and motion; a core library of 30 essential components; comprehensive Figma libraries with proper variant structures. We started in Sketch, migrated to Figma as it matured. The migration was painful but taught us valuable lessons about planning for change.

The typography work deserves mention. Most Arabic typefaces prioritize aesthetics over legibility, especially at small sizes. Working with a type designer, we created a custom font optimized for Persian and Arabic script. It tested 20-30% better for readability while being smaller in file size. Not perfectionism, just recognizing that typography drives both experience and performance.

Phase two focused on scale. We expanded to 150 components, introduced composition patterns for complex interfaces, and built vertical-specific components where shared patterns couldn't work. Flight booking, for instance, needed custom calendars that handled Persian calendar systems, dynamic pricing, and multi-city itineraries. Problems the core system couldn't solve alone.

The Organizational Side

Technical systems fail without organizational support. I set up a governance council with reps from each vertical, product leadership, and engineering architecture. Biweekly meetings to review contributions, prioritize components, resolve conflicts between consistency and vertical needs.

This proved critical during COVID. When the pandemic hit travel demand in early 2020, there was pressure to pause design system work. Instead, we reframed it as strategic investment. Used the slower period to accelerate component development and documentation. This paid off during recovery when teams could move faster with mature system infrastructure.

We built contribution workflows that balanced control with autonomy. Designers could propose new components through an RFC process requiring documented use cases, accessibility review, and engineering feasibility assessment. This prevented both bottlenecks and chaos. Clear paths to extend the system without fragmenting it.

Getting People to Use It

Adoption was our biggest organizational challenge. Engineers liked their existing patterns. Product managers questioned why "simple UI changes" needed system-level decisions. We needed to demonstrate value, not mandate compliance.

I developed a tiered strategy. Tier one: new products and greenfield work where Atlas could prove value without legacy constraints. The new insurance vertical launched entirely on Atlas, delivering in 40% less time than historical equivalents with better conversion. This became our proof point.

Tier two: incremental migration of existing products. Rather than forcing wholesale redesigns, we identified high-impact touchpoints (booking flows, search, payment) and migrated systematically. Each migration delivered measurable improvements: faster loads, higher conversion, reduced engineering maintenance. These wins built momentum.

Tier three: culture and capability. Design system office hours, certification programs for engineers, integration into onboarding. The system became infrastructure, not a project.

Impact

The numbers exceeded expectations. Conversion up 52% on average across migrated flows. Not because components looked prettier, but because consistency reduced cognitive load and systematic accessibility broadened reach. Design cycle time down 60% as teams used ready-made patterns. Implementation time down 40% with pre-built, tested components.

But the qualitative shift mattered more. We went from Emergent (Stage 2) to Structured (Stage 4) on UX maturity. Design became strategic with executive visibility, systematic processes, measurable business impact. Product managers started involving designers earlier. Engineers contributed to design discussions. Leadership saw design as competitive advantage, not cost center.

Atlas also enabled new capabilities. When leadership decided to launch a white-label platform for smaller travel companies, Atlas made it feasible. We could spin up new branded experiences in weeks instead of months. When regulations changed, we updated core components once instead of chasing changes across six codebases.

What I Learned

Design systems are organizational systems. The technical parts (components, tokens, docs) matter less than the processes and culture that sustain them. You can't just design system success. You have to design system adoption.

Three key lessons. Start with governance. Without clear decision rights and contribution workflows, systems become bottlenecks or chaos. Establish this early, even when the system is small. Measure what matters. Component count and adoption metrics tell partial stories. What matters is whether the system enables faster, better product development. Track cycle time, quality, team satisfaction. Systems are never done. Atlas required continuous evolution as needs changed, technologies emerged, expectations shifted. Build for maintenance, not completion.

Looking back, I would have invested in engineering tooling earlier. We built excellent designer workflows but engineering integration stayed manual too long. Earlier investment in code generation, automated testing, CI/CD would have accelerated adoption.

I also underestimated storytelling. Technical excellence doesn't sell itself. We needed clearer narratives about how Atlas enabled business outcomes, especially for executives approving resources and setting direction. The system succeeded because we learned to communicate value in business terms, not design terms.

Five years later, Atlas is still the foundation of Alibaba Travels' digital products. It's outlived my tenure, survived organizational changes, adapted to new technologies. Exactly what a mature design system should do. The real legacy isn't the components or Figma files. It's the organizational capability we built. The ability to scale design systematically, processes that turn individual craft into institutional excellence, culture that values consistency as much as creativity. Those capabilities persist regardless of tools or people. That's the work that matters: building systems that outlast their builders.