Ten products. Zero shared language.
By 2021, IndiGo's digital product portfolio had grown to 10+ products — booking flow, check-in, CrewPal, Staff Travel, IndiGo Holidays, loyalty, corporate portal, cargo, airport kiosks, and internal operations tools. Each had been built by different teams, at different times, with different design decisions. The result was a portfolio that shared a logo but not much else.
Buttons had 6 different visual treatments across products. Typography scaled inconsistently between mobile and web. A designer moving from the booking team to the CrewPal team had to relearn every pattern. Engineering spent 20% of sprint capacity recreating UI components that already existed somewhere else in the codebase.
I proposed, resourced, and led the build of IndiGo's first enterprise design system — a shared Figma library, token architecture, component documentation, and handoff protocol used across all 10 products and a 15-person design team.
The hidden cost of inconsistency
The problem with design inconsistency is that it's invisible until you measure it. No one flags "we have 6 button styles" as a business risk. It surfaces slowly — in slower sprints, in engineering rework, in user confusion when moving between IndiGo products, in onboarding time for new designers.
I made it visible by quantifying it. Before proposing the system, I spent 3 weeks auditing the portfolio and building a business case:
Component duplication across codebases
The same button component existed in 8 different forms across product codebases. Engineering estimated 340 hours per quarter spent recreating UI components that already existed elsewhere. That's 9 weeks of one engineer's time — every quarter — spent on zero-value work.
Designer onboarding took 3–4 weeks
A new designer joining any IndiGo product team had to reverse-engineer the visual language from existing screens. There was no documentation, no component library, no design principles. Every designer rebuilt context from scratch. Average time to first independent contribution: 3.5 weeks.
Design reviews consumed by inconsistency debates
In cross-team design reviews, 40% of feedback was about visual inconsistency — wrong button radius, different spacing from the adjacent product, mismatched type scale. None of this was about product thinking or user experience. It was quality noise that could have been eliminated by a shared standard.
Users noticed — and lost trust
In usability sessions, participants frequently commented on visual inconsistencies when moving between IndiGo products. "This looks like a different app" was a direct quote from 7 separate sessions. Inconsistency signals low quality — and low quality erodes trust, even when the underlying product works.
Auditing 10 products before writing a single component
Design system work is infrastructure work — and infrastructure decisions made without a thorough audit create new problems while solving old ones. I spent 6 weeks in research and audit before proposing a single token or building a single component.
Visual audit: Screenshot-catalogued every UI component across all 10 products. 2,400 screens captured and tagged by component type. Found: 6 button variants, 11 card styles, 4 navigation patterns, 9 form field treatments, and 14 different uses of the IndiGo blue across the portfolio.
Designer interviews: 1:1s with all 15 designers across product teams. Core finding: every designer was maintaining their own personal Figma library of IndiGo components because no official one existed. 15 shadow libraries, each slightly different, each drifting further from the others over time.
Engineering interviews: 8 engineers across 4 teams. Core finding: the front-end teams had started building their own informal component libraries in code — 3 separate React component libraries existed across the codebase, none of them shared, all of them partially inconsistent with each other.
Competitive benchmark: Audited the design systems of Airbnb (Lunar), Atlassian (Atlaskit), IBM (Carbon), and Shopify (Polaris) — specifically their token architecture, documentation standards, and governance models. Carbon's token hierarchy and Polaris's usage documentation became the primary references.
"I've built my own Figma library over 2 years. It has everything I need. But it only works for me — and when I leave, it leaves with me."
— Senior designer, booking team
This quote defined the risk I was solving: IndiGo's design knowledge was locked in individuals, not institutionalised. The system needed to outlast any single designer — including me.
The human side of systems adoption
Design systems fail more often from adoption problems than from technical ones. A technically perfect system that designers don't use is worthless. Understanding the psychological barriers to adoption shaped every decision about how the system was built and rolled out.
IKEA effect — involve people in building it
People value things they've helped create more than things handed to them. I involved designers from all 4 product teams in the component definition phase — running working sessions where teams nominated the patterns they wanted standardised first. This created co-ownership rather than compliance.
Loss aversion — frame it as gain, not replacement
Designers were attached to their personal libraries. "We're replacing your library with ours" would have created resistance. The framing was "we're building a foundation that makes your library better" — the system was positioned as amplifying individual work, not overriding it.
Social proof — early adopters as advocates
I identified 3 influential senior designers and onboarded them to the system first — before any wider rollout. Their public use of the system in design reviews created social proof. When the booking team's lead designer was using it and crediting it publicly, adoption accelerated faster than any mandate would have.
Three years. Four phases. One living system.
A design system is never finished — it's a product with its own roadmap. The build was structured in four phases, each with a defined scope and measurable adoption milestone before moving to the next.
Phase 1 — Foundation (6 months, 2021)
Token architecture: colour, typography, spacing, elevation, border radius. A single source of truth for every visual decision. All tokens defined in Figma variables and mirrored to CSS custom properties for engineering. 4 cross-team working sessions to ratify tokens before they were locked. Output: 80 design tokens, zero ambiguity about the core visual language.
Phase 2 — Core Components (8 months, 2022)
Built the 40 highest-frequency components nominated by product teams in the audit — buttons, form fields, navigation, cards, modals, alerts, badges, and tables. Each component: Figma variants for all states (default/hover/active/disabled/error), usage documentation, do/don't examples, and accessibility specification. Engineering received component specs in a format they could build directly from.
Phase 3 — Patterns & Templates (10 months, 2022–2023)
Moved from atoms to molecules and organisms. Built 12 page templates (listing, detail, checkout, confirmation, empty state, error, onboarding, dashboard) and 28 interaction patterns (search, filter, sort, pagination, infinite scroll, form validation). Templates reduced new feature design time from days to hours for common layouts.
Phase 4 — Governance & Contribution (Ongoing, 2023–2024)
A system no one can contribute to dies. Established a contribution protocol — any designer can propose a new component via a standardised brief, reviewed by a 3-person system team in a fortnightly session. Accepted components are built, documented, and released in a monthly system update. By 2024, 30% of new components were contributed by product teams, not the system team.
What the system is made of
Token architecture — the foundation everything else inherits from. Three token tiers: primitive tokens (raw values — `blue-600: #1a46c9`), semantic tokens (intent-based — `color-action-primary: blue-600`), and component tokens (component-specific — `button-background-primary: color-action-primary`). This hierarchy means a brand colour change cascades through the entire system by updating one primitive token — not 200 components.
200+ Figma components with full variant coverage. Every component built with Figma's variant system — all states, all sizes, all themes (light/dark, though dark was IndiGo internal tools only). Auto-layout used throughout for components that needed to scale with content. Every component detached from its origin file — teams could use them without being blocked by library permission issues.
Documentation built into the components. Each Figma component has an annotation layer (hidden by default, visible for developers) with spacing specs, colour tokens, and accessibility notes embedded directly. No separate spec document to keep in sync. The component is the spec.
Handoff protocol — eliminating the design-engineering gap. A standardised Figma frame structure for every feature delivery: component inventory, spacing annotations, state map, edge cases, and mobile breakpoints — all in one deliverable. Engineering reported 40% reduction in back-and-forth clarification requests after the protocol was adopted.
The token architecture change — moving from hardcoded hex values to semantic token references — meant when IndiGo updated their brand blue in late 2023, the change propagated across all 10 products and 200 components in 4 hours, not 4 weeks.
Infrastructure that compounded over time
Design system ROI is hard to measure in a single quarter. The value compounds — every component built is a component never rebuilt, every pattern documented is a pattern never debated again. Measured at the 18-month mark after core components launched:
The brand colour update in late 2023 was the system's most visible proof point. A change that would previously have required a designer on each of 10 product teams to manually update hundreds of screens was completed in 4 hours by updating a single primitive token. That moment converted the final sceptics in engineering leadership.
The system also changed how IndiGo hired designers. Job descriptions for product designer roles now listed "experience with design systems" as a requirement — a direct response to how central the system had become to day-to-day work.
What three years of systems work teaches you
A design system is a product, not a project. The most common failure mode is treating system work as a one-time deliverable — build it, ship it, done. It's not done. It needs a roadmap, a release cadence, a contribution model, and a team who owns it long-term. The governance structure I put in place in Phase 4 was more important than any component built in Phase 2.
Adoption is a design problem. The system's technical quality mattered less than whether people used it. I spent more time on onboarding, documentation clarity, and the contribution protocol than on the components themselves. The best design system in the world is worthless if teams build around it. Make adoption the easiest path.
Start with tokens, not components. Every design system I've seen that started with components eventually had to go back and retrofit a token layer — which breaks everything. Tokens first means every subsequent component decision is coherent. It's slower to start, but it's the only architecture that scales.
Involve engineering from day one, not handoff. The three separate React component libraries that existed before this system were built because engineering didn't trust that design would give them something they could actually use. Involving engineers in component definition — specifically in deciding what states and variants to include — meant the Figma components mapped to code components almost one-to-one. Handoff went from painful to near-automatic.
Document the decisions, not just the outcomes. Future designers and engineers don't need to know what the button radius is — they can see it. They need to know why it's 6px and not 4px or 8px. Every significant system decision was documented with the reasoning — the constraints, the alternatives considered, and why this choice was made. That context is what prevents the system from being second-guessed every 6 months.
