6 million passengers a month. One booking flow built for the wrong person.
IndiGo is India's largest low-cost carrier. At the time of this project, it was running hundreds of daily sectors across a passenger base growing rapidly beyond its original metro core. The product I inherited was not broken in the conventional sense — it worked. It just worked for the wrong user.
The booking flow had been designed for a digital-native frequent flyer. That segment was a minority. The majority — first-time flyers, non-tech users, travellers from tier-2 and tier-3 cities — were failing at the homepage, abandoning inside the Search Results Page, and defaulting to the cheapest fare because nothing in the design communicated why any other option was worth more.
I held sole UX ownership across 10+ customer-facing applications simultaneously — booking flow, holiday marketplace, staff travel portal, loyalty programme, check-in, ancillary products, flight status — with no shared design language, no component library, and no system connecting decisions across any of them.
The brief said "optimise the flow." Research said the flow was built for the wrong person.
The team's hypothesis going in: a general optimisation problem. Reduce friction, tighten the UI, address support volume. The assumption underneath it — the flow works for most users, needs refinement for the rest.
Research dismantled that assumption entirely.
Failure 1 — Homepage widget. Seven special fare categories — Armed Forces, Senior Citizen, Family & Friends, Students, Minor, Doctors & Nurses, LTC — displayed upfront with no progressive disclosure. Non-tech users read them as required fields. Many abandoned before entering a destination. The gate was at the entrance.
Failure 2 — Search Results Page. All flight options open simultaneously. For round trips, both outbound and return legs fully expanded at once. Users entered comparison loops — scrolling, re-evaluating, abandoning. The SRP was the highest drop-off point in the funnel. 62% of drop-offs happened inside this loop.
Failure 3 — Fare cards. Lite, Saver, Super 6E, Flexi — equal visual weight, equal card size, identical CTA. Price-sensitive users defaulted to Lite. Not because Super 6E lacked value — 15kg baggage, meal, seat selection, free date change for ~₹1,000 more than Lite is a strong case. The design made that case invisible.
"The booking flow wasn't confusing. It was designed for the wrong person. And no amount of copy optimisation would fix a structural modelling failure."
Research that changed the brief, not just the design.
I sequenced research to answer the segment question first — before validating any design direction — because a solution built for the wrong user would compound the failure, not fix it.
User interviews & contextual research. Metro and tier-2 travellers, first-time and frequent flyers. Key finding: non-tech users treated the 7 fare categories as required fields, abandoning before entering a destination. This was a structural misread of the UI — not a literacy problem.
Analytics review. Full funnel, fare selection distribution, support query categorisation. The SRP was the highest drop-off point. Super 6E consistently underperformed despite strong value positioning. The data confirmed what interviews were showing: the design was suppressing demand, not reflecting it.
Usability testing — 3 rounds. 8–12 participants per round, mixed digital literacy cohorts. Round 1 confirmed the comparison loop. Round 2 validated the collapse model with non-tech users. Round 3 approved the fare card hierarchy — and caught a near-mistake before it shipped.
Competitive benchmarking. Indian and international airline booking flows. No competitor had solved round-trip decision overload. The collapse model I was designing was a genuine departure from the industry.
"How do we design a booking experience for India's actual air travel demographic — not the digital-native minority who can navigate anything?"
The blind spot — stated honestly. Testing in early rounds was predominantly with digital-native users — easier to recruit, faster to test, cleaner feedback. This created a systematic gap: some flows that validated well internally failed in the field for tier-2 and non-tech users. We caught it mid-project. The cohort should have been stratified by digital literacy from round one — not added as a corrective measure.
Three decisions. One compounding architecture.
Design principle: one decision at a time. Users fail not because they can't decide — but because we ask them to decide too many things simultaneously. Every screen was redesigned to present exactly one decision and remove everything competing with it.
Decision 1 — Homepage: progressive disclosure of special fares
Context: 7 fare categories displayed upfront, no progressive disclosure. Non-tech users treating them as required form fields, abandoning before entering a destination.
Options considered: Keep all 7 visible. Remove special fares entirely and surface in a later step. Collapse to a single 'Special Fares' dropdown, expand only if selected.
Chosen: Progressive disclosure dropdown. Frequent flyers retain one-tap access. Non-tech users stop encountering what reads as a 7-field gate before they've entered a single journey detail. The inline search bar that replaced the card widget became the founding component of the new design system — one UX decision became infrastructure.
Decision 2 — SRP: journey-wise collapse model
Context: All options open simultaneously. 62% of drop-offs inside the comparison loop. SRP was the highest-drop-off point in the entire funnel.
Options considered: Highlight selected row, keep all open. Grey out unselected options. Full collapse — selected flight becomes locked compact card, others disappear, 'Change flight' CTA as escape hatch. Paginate one flight at a time.
Chosen: Full collapse on selection. For round trips: return leg appears only after outbound is locked. After both legs selected, a summary card shows both flights — clearly labelled, priced, no competing options — as the trust moment before payment. Data showed fewer than 8% of users meaningfully compared options after an initial selection. The collapse eliminates the loop for the 92%.
Trade-off: Users who wanted simultaneous comparison lost that ability. The data showed this was the minority whose behaviour was causing the majority to fail. The C-Suite sign-off happened in a single session — I presented the data, the prototype, and the trade-off explicitly. Approved on my recommendation alone.
Decision 3 — Fare cards: value hierarchy
Context: Lite, Saver, Super 6E, Flexi — undifferentiated list, equal weight, identical CTA. Price-sensitive users defaulted to Lite. Super 6E value was real and invisible simultaneously.
Options considered: Add descriptive copy to each card. Colour coding to differentiate tiers. Featured card treatment — visual prominence, full perk breakdown, primary CTA, 'Best value' badge. Default-select Super 6E and let users downgrade.
Chosen: Featured card hierarchy. Value visible before price. Option D — default-select — was tested in Round 3 and pulled before build. Users who noticed the pre-selection felt manipulated. Trust dropped measurably. The featured card without a default produced a comparable selection rate with none of the trust cost.
Three rounds. One near-mistake. A lot of watching data refresh.
Round 1 — Lo-fi, frequent flyers. Collapse model validated for speed. Comparison loop behaviour confirmed in the control condition. Blind spot identified: non-tech users were not yet in the cohort.
Round 2 — Mid-fi, corrected cohort. Non-tech and tier-2 users added. Confusion reduction validated. The round-trip summary card — entirely absent in the old flow — was cited as the "first moment of confidence" in the booking journey. Round-trip model validated end-to-end.
Round 3 — Hi-fi, mixed cohort. Super 6E selection rate measurably up with featured treatment. Default-selection version tested alongside — trust drop observed immediately. Pulled before build. Final prototype approved for engineering handoff.
What nearly shipped and was caught. A version with Super 6E pre-selected. The selection data looked strong in isolation. In the room, the first thing participants said when they noticed the default was "why was this already selected?" Trust dropped. Featured treatment without a default produced comparable selection with no trust cost. Pulled. No debate.
6× by day four. The data locked and it stayed there.
The SRP collapse model and fare card hierarchy went live the same day. By midnight, Super 6E selection had doubled — 2× the baseline. I stayed with the analytics team for three consecutive days watching engagement data refresh in real time. The team called it at 2× on day one. I wanted to see where it locked before declaring anything.
By day four, it locked at 6×.
The compounding architecture. The 6× result was not produced by either decision alone. The SRP collapse retained users who would have abandoned in the comparison loop. The fare card hierarchy redirected those retained users toward Super 6E once they reached fare selection. Neither screen alone produces 6×. The architecture of the two together did.
Secondary impact. The design system became the shared language across all 10 applications — reducing design-to-dev friction on every subsequent product decision at IndiGo. Research findings on tier-2 user failure changed how the product team recruited test participants in all subsequent projects: from convenience sampling to cohort-stratified recruitment. The SRP collapse model set the precedent for how IndiGo approached all major interaction changes: prototype-first, data-supported, single accountable decision-maker.
What I'd do differently. Honest, not safe.
Stratify the research cohort from round one. I over-indexed on digital-native users in early testing — easier to recruit, faster sessions, cleaner feedback. The tier-2 and non-tech users who needed the most from this redesign were the last to be tested. We caught it. It should have been designed in from the start.
Instrument before touching a single screen. The analytics review gave us funnel drop-off magnitude — but not segment-level breakdown, not time-on-task, not session replay by city tier. When the 6× result came in, I could show the after. I could not show the before in the same dimension. I now treat instrumentation as a design deliverable, not an engineering afterthought.
The design system cost was underestimated. Building it in parallel with live product work — under timeline pressure — meant some early components had to be retrofitted. I underestimated that cost and how much faster everything moved in the 18 months after the system stabilised. The system should have been the first sprint, not a concurrent one.
What I carried forward. After this project, I never ship without instrumentation in place first. The analytics setup, event taxonomy, and cohort segmentation plan are part of the design work. Sole accountability at scale means the data is either yours to own or yours to regret not having.
