One platform. Five engineering teams. No shared design language.
Quikr was India's largest classifieds platform — 1,000 cities, 13 categories, $350 million raised. Between 2015 and 2017, an aggressive acquisition strategy produced five distinct product verticals: QuikrCars, QuikrHomes, QuikrJobs, QuikrServices, and the core marketplace. Each ran on its own codebase, with its own engineering team and its own visual language. The platform looked like five different companies sharing a logo.
I joined as a Visual Designer, progressed to Sr. Visual Designer, and was moved into the core team by the VP as a UI Designer after the classified homepage redesign demonstrated I was operating at a different level. From there I took end-to-end ownership of the design system initiative — the first at Quikr — as sole design lead.
The brief was "make it consistent." The real question was how to build one design language that feels native to each vertical, reduces the cost of building all of them, and gets adopted by engineers who have no structural reason to use it.
16 acquisitions. Five codebases. Zero shared foundation.
CEO Pranay Chulet's acquisition strategy was logical from a market coverage standpoint. Between 2015 and 2017, Quikr acquired 16 companies — CommonFloor in real estate, Babajob in blue-collar jobs, and a string of category specialists. Each brought vertical depth, established user bases, and proprietary data. Each also brought its own product, its own engineering culture, and its own interface language.
The competitive pressure was real. Vertical specialists owned their categories with depth: Naukri and Shine in jobs, 99acres and MagicBricks in real estate, CarDekho and CarTrade in automobiles, OLX in general classifieds. The only durable answer was to ship faster and more coherently than those specialists. That required a shared design foundation. There wasn't one.
What fragmentation actually cost. Every new feature required five parallel design and build cycles with no shared components. A button style decision made in QuikrJobs had no relationship to the equivalent decision in QuikrHomes. Brand inconsistency was visible to users crossing verticals. Engineering teams were solving the same interface problems independently, repeatedly. Design-to-dev handoff was slow because there was no shared vocabulary — every spec had to be built from scratch.
"The platform looked like five different companies sharing a logo. That's not a brand problem — it's a product infrastructure problem."
You can't design what you haven't inventoried.
The audit advantage. Having joined as a Visual Designer responsible for iconography, marketing materials, and brand collaterals, I had something most design system leads don't have at the start: I understood what the brand was actually made of. Where inconsistencies lived. Which were legacy drift versus legitimate vertical-specific decisions. That knowledge made the audit phase faster and the token decisions more honest.
What the audit found. Across five verticals: 14 distinct button styles with no shared logic. Six different typographic scales with conflicting base sizes. Colour values defined by hex code in each codebase — no named tokens, no relationship between values. Spacing defined inline on a per-component basis. No shared iconography. No governance model for any of it. The inconsistency wasn't the result of bad decisions — it was the result of five teams making good decisions in isolation.
The classified homepage redesign — the project that changed my mandate. What was framed as a visual execution task, I treated as a problem-solving exercise: connecting visual hierarchy decisions to user scanning behaviour and category orientation. The VP recognised it, corrected my title to UI Designer, and moved me into the core team. The design system mandate followed directly. That ground-level work wasn't a detour — it was the foundation that made everything else possible.
Engineering interviews. Before designing a single component, I spent two weeks talking to engineering leads across all five verticals. The recurring theme: inconsistency wasn't their biggest frustration. Re-solving the same problems was. Every vertical had independently built form validation, card layouts, and navigation patterns. The appetite for a shared system was there — the ask was that it had to be practical within their existing stacks, not a theoretical ideal that required a full rewrite to adopt.
Three decisions that shaped how the system was built — and whether it would last.
Decision 1 — Three-layer architecture, not a flat style guide
Context: The obvious output was a visual style guide — PDF, colour swatches, type specimens. Fast to produce. Easy to share. Easy to ignore. A style guide documents decisions; it doesn't enforce them. With five engineering teams and no shared tooling, a document wouldn't fix a structural problem.
Options considered: Visual style guide — fast to produce, compliance without consistency, no propagation mechanism. Token-based system — named variables as source of truth, components inherit from them, changes propagate automatically.
Chosen: Token-first. Three layers: an immutable core of design tokens and typography, a shared component library governed by a two-vertical rule (a component only enters the shared library if it's needed by at least two verticals — preventing premature abstraction), and a vertical extension layer built on the same token set. Every colour, spacing value, and type scale defined as a named variable. Every component references tokens, not hard-coded values. Changing a token changes every component that uses it — across all five verticals simultaneously. Consistency becomes the path of least resistance, not a compliance ask.
Trade-off accepted: Implementing the token layer required individual buy-in from each vertical's engineering lead — harder than handing over a PDF. I worked with each tech lead to make the implementation practical within their existing stack. This was relationship work as much as design work. It took time a style guide would not have required. It also produced adoption a style guide never would have.
Decision 2 — The two-vertical rule for shared components
Context: Every design system faces the same failure mode: premature abstraction. Components added to the shared library before they're genuinely needed by multiple contexts become constraints that slow down the verticals they were supposed to serve. The system becomes something to work around, not with.
Options considered: Add everything that could theoretically be shared — maximum breadth, maximum drift risk. Add only what was actively duplicated — slower initial build, higher adoption confidence.
Chosen: A component enters the shared library only when at least two verticals need it independently. Until then, it lives in the vertical's own layer. This kept the shared library lean, intentional, and trusted. Engineering teams knew that if a component was in the shared library, it had been validated across real contexts — not designed speculatively.
Decision 3 — QuikrJobs first, fully complete
Context: Stakeholder pressure was to roll out across all five verticals simultaneously — show breadth, show momentum. Five 40%-complete implementations with no clean reference would have produced the same fragmentation the system was designed to solve. Adoption without a working proof point is change management without evidence.
Options considered: Simultaneous rollout — visible momentum, shallow adoption, no clean reference. Sequential rollout — one complete reference implementation that vertical leads could see, touch, and evaluate before committing their own teams.
Chosen: QuikrJobs as the first complete implementation. Highest listing volume, clearest user flows, and an engineering lead willing to partner on the build. Once Jobs ran cleanly on the system, it became the proof of concept that made every subsequent vertical conversation easier. The question shifted from "why should we adopt this?" to "when can we get this?"
You can't user-test a token. Validation had to happen in production.
A design system's quality isn't visible in a Figma file — it's visible when real engineers build against real specs and real users encounter real interfaces. The QuikrJobs rollout was staged deliberately: each stage gated on the previous one clearing before the next began.
Stage 1 — Spec review with engineering lead. Annotated component specs reviewed before any build began. The Jobs engineering team identified 3 spacing conflicts with their existing grid. Fixed before build. This stage alone justified the sequential approach — those conflicts would have shipped silently in a simultaneous rollout.
Stage 2 — Full prototype review. Complete Jobs listing flow built on new components. Stakeholder review across product, design, and engineering. Card hierarchy approved. Navigation transition required one revision. Signed off for build.
Stage 3 — Search and browse live. No regressions. Component behaviour matched intent. System cleared for the listing creation flow.
Stage 4 — Listing creation and account flows live. Two edge cases in form validation surfaced in production. Fixed in the shared component layer — and propagated automatically to all subsequent verticals before they'd even built those flows. This is what a token system produces: fixes that compound forward.
"A design system that's been tested only by the person who built it hasn't been tested. The QuikrJobs rollout surfaced problems I hadn't anticipated — and fixed them before they became systemic across four more verticals."
What nearly shipped — and was caught. An early version of the listing card used a single unified template across all five verticals — same hierarchy, same information density, same visual weight for every data point. Jobs and Services accepted it. Homes and Cars pushed back in review, correctly: a property listing card and a vehicle listing card require fundamentally different scan patterns. Price prominence, image hierarchy, and the role of technical specifications differ significantly between a ₹40 lakh flat and a ₹2 lakh car.
The fix was a shared structural foundation — card container, spacing, border treatment, responsive behaviour — with vertical-specific information hierarchies built on top. The base was identical across all five verticals. The expression adapted to category context. It was a harder build. It was the right solution. And because the fix was made in the shared component layer, subsequent verticals got it right without re-discovering the problem.
All five verticals. One foundation. A collateral standard that outlasted my tenure.
All five verticals — QuikrJobs, QuikrServices, QuikrCars, QuikrHomes, and the core marketplace — were running on the shared token and component system within 18 months of the initiative starting. The adoption sequence followed the QuikrJobs reference exactly: each vertical's engineering lead had seen the Jobs implementation before committing, which compressed their adoption timelines significantly.
The collateral standard. In parallel with the product design system, I established a new collateral design standard — a direct challenge to the Marketing Head's existing approach, which produced inconsistent brand output across verticals. The new standard was adopted institutionally. It is still being followed at Quikr. That's the metric that matters most for that chapter: not what I produced, but what the organisation continued to produce without me in the room.
The VP recognition and title correction. The classified homepage redesign — the project that preceded the design system mandate — resulted in the VP correcting my title from Visual Designer to UI Designer and moving me into the core team. That's the signal that what I was doing had been recognised as operating at a different level, not just executing more competently at the same one.
The organisational shift that mattered most. Product and engineering teams started opening the design system before scoping new features. Not because they were told to — because it was faster. The shared vocabulary moved from a design artefact into the daily language of product and engineering decision-making. That shift — from compliance to utility — is what separates a design system that lasts from one that gets abandoned the moment the person who built it moves on.
What I'd do differently. And what I'd do exactly the same.
Instrument adoption from the start. I knew the system was being used. I could not show designer productivity rate before and after, component drift rate over time, or user-facing metric improvement attributed specifically to UI consistency. The business case for a design system is easier to make — and easier to defend — with user data alongside engineering data. That instrumentation should have been part of the system specification, not an afterthought.
The two-vertical rule was right — and I'd enforce it earlier. The listing card near-miss happened because I tried to abstract a component before it had been validated in two real contexts. The rule existed; I bent it once under deadline pressure. It cost a revision cycle. The rule exists for exactly that reason.
The relationship work was the real work. The technical design of the system — tokens, components, documentation — was the visible part. The invisible part was convincing five engineering leads, one at a time, that adopting the system would make their lives easier rather than constrain them. That required understanding their stacks, their pressures, and their objections before presenting any solution. No amount of good system design survives a team that hasn't bought in. The real work is building enough trust with engineering teams that they see the system as a tool that serves them, not a constraint imposed on them.
What I carried into every subsequent project. At IndiGo, the design system wasn't a deliverable at the end — it was the first decision. That sequencing came directly from Quikr: I knew from experience what it costs to build the system after the product, and I refused to repeat it. The authority to change a system comes from having lived inside it first.
