Standardized in-house design library into a scalable, multi-product design system - balancing global standards with CarTrade’s hyper-customisation needs. Reduced recurring dev/design effort worth ~₹1.07Cr/year, while improving consistency across 5 products and enabling measurable business impact.
The reason for building an internal library instead of relying entirely on standard component libraries was the level of hyper-customization required by CarTrade's products, particularly for patterns that had evolved during the 2010–2020 period.
At the time, this level of customization was difficult to accommodate within standard libraries.
Customizing components within a standard library was often almost not allowed. Teams would end up making CSS changes, modifying components, and then storing those modified versions as reusable entities anyway.
This created the need for a repository that could act as a playground for customized components, which was essentially the reason Oxygen was born.
However, as the products evolved and the need for hyper-customization continued to grow, there was a larger strategic question:
Should CarTrade move completely to a standard design system, or should the existing Oxygen library be matured to whatever extent possible while continuing to support its customization needs?
The project focused on the latter.
The project was an effort to mature the in-house Oxygen Design System to global design-system standards while retaining the hyper-customization capabilities that CarTrade's products required.
The goal was not simply to replace Oxygen with a standard library.
Instead, the objective was to bring structure, scalability, accessibility, consistency, and engineering readiness to an existing system that had grown organically over time.
I led several major initiatives under the design system to move Oxygen towards a more mature, globally aligned system.
These included:
1. Color naming conventions and tokenization
2. Multi-product handling through a single repository
3. Component guideline documentation
4. WCAG-compliant handling of color and typography tokens
5. Design-system enablement within the existing developer handoff tool
6. Component upgrades for SEO and semantic compatibility
7. Component style upgrades
**8. Glassmorphism - A delightfull experience that no design system has""
THE PROBLEM
Oxygen's colours were named visually - names such as Silver, Grey, etc. - rather than semantically. That worked for a single product, but became difficult when the same system needed to support multiple products and themes. Also, communication across organization was affected a lot - Suppose someone said - Use 'Silver' - Now 'Silver' is subjective. For some it may perceive as a lighter grey, for some its the shiny metallic one.
THE SOLUTION
I did my research and studied around 50 standard libraries and introduced a structured naming and tokenisation system based on categories such as Primary, Secondary, Neutral, Accent, Info and Miscellaneous, with sequential values such as Neutral-700 instead of visual names. Now 'Silver' had a name say 'Secondary 300'.
This created a single source of truth for colour usage. Theme changes and dark-mode transitions could now propagate systematically rather than requiring individual colour replacements. And also it will further support the multi-product handling from a single repository.
WHY IT MATTERED?
The naming convention wasn't just documentation. It became the underlying architecture that made Oxygen capable of supporting multiple libraries and themes.
CarTrade Tech wasn't a single product. The same design-system thinking had to work across CarWale, BikeWale, CarTrade and other product surfaces, each with different requirements.
Instead of creating separate component libraries for every product, I worked on structuring Oxygen so that one repository could accommodate multiple product requirements without fragmenting the system.
The principle was simple:
One foundation. Multiple expressions.
The tokenisation work from Project 1 was critical here because semantic tokens made it possible to change themes and product-specific values without rebuilding the component architecture.
A design system isn't scalable if people only know what a component looks like. They also need to know when, why and how to use it.
I introduced clearer component-level guidelines covering usage, states, variations and behavioural expectations. The intent was to reduce interpretation between Design, Product and Frontend and make the library easier to adopt.
This shifted Oxygen from being primarily a visual library towards becoming a shared language between teams.
Accessibility wasn't being treated as a system-level constraint. Colour combinations across the repository often failed modern contrast requirements, which meant individual product teams repeatedly encountered the same accessibility problems.
I audited the colour system and upgraded the palette towards stronger contrast while preserving CarTrade's existing visual character.
The result was significant: average accessibility scores in web diagnostics improved from ~50% to ~90%.
The next challenge was adoption.
A design system only creates value when designers and developers actually use it. I worked on enabling Oxygen within the existing design-to-development workflow so that designers could work from the same reusable definitions and developers had a clearer reference for implementation.
This reduced the gap between design intent and coded output and prepared the system for the much more ambitious design-to-code direction that came later.
The broader evolution eventually moved towards a 1:1 MUI-mapped Oxygen system, which improved development speed by about 40% and made the codebase cleaner and more scalable.
CarWale is heavily dependent on organic search. That meant a component couldn't be considered successful simply because it looked right - its underlying structure also needed to support semantic hierarchy and SEO requirements.
I worked with Product, SEO and Engineering to introduce component-level thinking around semantic HTML, heading hierarchy and content structure.
This made the design system better suited to the reality of CarWale: a product where UI, content and search visibility are deeply connected.
Oxygen also needed to catch up visually with trend.
Several components had accumulated over time and started feeling dated or inconsistent. I led a series of component upgrades — introducing newer interaction patterns, cleaner surfaces, updated controls, badges, filters and more flexible component configurations.
One example was the trim/variant filtering system, where a single flexible component could operate as a multi-select, single-select, dropdown or segmented control depending on the requirement. The upgraded components also supported increasingly complex automotive information without creating one-off UI patterns.
The goal wasn't to redesign everything.
It was to make the existing system more capable without making it more complicated.
Some of the most interesting design-system problems weren't traditional product UI problems.
CarWale's Skin is one of its highest-value advertising properties. The site background is replaced by an OEM's campaign creative while CarWale's actual product — cards, content and sections — continues to sit above it. An average Skin campaign can be worth ₹30–50L to the business, while Carwale cracks around 15-20 skins campaign deals with OEMs and dealers, making it a ₹7-8cr business every year. Hence we believed in solving it like a system and not a creative work everytime. Hence there has to be technical design process that solves it effortless every time.
The problem was that rich campaign creatives often competed visually with the product UI.
I introduced Glassmorphism as a systemised layer between the Skin and the product - giving product sections a translucent, blurred surface that preserved the campaign artwork while protecting readability and hierarchy.
The eight initiatives collectively transformed Oxygen from a component repository into a scalable design-system infrastructure supporting 5 products, ~200 developers, 20 PMs and 16 designers and 10 frontend engineers. With an estimated ₹18.1L/month (₹2.172Cr/year) of organisational effort involved in managing and consuming the system, the work focused on reducing repetitive design and engineering effort through shared tokens, reusable components, documentation, accessibility standards and stronger developer enablement.
Estimated Cost of Managing Oxygen
Frontend Engineers - ₹4L/m (50% salary of 10 FEs)
Product Designers - ₹60K/m (20% salary of 3 PDs)
Product Managers - ₹1.5L/m (5% salary of 20 PMs)
Backend Engineers - ₹12L/m (10% salary of 200 BEs)
Total Monthly Expenses - ₹18.1L/m
The impact extended beyond internal efficiency. Accessibility maturity improved from ~50% to ~90%, while component upgrades demonstrated up to 60% higher model clicks in one observed experience. The system also contributed to Skin, CarWale's ~₹6Cr/year advertising property, where the Glassmorphism intervention helped improve client adoption, with existing-client orders growing ~2% and new-client acquisition growing ~5% YoY.
Considering that the matured Design System eventually eliminates a conservative 30% of the recurring effort involved in managing Oxygen (₹2.172Cr/year), while generating an estimated ₹42L/year in additional Skin revenue, the final estimated benefit from these 8 initiatives is approximately ₹1.07Cr/year (₹65.16L + ₹42L).
Hence the final impact:
Oxygen management - 30% efficiency gain = ₹65.16L
Existing skin revenue - ₹42L estimated additional revenue
Accessibility - 50% → ~90%
Product scale - 5 products
Teams impacted - 210 developers, 20 PMs, 16 designers
Total estimated annual gains - ₹65.16L + ₹42L = ₹1.07Cr/year
- A standard design-system library was not adopted immediately.
- The reasons for retaining Oxygen and evolving it were explained earlier: CarTrade's products had accumulated a significant degree of customization, and simply switching to a standard library would not have addressed all of those requirements.
- At the same time, the project was not executed as a single large migration.
- Everything was not changed in one go.
- The evolution of the design system took approximately 2.5 years, with changes introduced progressively across the system.
- This allowed the team to mature the existing library while continuing to support ongoing product and business requirements.
Looking back, these eight initiatives were less about building individual components and more about progressively removing ambiguity from the organisation.
We moved from:
Visual decisions → semantic decisions → system decisions → organisational decisions.
Colours gained meaning through tokens.
Components gained rules through guidelines.
Products gained a shared foundation.
Accessibility and SEO became system constraints rather than downstream fixes.
Components became more flexible without becoming uncontrolled.
And Skin showed that the design system could influence a revenue-generating business property, not just product UI.
Most importantly, this work taught me that a design system should not be treated as a static library.
It is an organisational infrastructure.
Its job is to make good decisions easier to repeat - across designers, developers, products and eventually, machines.
That foundation became particularly important as CarTrade entered the next phase of its design-system evolution: building a system that could work with AI-assisted design and development.