Vistara, rebooked

Overview

One trip, three screen sizes

At TCS we worked on the revamped ticket-booking screens for Vistara, an Indian full-service airline. This case study covers that work and the interactive prototypes I built from it: a desktop website, an iPhone app and an Apple Watch companion. All three follow the same itinerary, Bengaluru to Dubai on UK 563, so a reviewer can trace one booking from the search box to the boarding gate.

Same trip, same palette, and a different answer to "what matters right now?" on each device.

Starting point

Static comps for one screen size

The first phase of the project produced notebook sketches, a site map and high-fidelity desktop comps: the home page in two colour themes, and a flight-selection page with a date picker and a modify-search panel.

First phase Flight selection comp

First phase Modify search panel

The placeholder text shows these comps were layout studies, so I treated them as a starting layout and not as a record of how the live site behaved.

Users and journey

Who the screens are for

Three working personas shaped the flow and the scenario data. They are built from the Club Vistara tiers, the cast of the prototypes and the routes in the flow. Each frustration is tied to something the screens do about it, so it can be tested.

The journey, by stage

User interviews

The interviews were planned to test the personas and the journey above. This is the guide they follow, and the way each question maps to a part of the design.

Empathy maps

One map for each of the two main personas. They are working hypotheses, written to be confirmed or corrected in the interviews.

Surfacing the core pain points

Putting the journey, the personas and the empathy maps side by side, six pain points kept coming back. Each is a hypothesis and each has a place in the prototypes where it is answered.

Features that eliminate the pain

The shape of data

What the screens have to show, and in what form

A booking journey handles a small set of facts about a trip and a few numbers that change as you choose. Knowing which is which decided what got a large numeral, what got a colour and what stayed quiet.

Goals

Five goals, and how each is checked

Each goal comes from a need in the personas above. I kept the last column honest about which ones have been checked at all.

Process

How the work was sequenced

1. Sketch

   Notebook wireframes of the home page and the flight-selection page, with numbered regions so I could argue about order before drawing anything.

2. Map

   A site map of the whole airline site: header, navigation, home, book, manage, loyalty, offers, login and footer.

3. Compare

   Two colour directions for the home page, one aubergine and gold, one navy and amber.

4. Build the web prototype

   An interactive prototype with 36 screens in five groups, built first because it became the reference for brand colour, flight content and interaction patterns.

5. Bring the iPhone app to parity

   A gap scan against the web screen list found eight missing screens, which brought the total to 31.

6. Scope and build the Watch

   Six screens from a reference layout, turned into an interactive prototype and then fitted to two case sizes.

7. Audit, then verify the audit

   A contrast calculation, a heuristic review of the web flow, an Apple HIG audit of the iPhone and Watch prototypes, fixes with backups, then re-checks by three independent methods.

Design thinking process

The work followed the five stages of design thinking. Each stage has something concrete behind it, and one of them, testing with users, is still ahead.

The Double Diamond

The same work seen as a Double Diamond: two rounds of opening up and narrowing down, first on the problem and then on the solution.

Structure

From a notebook to a site map

The sketches fixed the order of things on the page. The site map decided what each platform would carry and what it would drop.

Sketches

The final web home keeps the sketch's order: notice bar, navigation, a hero with a four-tab search panel, a row of shortcuts, then a grid of featured fares with Dubai as the large tile. The sketch's "MORE" button became the results list itself, and the idea of a Modify control became the Edit search button in the route strip.

Site map

I drew the whole airline site as one tree before deciding anything about screens. It has nine branches, and the Manage branch alone holds three parents and thirteen children. Scroll sideways to read it, or open it full size.

Process flow

One booking from search to travel day, seen as a sequence of what the traveller does and what the screen answers.

User flows

Book

1. Home
2. Search
3. Results
4. Fare
5. Passengers
6. Seats
7. Add-ons
8. Payment
9. Payment fails?
10. Confirmation

When payment fails, the seat is held for 14 minutes and the traveller picks Try again or Use another method, then rejoins at Payment.

Manage

1. Trips
2. Trip detail
3. Change, cancel, add bags or check in
4. Fare difference or refund maths
5. Confirm

Travel day

1. Watch face
2. Next flight
3. Status
4. Boarding pass
5. Gate alert, View pass

Visual direction

Two colour directions, one kept

Both themes use the same layout. They differ in what the brand colour does, and that difference decided it.

Theme 1 Aubergine and gold

Theme 2 Navy and amber

Why Theme 1 won

• Aubergine with matte gold is the thing a traveller would recognise. Navy with amber looks like many travel brands.
• The purple system came with a rule for gold, described in the next section, which gave the interface a clear order of emphasis.
• I did not test the two themes with anyone. This was a design judgement.

Design system

A palette with a rule about where gold goes

The web prototype's colours are the reference for the other two platforms. Every contrast figure below is calculated from the hex values, not judged by eye.

Across the three platforms

Web prototype

The web booking flow, screen by screen

The web prototype has 36 screens in five groups: booking flow (8), manage booking (10), discover (4), Club Vistara (5), and states plus account screens (9). Screenshots below are taken from the running prototype. Select any image to enlarge it.

Then First-phase comp

Now Web results screen

Web: flight results

What to notice

• A flexible-dates link sits above the strip and says how much it could save, up to INR 4,238 here.
• A banner offers to hold today's fare for 72 hours for INR 499, placed where hesitation is highest: after the price, before the commitment.
• Each card carries a CO₂ figure compared with the route average, and a "What's included in this fare?" disclosure.
• A sticky bar keeps the round trip, the lowest fare for it, INR 28,174, and the 8,500 miles it earns in view.

What to notice

• Four fares: Lite at INR 14,087, Saver at 17,250 (marked most popular), Flex at 24,500 and Business at 35,911.
• Rows line up across columns, so you compare by reading across: cabin bags of 7, 7, 10 and 14 kg, checked bags of 15, 25, 30 and 40 kg.
• Each fare shows its difference from the one before, such as +3,163 for Saver, so the price of an upgrade is never a mental sum.

Web: fare comparison

Web: passengers

Web: add-ons

Web: seat selection

What to notice

• Cabins are labelled with their row ranges, so you always know where you are on the aircraft.
• The legend carries the prices: preferred INR 600, extra legroom 1,200, exit row 1,200, window 400.
• A selected seat can be tapped again to release it, and the screen says so.

Web: payment

Web: confirmation

Web: my bookings

Web: flight status

Web: Club Vistara

Web: payment failed

Empty results

• A search with no flights suggests nearby dates that do have seats, with their fares, instead of ending on an apology.
• The iPhone version is plainer: Clear filters and Change dates.

Web: no results

Heuristic evaluation

A heuristic review of the web flow, and four fixes

I reviewed the web prototype against Nielsen's ten usability heuristics and fixed what the review turned up in the latest version. Four findings were fixed in the latest version: three completely and one in part, which the accessibility pass that followed closed. I tried each by hand against the previous version, and re-ran the accessibility scan afterwards.

Web: Edit Search, open in place

What to notice

• The route strip stays put, so you can see what you are changing.
• The four fields, depart, return, class and passengers, are the same ones as the home-page search.
• Cancel sits beside Apply changes, so a wrong turn costs one click.

Before Fares named by cabin

After Fares named as on the next screen

iPhone prototype

The iPhone app: same journey, native habits

The app has 31 screens and three bottom sheets, drawn at 390 by 844 points. It keeps the web's order of steps and swaps the web's patterns for the ones iPhone users already know.

The booking flow

At the largest text size

The Text size setting lives in Settings, and a shortcut on the stage cycles through it. Below are four screens at Larger, which scales text by 30%. Long titles shorten with an ellipsis, as they do on a real iPhone, and prices, buttons and lists reflow instead of clipping.

After you book

Around the journey

Apple Watch prototype

Six screens, and a deliberate "no"

The Watch carries only the day of travel. Search, seat choice and payment were left out on purpose, because each needs typing or side-by-side comparison.

Decisions worth knowing

• Only the next-flight chain, Next flight, Status, Boarding pass, responds to swiping. Face, the gate alert and Club Vistara open by tap. That keeps custom swipes out of the way of watchOS's own back gesture at the screen edge.
• A text-size control offers three scales, 1, 1.15 and 1.3. A later check at the larger sizes found text clipping on two screens, and I fixed both.
• Back controls carry spoken labels, and animation is reduced for people who ask for it.
• The case toggles between 45mm and 49mm Ultra. The first version matched only the 45mm; I noticed because the Ultra's screen is larger.

The Apple HIG reference I used for the Watch audit has no watchOS-specific guidance, and I said so in the audit. The swipe rule above is my judgement from its general advice on gestures near system edges, not a documented watchOS requirement.

Artificial intelligence

Where intelligence helps, and where it should ask first

The prototypes do not include a conversational assistant. They do include suggestions that, in a live product, would come from pricing, demand and passport data. I treated each one as a place where intelligence earns its keep, and wrote down how it should behave.

Proposed next

Rules for how it behaves

1. Say why. Every suggestion names its basis, like "based on 60-day price history".
2. Ask before acting. Nothing is bought, changed or cancelled on the traveller's behalf.
3. Label it as a suggestion, and keep the alternative one tap away.
4. Keep it reversible: a 72-hour fare hold, free cancellation within 24 hours.
5. No false urgency. A claim about scarcity must be true and checkable.

How it compares

What other airlines already do, and where this design differs

I checked the public pages and App Store listings of the airlines Vistara's travellers compare it with: Air India, Air India Express, IndiGo and Akasa Air, with Lufthansa, Cathay Pacific and Etihad for international practice. The honest result is that no single feature here is exclusive. The differences are in the terms, the evidence and the way the pieces fit together.

The case for this design rests on the combination and on the evidence behind it, not on any feature being exclusive. A claim of "first" would need a proper competitor audit with signed-in access to each app.

Sources

• IndiGo, 6E Fare Hold
• Curly Tales, Akasa Air Lock Your Fare
• Cathay Pacific, hold your fare
• Air India app, App Store listing
• Air India Express app, App Store listing
• IndiGo app, App Store listing
• Akasa Air app, App Store listing
• Business Today, Lufthansa Apple Watch app
• Business Today, IndiGo refund steps
• Connecting Travel, Etihad visa advice tool

Accessibility

Scan, fix, scan again: 71 findings to none

The audits during the design work fixed real problems. A fresh automated scan of the final screens then found 71 more, and the web prototype had never been scanned at all. I fixed all of them and scanned again.

During the design work

I flagged one limit as I went: the HIG reference I used has nothing specific to watchOS, so the Watch findings lean on its general guidance.

The final scan, before and after the fixes

I ran an automated accessibility scan against every screen of every prototype, using the WCAG 2.0 and 2.1 A and AA rule sets. The counts are unique elements, not repeats of the same element on several screens.

The web count was 44 on the first scan and 46 after the heuristic fixes added two dimmed cabin names. Counting the first web scan, the total found was 71 across the three platforms.

What the iPhone contrast findings were

What changed to close the 71

What the scan cannot tell me

A clean scan is not proof that the screens are fully accessible. A manual pass on the iPhone prototype found problems it could not see: a settings gear that was drawn as a distorted flower, seventeen icons that did not match what they stood for, large titles that scrolled underneath the clock and battery, and a gold badge on dark cards that was close to invisible. All are fixed. The scan checks labels and colour. It says nothing about focus order, whether focus is visible on every control, what a screen reader announces after a tap, or whether a task can be finished by keyboard alone. I ran keyboard tests on the iPhone and Watch prototypes earlier, and I have not yet done that on the web prototype.

Problems and lessons

What went wrong, and what it taught me

A fix is not done until I have watched it work on the screen.

SLA and compliance impact

Where the design meets service levels and compliance

An airline makes promises with clocks attached: a fare held, a seat kept, a check-in window, a refund date. A broken promise is a service failure before it is a design failure. I treated each as a design input and checked it against what the screens say.

Service-level moments

Compliance

Impact

These are expected effects, not measured ones. They belong in the hypothesis table with the others.

Results

What I measured, and what I have not proven

Verified on the final prototypes

Hypotheses to confirm with users

What next

What I would do next

1. Put the scenario and the colours in one place

   One shared set of itinerary, account and amounts, and one shared colour set. That would keep names, seats and totals in step across all three platforms.

2. Run the next usability round

   Five moderated sessions on the web flow, using the tasks in the hypothesis table. Then a hands-on test of the Watch on a real device.

3. Hand-test the web prototype with a keyboard and a screen reader

   A clean scan does not cover focus order or announcements, and the web prototype is the one I have checked least.

If I started again

I would agree the shared scenario and colour set first, run the accessibility scan on the first screen and not the last, and keep the audit findings in a list with a status beside each. Most of the defects that mattered were found by checking, not by looking.