Design Systems at Alibaba
How we built an RTL-first design system and maintained it during a major redesign.
Alibaba is the leading Travel and Hospitality company in Iran with over 4M MAU.
In the past few years, Alibaba has been growing rapidly in multiple verticals and has penetrated new markets. And the need for faster development without having a scalable foundation caused many challenges for the design and development teams.
This is the story behind building our design system and the challenges we went through in maintenance during a major redesign of our products from 2020 to 2022, in which I initially pioneered as a Product Designer, and later on led the Design Systems initiative and the redesign of the funnel for the web.
History
In late 2019, our design team was in the emergent stage of UX maturity. We had fundamental UX problems in our products and the products’ interface was outdated. The development cost of features was high and often minor fixes needed major refactoring on the engineering side. The front-end team was considering a codebase rewrite due to performance issues and we felt that a redesign was needed.
On the other hand, our design team getting larger along with the company’s wide portfolio of products with different business requirements caused us to face different challenges at scale:
- Solutions couldn’t scale between products due to a lack of reusable patterns and guidelines
- Designers often overrode the design with their personal style which would cause inconsistency between products and channels
- Both design and development were time-consuming
- Every solution was designed with only a desktop-first mindset
So to achieve consistency and efficiency, the decision to invest in a design system was a no-brainer. But how we wanted to approach it, was a big question.
In the following, I will explain a series of these challenges.
Chicken or Egg?
We faced a chicken or egg dilemma whether we should start with a redesign and then define a system based on the new design to reduce possible reworks or we should establish the design system based on the current state and then go through a redesign.
To address the situation, we established that:
- The redesign was going to happen gradually.
- Every design decision had to be backed up by data.
So we couldn’t just revamp everything without defining a baseline and metrics to measure the success of changes. We finally decided that it’s more principled to build a foundation based on the current state of our products but visually enhance it before the upcoming redesign.
Free-size or Taylor-made?
It’s crystal clear that building a design system from scratch at this scale is a time-intensive effort, But:
- We knew there was a major redesign ahead of us, so there were going to be lots of new requirements and changes in each product so we wanted complete control from the start.
- We had to consider particular customizations and adjustments like styleguide refresh, the future rollout of our custom brand typeface, and RTL-first patterns that couldn’t be met by existing open-source design systems.
So despite the difficulties, we chose a hybrid approach. On the design side, we decided to build everything from scratch, but to lower the cost and implementation effort on the engineering side we utilized existing Vue libraries that gave us basic components that we could start from.
Grassroots vs Top-down?
Despite the leadership's awareness of our decision and efforts throughout the whole process, we didn’t have any support like dedicated resources or a broad timespan for our first release. But on the flip side, some of us who were more enthusiastic pioneered putting together a design core team.
And so began our journey of building our design system “Atlas”, which I divided into 4 phases: Foundation, Redesign, Maintenance, and Growth.
Phase 1 — Foundation
In the design core team, we planned and designed version one together. Our team’s main responsibilities were to build, maintain, educate and support.
After a period of research for best practices, we performed interface audits through the whole digital portfolio to identify basic patterns and define the core UI components with the highest reusability across our products and channels in Alibaba.
We also wanted to renovate our visual interface to have a modern, clean and fresh look. So in parallel, we defined a refreshed styleguide consisting of a new color palette, typeface, and a redesigned icon set.
In the next step, we applied accessibility guidelines to the system.
After almost 3 months of intense work, reviewing, revisioning and testing, the design core team built a refreshed foundation. The end result was a significant number of styles and components. We wrote basic specifications along the way and tested many documentation tools as well.
Our tool of choice for developer handoff was Zeplin because of features like Global Styleguides and Connected Components. We utilized Zeroheight for some time, but maintaining another source was a tedious job, so we chose Zeplin for keeping documentation. And for a more live version of components, we used Storybook to keep tokens and code assets.
Finally, we released the new styleguide and component library for the whole design chapter so they could start to adopt the new design language. Using Abstract as our version-control tool with rigid governance, peripheral designers had no edit access to libraries, and the core team decisions would just propagate out to the teams.
Phase 2 — Redesign
It wasn’t long after the adoption that the redesign initiative started throughout the organization. Both the front-end and back-end engineering teams started to rewrite and upgrade their infrastructure.
As for us, the design and research teams defined their expectations and success metrics alongside the product team.
The product team started documenting the user stories and gave us future requirements. In addition to that, Research and CRO teams gathered existing data on current users' behavior and using these qualitative and quantitative reports we gained insight into current issues.
After the initial adoption of the design system, the designers then started to redesign the respective products simultaneously using all the given data and requirements. We revised the information architecture of components and had major changes in the contents and flows. We also rebuilt the PWA from the ground up with a mobile-first approach.
Most of the important design decisions were either tested on our legacy website or it was validated through tests.
We also tackled a lot of new visual inconsistencies between products after the redesign, and resolving them was a team effort. Reviewing each step of the funnel of all the products altogether enabled us to better inspect and understand the context of each product and resolve inconsistencies simultaneously. but either way, normalizing and maintaining these continuous changes in the system was a labor of Hercules.
Change Management
Following the covid recession in 2020, the travel industry was one of the most impacted industries all over the world and we were no exception.
The core team disbanded, everything became remote and all of the design team members got busy with the redesign. This sudden changes in the distribution of our effort slowed down our momentum. At this time besides being in a product team myself, I was burdened with most of the planning and maintenance efforts of Atlas.
As the lead of operations for the web redesign I was in charge of:
- Actively planning and scoping for adoption and redesign
- Overseeing adoption progress and compliance check
- Coordination with designers and managing assignments
- Optimizing styleguide and components
- Keeping the library and changelogs updated
At this point, the system mostly enforced standards and offered minimum flexibility.
Phase 3 — Maintenance
After the redesign was almost done and the design team fully adopted Atlas and the component structure was stable enough, we formed a multidisciplinary core team including DSM, PM, front-end engineers, and QAs with the core functionality of implementing Atlas in Storybook and also the newly designed products based on it.
As a Product Designer in this team called the Web Experience team, I was in charge of redesigning most of the general components and features of funnels for both Desktop and PWA.
This was the time when the heaviest lifting work was done by the core team. Day and night efforts to release before the deadlines.
At this phase as the DSM, I led the funnels handoff process for the web and I was in charge of:
- Scoping and prioritization for design system handoff
- Partnering up with Design Director and Product Leads for planning launch plans
- Partnering up with QA to perform UI checks
- Coordination between peripheral designers and front-end core team, providing support and guidance
- Preparing assets and providing basic documentation for components based on each product’s context (anatomy, naming conventions, etc.)
The system’s value is realized at scale.
As I mentioned before the continuous changes during the redesign process created new challenges: new inconsistencies, bloated libraries that needed restructuring and organizing, and besides all that serving different products was adding more complexity. But it was through these problems that we could battle-test our design system.
By this time I managed to optimize most of the styles and refine basic components. And it was tricky to balance consistency and flexibility, to be able to handle changes at this scale while not limiting designers.
Each product had different business requirements that needed a unique pattern to cater to them. To tackle these issues domain knowledge of all the verticals was necessary to understand each context and balance it with maintainability.
Products of the same family or “tribes” had often similar patterns that could be identified as a subset.
More complex components were broken into sub-components to support specific contexts that couldn’t be handled with configurations, which offered more flexibility for the designers.
Phase 4 — Growth
At this point the engineering team implemented Atlas and we launched the new products for both the website and app platforms, but there were still other areas in the development pipeline that kept the engineering teams busy and due to a lack of resources, the active development on Atlas paused so we decided to play catch-up writing documentation.
Another issue was that even though we had utilized Storybook as a source of truth but the engineering core team still needed help to maintain and propagate the adoption of Atlas in their chapter. So to ensure continuity and prevent possible inconsistencies in the codebase I drafted a governance model so we could align the design and development more in line.
As for many other companies, at this point, we went through a transition between design tools and migrated from Sketch to Figma. We started Figma migration with significant help from team members and restructured components based on Figma’s variants.
As I mentioned before, at the beginning of our journey we had rigid governance with no edit access to libraries for peripheral designers.
But during migration, I tried to get rid of some of the limitations by eliminating unnecessary governance. This was due to the fact that besides being in two other teams as a Product Designer and having my role as the DSM, it was exhausting to be a single maintainer. And considering the migration plan, I decided to distribute the workload among team members.
To pull out more participation, the whole team was given edit access to some libraries so that they feel more ownership, and see themselves as the contributors of a shared system. So I changed the library structure based on the concept of Access Level and came up with contribution models for those libraries.
I also established daily meetings called “Atlas Daily” to get the team more involved and to onboard them about the decisions behind the structures and build patterns.
ROIs
There are still lots of room for improvement, and we are still trying to improve our processes and documentation. But we’ve been able to make a huge impact as a team on the maturity of products and business operations.
Operational Improvements (Design System)
- Efficiency: 50% faster design to development handoff (average cycle time of a regular feature)
- Maintainability: 65% decrease in codebase, up to 20% less ongoing maintenance (after phase 3)
- Consistency: 80% adoption across channels, but an increase in support requests (due to new product lines)
- Autonomy: Accessible libraries with contribution guidelines
- Scalability: A stable foundation that will support new product lines for the next years to come
Product Improvements (Redesign)
- Conversion Rate: 52% average increase
- Orders: 65% increase (PWA)
- Sessions: 30% increase (PWA)
- Efficiency: 55% increase in PageSpeed score for web channels (PageSpeed Insight)
- Accessibility: 30% increase (Lighthouse)
Key Takeaways
Having been involved in the design of Atlas from the ground up, contributing to most of the maintenance and documentation efforts, I have been the main decision-maker, which was necessary at the time. but over time I tried to involve all members of the team in the decisions and avoid becoming a SPOF.
Starting with a federated team model is an economical choice at large scales, but this model may not be sustainable in the long run, as it needs allocated individuals with dedication. At some point, there should be a centralized part of team members who are responsible for updating the library, otherwise, the design system gets outdated.
Many of us with smaller teams and limited resources shouldn’t compare our design systems to huge ones of companies with big teams. Instead, we should create our own metrics for success.
According to Gall’s Law, all complex systems evolved from simpler systems that worked. It’s so cool to start with a multi-layered token system, but sometimes based on the product's time and resources it’s practical to start with the current requirements and needs of the team and gradually make progress toward more complexity.
It’s not strange that the business might not be interested in design system topics. Business usually cares about: savings, reducing risks, and increasing productivity. So to get resources and plan to put effort into design systems, we need to work backward from those outcomes and sell the design system as a capability by making a business case, showcasing proof of concept, and pitching the ROIs to the business.
As a craftsman, I was not much into advertisements or any kind of show-off, but I found out that a Design System isn’t just about design and development effort, but marketing and building an internal community are as important. So in order to symbolize our achievements and keep the collaboration and contribution spirit, we came up with a name and visual identity for our design system.
Thank you
It would be a long post if I had included every detail, all the great work that happened in the past 3 years, and all the contributors who have helped us along the way. But thank you!
At a minimum, I want to give shout-outs to some special folks who have directly helped build and support design systems at Alibaba over the recent years: Hasan Hemmati, Nazanin Chekinipour, Milad Gheisari, Sasan Farrokh, Mohammad Hooshdar, Mehdi Hosseinipajoh, Mostafa Amini Nasab, Ali Saeedi, Milad Mirzaei, Hossein Mirsaeedi. The incredible research team who helped us with the redesign: Nayyereh Afzali, Mohsen Dehghan, Hamed Astaraki, and Sajede Pourvali.
And special thanks to Ehsan Fathian, Mona Hosseini, and Saeed Hosseinirad.
In the future, I will be writing more about Design System management and Design operations, so stay tuned.
