Case study · Y.Design · Yubi · 2022 to 2025

One system. ₹186Cr saved.

In FY22, Yubi was burning $50.4M a year in engineering while five brands and thirteen products drifted apart. Y.Design, a token-based multi-brand system, brought the $140M ecosystem back to one language and cut operating costs by ₹72 crore in FY24, then ₹186 crore in FY25.

My roleDirector of Design · System architect
Reporting lineDirectly into the CPTO
Team20+ designer org · platform pod + federated contributors
Timeline2022 to 2025 · 3 years
ScopeDesign systems · DesignOps · AI workflows · Governance
Outcome₹186Cr saved FY25 · 85% adoption
01 · Why Y.Design
Fragmentation was a hidden tax on everything.

FY22 closed with $50.4M burnt in engineering cost for creating products and new features, with limited resources to show for it. The majority of the products had drifted from the original product and identity, and users struggled to relate to them. When a user switched from one platform to another, the entire experience went for a toss: the learning curve went up, familiarity went away, and a platform meant to be self serve turned Ops heavy instead.

Every inconsistency was a conversation that hadn’t happened. Every rework was a cost nobody had calculated. So I calculated it: crores of engineering rework a year, all traceable to fragmentation.

The problem, on screen
Thirteen products, and no two of them agreed on anything.

The audit made the chaos undeniable. Navigation flipped between top bars and left rails, sometimes within the same product, and the app switcher lived in a different place on every platform. Filters fought layouts for the same screen real estate. Backgrounds ran light blue, grey, or white with no logic, and cards disagreed on radius, shadow, stroke, and padding. None of this was any team's fault. It was the natural result of 13+ products shipping fast with no shared language.

Problem areaWhat the audit foundWhat it cost users
NavigationTop bars in some products, left rails in others; icon-only versus icon-and-label; the app switcher living in a different place per productRelearning the interface at every product switch
Filters and layoutFilters in the left panel in some products, that same space taken by navigation in others; overlapping claims on screen real estateNo stable information hierarchy anywhere
Visual styleBackgrounds ran light blue, grey, or white with no logic; cards disagreed on radius, shadow, stroke, and paddingThirteen products that read as thirteen companies
Stakeholders, challenges, and governance
The hard part was never the components. It was the org.

Building YDS was a cultural shift wearing a design project's clothes. Thirteen-plus product leaders each had their own roadmap, so alignment ran on negotiation, workshops, and standing advocacy rather than mandate. Designers and developers were understandably reluctant to give up custom solutions they felt were unique to their product. The audit itself spanned 44 designers and hundreds of screens. And adoption had a real cost: developers refactoring old code sometimes slowed short-term delivery, a trade I had to defend in every quarterly conversation.

Two structures made it stick. Governance: every new design and build passes YDS review, so the system stays current instead of rotting. And a contribution model that balances central ownership with open contribution, so product designers extend the system without breaking it. That pair is also the budgeting story: a dedicated system team is an upfront cost that repays itself in reduced duplication, faster delivery, and the ₹186Cr the outcome section counts.

ChallengeAlignment across productsEach of the 13+ products had its own leaders and roadmaps. One design language required negotiation, workshops, and ongoing advocacy, never mandate.
ChallengeResistance to changeDesigners and developers were reluctant to give up custom solutions they felt were unique to their product's needs.
ChallengeScale of the auditWith 44 designers and hundreds of screens, a comprehensive inconsistency audit was a massive effort in its own right.
ChallengeIntegration with developmentAdopting standardised components meant refactoring old code, which sometimes slowed short-term deliveries, a trade defended in every quarterly conversation.
ChallengeGovernanceKeeping the system updated, and ensuring every new design and build complied with YDS, required strong governance and review processes.
ChallengeThe contribution modelBalancing central ownership with open contribution, letting designers extend the system without breaking its consistency, was an ongoing act.

The answer to all six was a dedicated design system team, argued on six grounds: a single source of truth across every Yubi product, reduced duplication of components and flows, faster delivery through reuse, a unified experience that builds user trust, a bridge team keeping design and engineering speaking one language, and continuous improvement, governance, audits, and documentation that keep the system alive rather than archived.

02 · The strategy · The Invoice
I didn’t ask for a budget. I showed the invoice.
Design systems are business systems. Tokens are just how they’re spelled.

I never pitched a design system as a design initiative. I presented the annual cost of not having one, in currency the CFO reads. That conversation happened once, and Y.Design was funded and built starting the next quarter.

The architecture followed the business case: tokens layered Core to Semantic to Theme, so a component never names a hex. It asks for a role, the role points at a ramp, and the ramp points at one core value. Re-point one ramp and every product re-skins at once, five brands from a single source of truth.

How a token resolves: a core brand value passes through two semantic tiers into a component button, unchanged
How a token resolves: core value to semantic role to component. No component ever names a hex.

And the system is headless. The core carries structure, behaviour, and accessibility with no brand baked in; each brand plugs its own tokens into the same skeleton. That is how one system serves 20+ products across 4 different brands without ever splitting.

20+Products served
4Brands, each its own skin
1Headless system underneath
The architecture · Three levels
Scale the ecosystem, not the fixes.

Solving only at the UI level would not have addressed systemic fragmentation, so the transformation ran on three levels at once. Driving it took cross-functional alignment: with product on outcome metrics like conversion and TAT, with engineering on scalable patterns and reduced rework, with leadership on design reframed as a business driver rather than a support function.

03Feature level
Individual workflows simplified, one decision at a time.
02Product level
Journeys aligned across different use cases, so switching platforms stopped costing users their bearings.
01System level
Consistency, trust signals, and shared patterns: the foundation every product inherits.
The system, in components
One language, from data grid to card.

The architecture lives on in Optimistic Design, my public design system built on the same thinking: 57 production components on three token tiers, from a full data grid with filtering, grouping, pinning, and inline editing, down to one set of card parts recombined per product.

The design system's data grid component: dark theme, density and shape controls, column filters, an attention chip flagging rows that need review, and pagination
Design system card components: a payment card and a balance KPI stat built from the same card parts
The flagship data grid and the card family: every state, theme, and density from the same tokens.
57Production components
3Token tiers, core to theme
688CSS variables, one source
20Type styles, display to code

The library, as it stands: 38 production-ready components in Figma and code, organised in three tiers.

ATOMS · THE V1 EIGHT
ButtonsInputsCheckboxesDropdownsTogglesAlertsModalsTabs
MOLECULES · THE V2 EXPANSION
Navigation barsSide panelsTablesPaginationTooltipsCardsDashboard layoutList viewDetail view
WORKFLOWS · THE V3 STANDARD FLOWS
OnboardingFilters and searchCreation flowsNavigation and hierarchyCards and list viewsCharts and data viz
The initiative · Design led, end to end
A pure design-led innovation, from pitch to metrics.

Nobody commissioned Y.Design. It began as a design initiative and stayed design led the whole way: the pitch, the roadmap, the alignment, the education, the rollout, and the proof.

01Pitch to the managementThe Invoice conversation: fragmentation priced in currency the CFO reads. Funded the next quarter.
02Lay out the roadmapFoundations first, components next, workflows last. V1 to V3 mapped before the first component shipped.
03Align every product counterpartEach product's leads in the loop on what ships, when, and what it replaces, so the system landed with owners, not on them.
04Educate the usersSessions, playbooks, and office hours for the designers and engineers who would live in the system daily.
05Roll out V1, V2, V3V1: foundations, tokens, and 8 basic components. V2: 24 components with layouts, navigation, and tables. V3: 38 production-ready components in Figma and code, with 6 standard flows covering ~80% of product screens across 13+ products.
06Push adoption, create volunteersMigration sprints plus volunteer champions inside every squad, so adoption had advocates where the work happens.
07Measure the metricsAdoption, bugs, GTM speed, and engineering burn, tracked from day one. The numbers on this page are that scoreboard.
03 · The team, and how I ran it
A platform pod at the centre, contributors at the edges.

A dedicated system pod inside the 20+ person design organisation owned the core. Product designers contributed patterns back through a governance process, so the system stayed close to real product needs instead of becoming an ivory tower. Engineering co-owned the tokens.

And because a 20-person team serving 13 products cannot run on manual handoffs, we automated early: Token Studio pipelines, automated component variant generation, and AI-assisted design review. The front-end footprint needed to maintain UI went from 68 engineers to 12.

04 · The rollout
Adoption is the product.
01Price the problemThe Invoice: fragmentation quantified in crores of annual rework, presented as cost, not vision.
02Architect for many brandsToken layers from base to theme, so five brands and thirteen products flex from one source of truth.
03Ship adoption, not a libraryMigration sprints, playbooks, and office hours took adoption from 30% to 85%. A system nobody uses is a cost, not an asset.
04Automate the boringToken pipelines, variant generation, and AI-assisted review, so the platform pod scales without headcount.
V1 · V2 · V3 · The adoption plan
The system grew in staged versions, each one earning the next.
V1Launch · foundations and 8 componentsCore principles first: typography, colour, spacing, grids, and accessibility tokens, plus the 8 basic components every screen needs, buttons, inputs, checkboxes, dropdowns, toggles, alerts, modals, tabs. Adoption stayed deliberately small, new features and minor tasks, but the base layer of consistency and the idea of a shared language were established.
V2Expansion · 24 components and standard layoutsThe molecule level: navigation bars, side panels, tables, pagination, tooltips, cards, and standardized page layouts for dashboard, list, and detail views. Twenty-four components total, broad enough that teams began replacing older UI patterns instead of just decorating new ones.
V3Current · 38 components, 6 flows, 80% of screensStandardised workflows, onboarding, filters and search, creation flows, navigation, cards and lists, charts, mean 6 standard flows now account for roughly 80% of product screens across 13+ products. Thirty-eight production-ready components in Figma and code, extensive documentation, and the design-system website as the single source of truth. Inconsistency down 80%, custom development minimised.
V4Next · the AI layerYDS components become the vocabulary of an AI-driven workflow engine: agent and chat templates, inline summaries and insight panels, dynamic experiences assembled from YDS-defined parts. The vision: from static UI to intelligent, adaptive workflows, still grounded in one system's consistency.
PRODUCTION-READY COMPONENTS, BY VERSION 8 24 38 V1 LAUNCH V2 EXPANSION V3 CURRENT 6 FLOWS · ~80% OF SCREENS
The gap that closed
Same teams. Half the sprints.
Large
8 sprints
4 sprints
Medium
5 sprints
3 sprints
Small
3 sprints
1 sprint
Go-to-market by t-shirt size, in sprints: before Y.Design, after.
Common flows unified and shared64%
Platform UX and UI changed, Yubi 1.0 to 2.0100%

64% of common flows are now unified and shared. Major components like the Table ship as a full plug and play model. And over two years the platform UX and UI changed 100%: the project that took Yubi 1.0 to Yubi 2.0.

05 · Business outcome
The savings compounded, and so did the feeling of one company.
₹186CrOperating costs cut in FY25
₹72CrOperating costs cut in FY24
85%Adoption across 13 products, from 30%
139 to 4UI bugs per quarter
$50.4M $22.2M FY22 FY23 FY24 FY25
Engineering run rate, quarter by quarter: $50.4M leaving FY22 to $22.2M in FY25.

Engineering burn fell from $50.4M in FY22 to $22.2M in FY25, while operating costs fell by ₹72 crore in FY24 and ₹186 crore in FY25. UI bugs per quarter dropped from 139 to 4. Adoption climbed from 30% to 85%. And for the first time, thirteen products felt like they were made by one team.

06 · What I carry forward
Make the cost of bad design visible, and the C-suite starts asking for design.

Y.Design proved that the fastest way to fund design maturity is not evangelism. It is accounting. Price the fragmentation, show the invoice, and the organisation will build the system for you.

Next story
NPS 1.7 to 8.23.