Over the last several years, Zoomcar's product has grown from a single business line to having four consumer-facing business lines and three platforms to manage the whole business. Having a consistent experience across all of a business's products and platforms is essential for Zoomcar's success.
While the company grew, so too did the size of the team. Zoomcar needed an internal style guide and design system to act as the source of truth for the product organization. This system aimed to bridge the gap between designers and developers, making it easier to collaborate and ship products faster.
Why Build it?
Our problem was no different from companies that had a fast growth phase. Both tech and design debt started weighing us, making iterations and new releases harder. For us, Design System on a high level served to solve three major problems.
Inconsistency
This was one of the significant problems we wanted to solve with the introduction of the design system. Our app had so much inconsistency that users moving between screens felt like a different app experience. In our five years, multiple designers worked on it. There was no single design directional perspective that everyone could align with.
Inefficiency
Each designer and developer was reinventing components on each project basis since nobody had a centralized place to look for what was already build.
Designers have to spend a lot of time making sure each component handles all the edge cases, which meant less time focusing on understanding user problems.
- Where is the updated sketch file. Who edited it last?
- Did this icon was already made?
- What color can I use here?
- Why did you develop this component? It was already made before, right.
- Why it's PNG here, and there it's SVG?
These kinds of questions and discussions started talking about a lot of our daily workhours.
Developers also had the same problem. We had around four definitions for a button component in the codebase at that time. Thus any change to button style in the future requires changing the code at all four places.
Mindset
I believe there exists a threshold point where people wanted to fight for managing inefficiencies. If that threshold is passed, then people will stop caring about Ineffciesiess. Inefficiencies will start to grow exponentially more time we are in that state.
We wanted designers & developers to fight for the time they needed to clear design and tech debts. This was only possible if they understand there existed a shared purpose to fight for.
Getting Started
After going through endless Design Systems & case studies that existed at that like carbon design systems, Polaris, lightning, etc., we realized a few things.
- We can't simply move our entire Design to a new design system language. We didn't have that much resource to allocate.
- With this project's massive scope, we will not get top-level management without proving its value in the long run.
The question we were trying to answer was, where do we start?
Start Small
We had a new project in the pipeline to build an end to end experience for renting eScooter. This became our segway to develop & test our MVP design system. eScooter was launching as an experiment-type project. This gave us a lot of freedom to experiment with a few things without much friction from stakeholders.
Instead of rethinking our entire existing components, We started laying foundational level things like color, type, spacing, elevation, etc. The foundation is essential for guiding our work in a united direction while searching for creative design solutions individually.
We also worked on very low-level components like buttons, icons, etc. We knew there was a good chance to relook these components when we scale the Design System.
With a few foundational level things and few low-level components, we started talking about design systems in every conversation we had with developers for that project. Luckily we had early adopter engineers who were interested in our vision.
With this launch, we were able to achieve few things we wanted.
- Tokenized our colors, shadows & types in code.
- Introduced few low components like Button, Icon, Illustrations
- Helped to establish trust among stakeholders
- People were started getting interested in our vision
Create Noise
The next step was to get buy-in from all the stakeholders to adopt the Design System at the company level. The answer to this was creating more visibility on the work we did for eScooter and how it added value to the business.
Over the next couple of weeks, we started giving many presentations to almost all the company stakeholders.
We also did a polling session with our leadership and engineers to determine what we will call the system. We finally ended naming it "Drift Design System."
We also created a Gitbook. More than documentation, it was a tangible thing we could show to different people during the conversation.
With all the noise we created, we were able to align stakeholders on the following terms.
- Any new feature we design will adopt a new design language.
- We will adopt DLS to the existing Design when the company decides we need a redesign.
Yes, we knew it would make the app experience more fragmented, but we also knew we could adapt to a new system within time.
Drive Adoption at Scale
The next problem was how to take the Design System and scale it to our entire product line, which had 4 Consumer-Facing products and 3 Platforms. We wanted to set a few ground rules before we started thinking about the scale.
Setting Parameters to the System
We defined a few characteristics of how the Design System will be evolved over time.
Rules: Strict Vs. Flexible - To minimize deviations, core modules in DLS are specified strictly.
- Typography treatments are strictly defined.
- There is an eight-pixel grid used for spacing.
- Shadows are documented.
- Naming conventions are consistent.
We maintained strictness, at least in our mobile ecosystem. We did this since we knew people would not use the freedom that comes with a flexible system to impact our end users positively.
Team Model: Centralised Vs. Distributed - We had chosen a centralized approach for maintaining the design system. A few of reason why we did this was
- It served many product verticals, free from the bias of any product verticals.
- It enabled to move much faster.
Build Tools for Adoptions
We invested the time in building a couple of tools, which helped both engineers & designers to adopt design systems.
- One was a service which used to maintain our icons. Once icons are merged, files are merged in Abstract. It automatically generates device specifics formats.
- A Zeplin Extensions to show few design tokens like shadow values and some platform-specific rules.
We continue working on improving these tools that help designers and developers managing Design less dreadful. We wanted all our designers to handle the user's problem instead of focusing on maintainability and other things.
Change in Design Culture
To ensure all designers are shipping designs based on design system guidelines, we introduced a couple of steps in our design process.
Before Dev Handoff, the designer working on the project has to conduct a design system review meeting. In the meeting couple of things are checked & discussed.
- If components are rightly resued.
- If there is an introduction of a new component.
After all, the feedback from this meeting is made, only it is added to Zeplin for engineers.
Where are we Now?
For the past year, we have been working on a design system. Still, it is very much an evolving System. But as of this date, we were able to achieve a fair amount of progress.
- We are currently happy that 70% of our main app is in our new design system, with 100% adoption over the horizon.
- We expanded our system to support web platforms.
- Conversations are happening around maintaining the System between Designers and Engineering, which was a massive win.
Learnings
We were well aware we did cut down on a few places since we had limited resources to begin this project. Here are the few things I learned over the entire course of building this system
Documentation
A significant way that documentation helps with adoption is by providing an unambiguous reference for people who want to get started with the design system.
We started building the Design System with a small team. When we started scaling to all teams, there was a lot of confusion on using the design system, especially among people who recently joined the company. This kind of ambiguity slows people down and creates friction for design system adoption.
Team Model
A massive benefit of centralized design teams is that experience is unified and consistent across many products. In this way, centralized teams have a high vision instead of an incremental vision of a single product.
On the contrary, designers who were not part of the design systems team became distant it resulted in the slow discovery of constraints in each project.
We should have a set process that enables us to get feedback and analysis it from a broader audience.
Give Voice to the System
There were many instances were adding things to the existing system would have solved user problems quickly. But now we had to manage that added complexity of the system also. We have to play the balancing act of solving user problems and maintainability of the system.
Ex: Instead of merely adding a subtext to the 'Button Component,' we had to make multiple versions for the stakeholder without changing the system. I know it was a small change, but the compounding effect of numerous changes is enormous. It would lead us precisely to the same position we started with.
Track Metrics
Even though we had metrics to track design systems, different adoption metrics, it's tough to measure people's happiness, or the impact on how people work in terms of UI, or the teams' efficiency and velocity in delivering updates and new features to the product.
A couple of additional metrics I would have tracked if I am starting from scratch would be.
- Time needed for QA
- No of Design related debts
- Usability metrics
- Team NPS
Major Takeaways
For those of you who are considering building a design system, here are few tips.
- Find a real place to start. It's essential to show the value of a potential design system by solving a small problem first. A design system by itself doesn't have any value. It only serves a purpose when applied to a real problem.
- Drive adoption and gauge progress. The actual work starts once the adoption begins. Design systems are only worthy once they are fully united into the team's workflow.
- Every company is unique. It may get overwhelming, seeing other company's design system progress. But there is no point in this comparison since we don't know the context in which they build the system. Maybe they didn't have to fight to align the stakeholders. They had different engineering culture. They had more resources. It can be a lot of things. So stop comparing and adopt a process that works for your company.