Scaling a design system for India's third largest bank - Axis Bank

Scaling a design system for India's third largest bank

Reduced time-to-market by 30%, used across 25+ products

SUBZERO DESIGN SYSTEM

DESIGNOPS

Impact HIGHLIGHTS

1.2 M+

1.2 M+

1.2 M+

component inserts from the library in FY 23-24

component inserts from the library in FY 23-24

30%

30%

30%

reduction in design-development time

reduction in design-development time

25+

25+

25+

products across the axis ecosystem built

products across the axis ecosystem built

Overview

Axis Bank is one of India’s largest and most trusted financial institutions, serving millions through a wide range of digital products, from retail banking apps to enterprise dashboards and investment platforms. Drawing from my love for structured systems and scalable thinking, I helped evolve Subzero into a full-fledged design system. I focused on reducing design debt, aligning designers and developers, creating responsive component guidelines, and setting up a governance model that brought 25+ products into sync.

My Role

Governance and adoption, scaling across breakpoints, UI pattern library development, migration of old products, design-dev sync

Timeline

2023-2024
Always a work in progress -
like any design system is!

Team

3 designers
8 developers
1 project manager

Introduction

Building is the first step. Scaling is where the real maturity begins

Scaling is about taking it from 1 to 10, where a design system stops being a collection of assets and starts becoming a shared language, a decision-making tool, and a backbone for consistent, scalable product development.

It meant building rules, not just components. Designing not just for today, but for every team that would use the system tomorrow. I focused on making Subzero a system that developers trusted, designers loved, and product teams could rely on across 25+ digital products.

25+ products within the Axis Ecosystem are built using Subzero

Scaling

Defining component and scaling standards

As our components were being used across mobile, tablet, and web platforms, I noticed design breakdowns due to inconsistent sizing and layout behavior. To fix this, I defined variants, and created responsive guidelines for scaling components. This helped teams scale components fluidly across touchpoints while maintaining visual harmony and dev alignment.

Patterns

I turned inconsistent repetition into a standardized library

Being on the design system team gave me a bird’s-eye view of how different financial products were being built in the organization. I noticed that across credit, savings, investment and more, teams were repeatedly creating similar modular flows like KYC, MPIN setup, NPS, from scratch. This repetition often led to inconsistencies and friction, both for users and internal teams. I took the lead in identifying these recurring UI patterns, mapping them across products, and working closely with designers and developers to formalize them into a centralized system pattern library

Operations

Establishing a system of governance

Many design systems fail not because of poor design, but because of poor governance. People stop trusting or using the system if there’s no clear way to contribute, request, or evolve it. When I started scaling Subzero, there was no centralized way to:

  • Request new components

  • Give feedback on existing patterns

  • Ask questions or suggest improvements

  • Get guidance on DS adoption in their product

When you're scaling a design system like Subzero across 25+ digital products, governance isn’t a luxury but a necessity. Without it, every team starts doing their own version of “what looks right.” So I designed a simple but effective framework that gave Subzero structure, and gave teams confidence.

Migration

Tackling design debt at a very very large scale

Before our internal tech teams were fully in place, many of Axis Bank’s digital products were built and shipped through external vendors. While this allowed for faster initial rollout, it also led to a major side effect: fragmented design ecosystems. Even as we rolled out Subzero, many designers continued using legacy kits specific to their vendor team or past projects because migrating felt effort-intensive. That meant developers, too, were still building with outdated systems, perpetuating the design debt and delaying standardization. This was costly for the business. Teams were reinventing the wheel, wasting time rechecking decisions, and unknowingly drifting further from a cohesive experience.

Documentation

Making designer and developer onboarding easier

As part of the Subzero 2.0 initiative, I led the creation of the design system’s official website and documentation platform, transforming it into a single source of truth for designers and developers across Axis Bank. The goal was simple: make onboarding seamless and ensure that anyone using the system, whether new or experienced, could easily understand its rules, guidelines, component anatomy, dos and don'ts, and limitations.

Takeaways

Collaboration is key to make a robust, adoptable design system

1

A design system is never ‘finished’

When we first started building Subzero at Axis Bank, I thought we were working towards a clear finish line, one day we’d have all our components, documentation, tokens, and governance in place and we’d be done. But with every update, I realized that a design system is less of a project and more of a living organism. It breathes, adapts, grows, and sometimes even breaks, and that’s what makes it powerful.

2

A system doesn't always work how you imagined

It’s easy to believe the system you’ve built is perfect—until you realize it only works for people if it’s built with them. A design system lasts only as long as people feel heard, involved, and able to challenge it. Without feedback, it stops being a system and starts becoming a rulebook no one wants to follow.

3

Building a system in silos is a myth

Some of the most meaningful progress we made wasn’t behind a screen, it was in messy conversations with engineers, negotiating edge cases, defining tokens together, or syncing with product managers to understand roadmap priorities. It was about reading the room, translating design intent into engineering logic, balancing consistency with flexibility, and knowing when to stand your ground vs. when to adapt. I had to become a translator, a mediator, and sometimes a gentle nudger, turning design intent into engineering logic and advocating for shared ownership.

Let's brainstorm ideas together!

rhythm.gauba@gmail.com

Made with ❤️ in Pittsburgh | © Rhythm Gauba 2025

Let's brainstorm ideas together!

rhythm.gauba@gmail.com

Made with ❤️ in Pittsburgh | © Rhythm Gauba 2025

Let's brainstorm ideas together!

rhythm.gauba@gmail.com

Made with ❤️ in Pittsburgh | © Rhythm Gauba 2025