Every project started from scratch. Every designer had their own button, their own input, their own colour. I built the single source of truth that ended all of that — 6 foundations, 11 components, and developer-ready tokens across IndiGo web and app.
RoleLead DesignerSole owner of system architecture
IndiGo had multiple designers working across web and mobile — each doing good work in isolation. But without a shared system, every new project meant rebuilding the same button, redefining the same colour, recreating the same input field. The inconsistency was invisible to any one designer, but obvious to any user moving across platforms.
No one had stepped back to build the infrastructure. I took ownership of building it from the ground up — designing the architecture, building every foundation and component, and writing the documentation.
Button, Input, Navbar, Avatar, Accordion, Breadcrumbs, and more
</>
Dev token export
Every component published with code-ready design tokens for developers
02 · Discovery
Auditing the inconsistency
Before designing anything, I audited existing UI across IndiGo web and mobile. I catalogued every button, input, card, and navigation pattern across all active surfaces. The audit revealed significant variation — the same component sometimes appeared in 4 or 5 different visual treatments across different parts of the product.
I also interviewed designers on the team to understand how they currently worked. The answer was consistent: everyone started from scratch on every project because there was no trustworthy shared source.
“
I just copy from the last project and change things. There is no official version of anything.
IndiGo designer · Discovery interview
Component inconsistency audit · Same component, multiple conflicting versions found across surfaces
Audit methodology applied to every component across web and mobile — inconsistencies catalogued before any design work began
03 · Problem definition
Naming the real cost
The problem wasn't just visual inconsistency — it was the invisible tax on every designer's time. Every project started from zero. Every handoff to developers meant explaining the same decisions again. There was no shared vocabulary, no shared truth.
How might we
How might we create a single source of truth for IndiGo's UI — so designers stop rebuilding what already exists, developers ship faster from tokens, and users experience one coherent product across every surface?
04 · What was built
The full system
I structured the system in two layers — Foundations first, then Components built on top of them. Every component was built with variants, states, and design tokens so developers could consume it directly without re-interpretation.
Foundations
T
Typography
Type scale · weights · line-height
■
Colors
Brand · semantic · neutral tokens
◆
Icons
Icon library · usage guidelines
□
Layout
Grid · spacing · breakpoints
▪
Object Styles
Elevation · radius · borders
✎
Utilities
Spacing helpers · display · overflow
Components
❏
Accordion
Expand · collapse
▶
Button
Primary · secondary · ghost
❯
Breadcrumbs
Navigation trail
☑
Selection
Radio · checkbox
●
Avatar
Image · initials · sizes
▫
Inputs
Text · search · states
☰
Navbar
Web · mobile navigation
◆
Chip + Badge + Tag
Labels · status indicators
○
Carousel Indicator
Dots · progress
▮
Progress bars
Linear · step · loading
▲
Tooltip
Hover · contextual info
Token architecture · How design decisions flow from token to screen
Token architecture ensures a single colour change propagates instantly to every component — no hunting, no manual updates
05 · Build process
How the system was built
01
Audit first — no assumptions
I catalogued every existing UI component across IndiGo web and app before designing anything. This gave me a complete picture of what existed, what was duplicated, and what was missing entirely. The audit became the brief.
UI auditComponent inventoryGap analysis
02
Foundations before components — building the base layer
I built the 6 foundation pages first — Typography, Colors, Icons, Layout, Object Styles, and Utilities. Components can't be consistent if their raw materials aren't. Every colour was tokenised with both a raw value and a semantic alias so the system could be themed or updated without touching component files.
Token architectureSemantic naming6 foundations
03
Components with variants and states — no guessing in handoff
Each of the 11 components was built with all variants (primary, secondary, ghost, disabled) and all interactive states (default, hover, focus, error, loading). Developers got a complete spec — no interpretation needed, no back-and-forth about what the disabled state should look like.
11 componentsAll statesDev-ready tokens
04
Documentation — the system only works if people use it
A design system without documentation is just a Figma file. I wrote usage guidelines for every component — when to use it, when not to, which variant for which context, and accessibility considerations. The goal was to make the right choice the obvious choice.
The hardest part wasn't building the system — it was changing habits. I ran a workshop with the design team walking through the system, showed how it reduced rework on a real project, and made the Figma library the default starting point for all new work. Adoption happened gradually but consistently.
Team workshopFigma libraryChange management
06 · Results
What changed
Adoption was gradual but the impact was clear. Designers stopped rebuilding. Developers had a token reference. And for the first time, IndiGo's web and app felt like they came from the same product family.
17
Pages delivered — 6 foundations and 11 components fully documented
1
Source of truth — first time IndiGo had a unified UI reference
✓
Consistent UI achieved across IndiGo web and mobile app
“
We finally have one place to look. I don't have to ask what the right button is anymore.
IndiGo designer · Post-adoption feedback
07 · Reflection
What I would do differently
Building a design system taught me that the technical work is only half the job. The harder half is governance — making sure the system stays alive, gets updated, and doesn't drift back into inconsistency over time.
👥
Build adoption into the plan from day one
I built the system first and then thought about adoption. Next time I'd involve the team earlier — getting buy-in during the build makes adoption far smoother than trying to retrofit it.
📄
Create a contribution process
I was the only person who could add to the system. That created a bottleneck. A clear contribution process would let other designers propose additions without everything going through one person.
⏰
Version control and changelogs
When components were updated, people using older versions weren't notified. A versioning system and changelog would have prevented silent inconsistencies from creeping back in.
📈
Measure system health metrics
I had no way to track adoption rate or component usage. Measuring how often designers actually pulled from the library would have shown what was working and what needed better documentation.