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.
73
screens and views
36 web, 31 iPhone, 6 Watch, counted from each prototype's own navigation
6
steps in the web booking funnel
The first-phase comps had five. Fare choice became a step of its own
1
itinerary shared across the three platforms
UK 563, PNR VST-7XQ49P, Club Vistara Gold
0
accessibility findings open after the fixes
71 found by the first scan of all 73 screens, then fixed and scanned again
The premise
Booking a flight is a long form with a price that keeps moving. The trip then lives on for weeks: a visa to arrange, a seat to change, a check-in window, a gate. Each device is good at a different part of that.
What I made
A web booking flow with six steps. An iPhone app with five tabs and the same journey. A Watch app with six screens that cover only the day of travel: next flight, status, boarding pass, a gate alert and loyalty tier.
What I checked
A click-through of every screen, a contrast calculation, a heuristic review of the web flow, two Apple Human Interface Guidelines audits and, for this write-up, an automated WCAG scan of every screen.
Same trip, same palette, and a different answer to "what matters right now?" on each device.
Context. Vistara stopped flying under its own name on 12 November 2024, when it merged into Air India. The fares, flight times and badges in the prototypes are sample content, not live data.
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
Outbound and inbound on one page. The return list sits below the fold with a second, identical date strip.
First phase Modify search panel
Edit search as an overlay. It covers the date strip it is meant to change, and the route fields still hold placeholder text.
What I kept
The named steps: Flight Details, Passenger Details, Seat Selection, Addons, Payment Details.
A price on every day in the date strip, with the lowest marked.
A filter and sort bar directly above the results.
What I changed
Fares were hidden behind a chevron in each cabin column, and "First: not offered" took a third of every card. Fare choice became its own screen.
Placeholder content (nine identical "Houston, INR 78,543" tiles, "John" and "Doe" in the route fields) became one real itinerary.
Search editing moved into the header strip so the results stay visible while you change them.
Everything after payment, and every state other than the happy path, had no design at all. Those became half of the final screens.
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.
Working persona
John Doe, the frequent business flyer
Club Vistara Gold, 32,450 miles, 14,500 of 50,000 tier points toward Platinum. Flies Bengaluru to Dubai.
Context. Books on a laptop at his desk, checks in on his phone, shows the pass at the gate.
Goals. Book quickly, use miles, keep Gold benefits visible, change plans cheaply.
Frustrations to design out. A total that moves between steps. Unclear cost of a flexible fare.
What the screens do. Running booking summary, fare matrix with the price of each upgrade, miles slider at payment, bonus-miles notes.
Working persona
Sarah Doe, the phone-first planner
A saved traveller in John's profile who plans and manages her own trips almost entirely on an iPhone.
Context. Books in short sessions, often interrupted. Wants everything about the trip in one place afterwards.
Goals. Finish a booking in sessions, know what to do before travel, keep the pass in Apple Wallet.
Frustrations to design out. Missed deadlines for visas and check-in. Re-typing passenger details.
What the screens do. Saved travellers, a "Get ready" checklist with dates, a Trips tab with days to go, Face ID at payment.
Working persona
Arjun Mehta, the family organiser
Books for several people at once, so saved travellers matter more to him than to anyone else.
Context. Compares options with others, needs one total and one reference number.
Goals. Seats that suit the group, the right meals, assistance for anyone who needs it.
Frustrations to design out. Dietary and access needs buried in a call to the airline.
What the screens do. Meal choices including Jain, kosher and child meals, a special-assistance screen, priced seat tiers, a 72-hour fare hold.
The journey, by stage
Journey map: a hypothesis to confirm in interviews
Stage
What the traveller is doing
Main device
Likely worry
Design response
Plan
Compares dates, prices and routes
Web, iPhone
Is a nearby day cheaper?
Per-day prices, flexible-dates saving, fare hold
Book
Chooses a fare, enters passengers, seats, extras, pays
Web
What will the total be? What does each fare include?
Fare matrix, running summary, clear failure states
Prepare
Arranges a visa, picks a meal, checks baggage
iPhone
Have I missed a deadline?
"Get ready" checklist with dates, meal and assistance screens
Travel day
Checks in, finds the gate, boards
iPhone, Watch
Where do I go, and when?
Pass in Wallet, next-flight card, gate alert, wrist boarding pass
After
Changes or cancels, tracks miles
Web, iPhone
What will a change cost?
Fare difference on every option, refund maths before the cancel button
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.
What the interviews are meant to settle
Walk me through the last flight you booked. Which device did you start on, and which did you finish on?
At what point did you know the price you would pay? Was it ever different from what you expected?
How do you decide between a cheaper fare and a flexible one?
What do you do between booking and flying? What do you worry about forgetting?
Who else do you book for, and what do they need?
What do you use to check in, and what do you carry to the gate?
When did you last change or cancel a booking? What was hard?
How do you use your miles, and how do you know when a tier is within reach?
How the guide maps to the design
Questions 1 and 6 decide which device owns which step. Questions 2 and 3 test the fare matrix and the running summary. Question 4 tests the checklist. Question 5 tests saved travellers and assistance. Question 7 tests change and cancel. Question 8 tests the Rewards screens.
Findings from sessions run with this guide are not reproduced here, so the persona details above stay hypotheses until they are.
Empathy maps
One map for each of the two main personas. They are working hypotheses, written to be confirmed or corrected in the interviews.
Hypothesis John Doe, frequent business flyer
Thinks
Is this the best fare for the dates I need?
Will changing my plans cost me?
How close am I to Platinum?
Does
Compares days on the price strip
Checks the price history before booking
Books on a laptop, checks in on a phone
Feels
Pressured when a price keeps moving
Relieved when the total stays put
Rewarded when miles are visible
Would say
Show me the total before I commit
What does the flexible fare actually include?
Hypothesis Sarah Doe, phone-first planner
Thinks
Have I missed a deadline before the flight?
Where will I find everything on the day?
Does
Plans in short sessions on her phone
Reuses saved travellers
Keeps the pass in Wallet
Feels
Anxious about visa and check-in dates
Reassured by a dated checklist
Annoyed by retyping details
Would say
Tell me what I still need to do
Fill in what you already know
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.
Book
1
The price moves
Totals that change from step to step make people doubt the final number.
Answered by a running summary and a 72-hour fare hold.
Book
2
Fares are hard to compare
Cabin names, baggage kilos and change rules sit in different places.
Answered by a fare matrix that reads across, with the price of each step up.
Book
3
The same details, typed again
Booking for others multiplies the form filling.
Answered by saved travellers that fill the form on one tap.
Prepare
4
Deadlines are easy to miss
Visa, check-in window and meal lock all have dates that live in different emails.
Answered by a dated "Get ready" checklist and a days-to-go card.
After
5
Changing plans feels risky
Fees and refunds only appear after you commit.
Answered by fare difference and refund maths shown before the button.
Travel day
6
Scrambling at the airport
Gate, time and pass are in three places.
Answered by a pass in Wallet, a next-flight card and a gate alert on the wrist.
Features that eliminate the pain
From pain point to feature
Pain point
Feature
How it removes the pain
Where it lives
1 The price moves
Running summary, one return-trip total, fare hold
The number you saw is the number you pay, and it can be held for 72 hours
Web results to payment; iPhone bottom bar
2 Fares are hard to compare
Fare matrix with aligned rows and step-up prices
You compare by reading across, and see what an upgrade costs
Web fare screen; iPhone fare cards
3 Details typed again
Saved travellers and autofill
One tap fills the form
Passenger screens on web and iPhone
4 Deadlines are easy to miss
"Get ready" checklist, days to go, check-in tag
Every date sits in one list with what to do and by when
Confirmation; iPhone Trips tab
5 Changing plans feels risky
Fare difference and refund maths up front
You see the cost before you press the button
Change flight and Cancel booking
6 Scrambling at the airport
Pass in Wallet, next-flight card, gate alert
The next thing to do is always the first thing on screen
iPhone boarding pass; Watch
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.
Flight
Number UK 563, BLR to DXB, 16:45 to 19:20, 4h 5m, non-stop, Boeing 777, gate B12.
Design decision. Times are the largest type on a flight card. Duration and stops sit between them.
Fare
Lite, Saver, Flex and Business: price, baggage kilos, seat rule, meals, change and refund rules.
Design decision. Rows align across fares so you read across, and each shows its step up from the one before.
Design decision. The PNR and the total are the two things people look for again, so both are easy to find.
Member
Gold tier, 32,450 miles, 14,500 of 50,000 tier points, 4,200 miles expiring in December.
Design decision. The balance is the headline. Expiry is a separate, plainly worded number.
From data to visual form
Kind of data
Visual form
Where
A price for each day
A strip of day cells with the lowest marked
Web results; iPhone results
The difference between fares
A matrix with a step-up amount under each price, such as +3,163
Fare screens
A deadline
A dated checklist row with a tag, such as "Action needed by 28 Oct"
Confirmation
Seat availability and price
A seat map by cabin, with a legend that carries the prices
Seat screens
Flight state
A coloured banner first, then times on a line
Flight status on all three platforms
Progress to a tier
A card with a bar: 14,500 of 50,000 points
Club Vistara
Time to departure
One large numeral, such as 3h 12m
Watch
A boarding pass
A large scannable code with seat, gate and zone beneath
iPhone and Watch
Money in and out
Signed lines in colour: miles in gold, promo in green, fees in red
Payment; Cancel booking
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.
Goal
Design response
How I would measure it
Status
Show the price of every choice
A running booking summary beside passengers, seats, add-ons and payment. Prices on date cells, fares, seat tiers and extras. A 72-hour fare hold.
Checked now: is a price on screen at each step? With users: drop-off by step
Checked A price is on screen at all 6 web steps, and one total carries through from passengers on: 34,500, 37,050, 34,550. The iPhone does the same: 34,500, 34,500, 35,399, 33,899
Make six steps feel short
A named stepper, one decision per screen, a fare matrix you read across
Checked now: clicks from search to confirmation. With users: time to finish, back-clicks per step
Checked 7 clicks on web and 7 taps on iPhone, from search to confirmation, accepting the defaults
One itinerary, one vocabulary
The same flight, PNR, seat, tier and miles on all three platforms; a shared colour palette
Colour and wording audit across the three platforms
Checked Flight, seat 16C, gate, tier, miles and colours match on all three. Web and iPhone both price the return trip on the Saver fare; the totals differ only by the extras and miles each applies
Usable with assistive technology
Names for controls, visible focus, text that follows a text-size setting, reduced-motion support
An automated accessibility scan on every screen; keyboard task completion
Checked 71 found, 0 open after fixes. Keyboard task completion is still to do
Give each device one job
Web and iPhone cover the whole journey. The Watch covers only the day of travel
Parity scan of iPhone against the web screen list
Checked: 8 gaps closed
Process
How the work was sequenced
Sketch
Notebook wireframes of the home page and the flight-selection page, with numbered regions so I could argue about order before drawing anything.
Map
A site map of the whole airline site: header, navigation, home, book, manage, loyalty, offers, login and footer.
Compare
Two colour directions for the home page, one aubergine and gold, one navy and amber.
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.
Bring the iPhone app to parity
A gap scan against the web screen list found eight missing screens, which brought the total to 31.
Scope and build the Watch
Six screens from a reference layout, turned into an interactive prototype and then fitted to two case sizes.
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.
Empathise
Reviewed the first-phase comps, drew the site map, wrote the interview guide and built working personas and a journey.
Define
Turned the journey into pain points, goals and a measure for each goal.
Ideate
Sketched the home and flight-selection pages and compared two colour directions.
Prototype
Built clickable prototypes: 36 web screens, 31 for iPhone and 6 for Apple Watch.
Test
Heuristic review, two HIG audits, accessibility scans and walk-throughs. Sessions with users come next.
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.
Discover
First-phase comps reviewed, the whole site drawn as a map, an interview guide written, and the journey laid out stage by stage.
Define
Personas, empathy maps and pain points narrowed the work to six problems and five goals.
Develop
Sketches, two colour directions, a design system and prototypes on three platforms explored the answers.
Deliver
Heuristic fixes, audits, accessibility scans and price and policy alignment settled what stays.
My role
On the TCS engagement I drew the sketches and the site map and designed the screens. I later turned them into interactive prototypes, tested them by hand and sent each problem back to be fixed one at a time. The audit and lessons sections say what that testing caught.
Constraints
Every price and time is sample content, not live data.
Each platform is a clickable prototype that opens with no setup.
Web is desktop-first. The iPhone is drawn at 390 by 844. The Watch has two case sizes.
Methods
Hand sketches and a site map, high-fidelity comps, clickable prototypes, a public Apple HIG reference for the audits, a heuristic review, and an automated accessibility scan for the final check.
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
Home. Eight numbered regions: notice bar, navigation, hero, a five-tab search panel, six icon shortcuts, a deals grid, two offer tiles and the footer.Flight selection. Nineteen regions. The summary strip with a Modify control, the date strip and the three-column fare row all survived into the final web screens.
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.
Site map. Colour marks the tab format, main navigation, parent calls to action and child calls to action.
Where each branch of the map ended up
Site map branch
Web (36 screens)
iPhone (31 screens)
Watch (6 screens)
Book
Booking flow: eight screens. Multi-city and destination explorer under Discover
Book tab: home, results, fare, passenger, seats, add-ons, payment, confirmation, plus date, passenger and filter sheets
Left out on purpose
Manage
Ten screens: my bookings, check-in, boarding pass, change, cancel, meals, assistance, baggage, upgrade, status
Five screens: dashboard, redeem, tier benefits, statement, transfer
Rewards tab: dashboard, redeem, tiers, statement
Club Vistara tier and miles
Offer
Offers and deals, cabin product
Discover tab: offers, the Vistara Suite cabin page
Left out
Login and sign up
Login, sign-up, forgot password, verify email, my account
Sign in, create account, reset password, Profile tab and settings
Assumes you are signed in
Header and footer
Notice bar, four-item navigation, four-column footer
Replaced by the tab bar. Legal and about links are not carried
Replaced by the watch face
The Watch cut is a decision, not a gap. Search, seat selection and payment all need typing or comparison. A two-inch screen is for the next flight, a status line, a scannable pass and an alert at the gate.
Process flow
One booking from search to travel day, seen as a sequence of what the traveller does and what the screen answers.
Stage
The traveller
The screen answers
Where
Search
Picks route, dates, class and passengers
A four-tab search panel with sensible defaults
Web, iPhone
Compare
Scans days and flights, filters and sorts
Prices per day, lowest marked, a sticky "from" total
Web, iPhone
Choose a fare
Weighs Lite, Saver, Flex and Business
A matrix that reads across, with the step-up price
Web, iPhone
Passengers
Fills or picks a saved traveller
Autofill and a booking summary
Web, iPhone
Seats and add-ons
Chooses a seat, meal, bags and extras
Priced seat tiers and a total that updates
Web, iPhone
Pay
Picks a method, applies miles and a promo
Itemised summary, free cancellation within 24 hours stated
Web, iPhone
Confirm
Reads the PNR, checks what is left to do
A "Get ready" checklist with dates
Web, iPhone
Prepare
Sorts a visa, meal, check-in
Days to go, a check-in tag, reminders
iPhone
Travel day
Finds the gate, shows the pass, boards
Next-flight card, pass in Wallet, gate alert
iPhone, Watch
User flows
Book
Home
Search
Results
Fare
Passengers
Seats
Add-ons
Payment
Payment fails?
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
Trips
Trip detail
Change, cancel, add bags or check in
Fare difference or refund maths
Confirm
Travel day
Watch face
Next flight
Status
Boarding pass
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 1. The airline's own colours. Gold appears as a hairline under headings and on the search tab.
Theme 2 Navy and amber
Theme 2. A placeholder logo, an amber primary button and an extra loyalty band above the footer.
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.
Theme 1, calendar open. A selected range in solid aubergine reads clearly against the pale surface.
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.
Aubergine#511D4B Buttons, headings, links. 12.9:1 on white
Deep aubergine#3A0F35 Header and hero. Gold on it: 5.9:1
Night#2A0726 Darkest surface, and the text colour on the Watch's gold buttons
Matte gold#BB9753 Dark surfaces only. On white it is 2.7:1
Gold, deep#80642D Gold as text on light. 5.6:1 on white
Paper#FBF8F2 Page ground. Ink on it: 17.5:1
Contrast of the main pairs, calculated from the hex values
Pair
Ratio
Normal text, 4.5:1
Where it is used
Ink #1A0F1F on paper #FBF8F2
17.50
Pass
Body text
White on aubergine #511D4B
12.91
Pass
Primary buttons
Muted #5C4D63 on white
7.79
Pass
Secondary text
Success #3A6347 on paper
6.48
Pass
Confirmations
Gold #BB9753 on deep aubergine #3A0F35
5.90
Pass
Accents on the header and hero
Deep gold #80642D on paper
5.24
Pass
Gold text on light surfaces
Danger #B23A3A on paper
5.57
Pass
Errors and destructive actions
Matte gold #BB9753 on white
2.74
Fail
Never used as text on light. This is the rule
Across the three platforms
Colour
Web
iPhone
Watch
Aubergine #511D4B
Yes
Yes, as the tint colour
Yes, in the cards, blended with the lighter aubergine #6E2D67
Matte gold #BB9753
Yes
Yes
Yes
Light gold #D4B477
Yes
Yes
Yes, as the main accent
Deep gold #80642D
Yes
Yes
Not needed. The Watch has no light surfaces
Status colours
Muted green and red tuned to the paper ground
Four system-style colours, darkened. Green, red and blue pass 4.5:1 on white. Orange is only an icon fill
watchOS dark-mode green, red and blue
Type
Quicksand for headings, Inter for interface text, DM Mono for small data labels
Quicksand for the wordmark and titles, the system font for everything else
System font with a text-size scale of 1, 1.15 and 1.3
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
Booking flow
8 screens
Web: flight results
Results. Filters on the left, days and prices across the top.
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
Fare choice as its own step. In the comps this lived behind a chevron.
Web: passengers
Passengers. Saved travellers fill the form on one tap. The summary panel stays at the right.
Web: add-ons
Add-ons. Meals come as cards. The summary panel keeps the running total.
Web: seat selection
Seats. Seat 16C chosen, an aisle seat at no charge on the Saver fare.
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
Payment. Card, UPI, net banking and wallets, with a card preview beside the form.
Web: confirmation
Confirmation. The PNR sits in its own box under the greeting, and a pass preview follows.
After the booking
Manage, loyalty and edge cases
Web: my bookings
My journeys. The action on each trip changes with the trip's state: check-in, boarding pass, change.
Web: flight status
Flight status. Look up by flight number, route or PNR. The state is a coloured banner first, numbers second.
Web: Club Vistara
Club Vistara. Balance and tier first, then the distance to the next tier.
Web: payment failed
Payment failed. It says what happened, that the seat is held and for how long, and offers two ways forward.
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.
Findings from the review and what changed between the earlier and the latest version
Finding
Heuristic
Before
After
Check
Edit Search threw you out of the results
User control and freedom; flexibility and efficiency
The button jumped to the home page, leaving the results behind.
A panel opens under the route strip with depart, return, class and passengers. Cancel closes it, Apply updates the summary and shows a "Search updated" message. The button reads Close while the panel is open.
Tried in both versions. The earlier one landed on Home. The latest stayed on Results with the panel open. Applying two passengers in Business updated the summary line; Cancel closed the panel. Fixed
The same fares had two sets of names
Consistency and standards; match with the real world
Result cards named the fares by cabin: Economy, Business, Premium Economy. The next screen called them Lite, Saver, Flex and Business.
Cards now lead with the fare name and follow with the cabin: Lite · Economy, Flex · Premium Economy, Business · The Vistara Suite.
Compared the labels on the first flight card in both versions. Fixed
Step numbers repeated the stepper, on half the steps
Aesthetic and minimalist design; consistency
Fare, add-ons and payment began with "Step 02 /", "Step 05 /" and "Step 06 /". The other three steps had no such label, and the stepper already shows where you are.
The labels are gone. The stepper is the one place that numbers the steps.
Compared the headings on the three screens in both versions. Fixed
Navigation controls ignored the keyboard
Flexibility and efficiency of use
Some navigation links, such as Log-in and the back links, responded to a click but not to the keyboard.
Enter and Space were meant to activate those links.
The progress steps already took Enter in both versions. The 11 links the change targets could not take focus, so nothing improved. The accessibility pass gave them focus and a role; Log-in now opens with Enter. Fixed in the accessibility pass
Web: Edit Search, open in place
Edit Search. The results stay in view while you change the search.
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
The fixes left two things behind. The grey cabin names on the cards were dimmed to 70% and measured 3.65:1, which took the web scan from 44 to 46 findings. The accessibility pass removed the dimming. The second is still visible: "Business · The Vistara Suite" wraps to two lines, which makes that card taller than its neighbours.
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.
What changed from the web
Top navigation became a five-tab bar: Book, Trips, Discover, Rewards, Profile.
Tab roots use large titles. Pushed screens use a standard navigation bar with a Back label.
Forms and settings are grouped inset lists, the way Settings does it.
Dates, passengers and class, and filters open as bottom sheets, each with Cancel and Done.
Every funnel step ends in a bar that holds the running price beside the primary button.
Small platform touches
An Apple Wallet button on the boarding pass.
Face ID for payments as a setting, and Continue with Apple on sign-in.
Steppers and switches sized for a thumb: 44-point steppers, 51 by 31 switches.
Every screen and state can be reached from inside the phone: tap the Dynamic Island, or Profile then All screens, for an index of all 31 screens and three sheets. A "Simulate a declined card" switch on Payment leads to the failure screen, and filters that return nothing lead to the no-results screen.
A Text size setting with Default, Large and Larger. Every piece of text follows it, and the screens hold up at the largest size.
On the cancel screen the safe choice, Keep my booking, is the filled button. Cancelling is plain red text.
After booking, a "Get ready for Dubai" checklist: visa by 28 Oct, seat, meal, check-in opening 31 Oct.
The booking flow
Home. One search card, five shortcuts.Results. A day-later saving is called out below the list.Fare. Fares stack, with included and excluded items ticked or struck.Passengers. Saved travellers autofill.Seats. Skip is available in the bar.Add-ons. Switches and a stepper, with a Gold bonus-miles note.Payment. Miles can pay part of the fare.Confirmed. The checklist begins the trip.
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.
Results. Flight times and prices at 130%.Fare. The Saver price drops below its name when the row runs out of room.Payment. The total and the button stay in view.Settings. Default, Large and Larger.
After you book
Trips. Days to go are the first line of each card.Trip detail. Terminal, gate, seat, then actions.Boarding pass. Add to Apple Wallet sits under it.Check-in. The closing time is stated up front.Change flight. Each option shows its fare difference.Cancel. Refund maths first, then the two buttons.
Around the journey
Discover.Cabin page. Specs as big numerals.Rewards. The card is the page's one dark surface.Flight status.Meals. Locks 24 hours before departure.Assistance. Requests go only to the crew who need them.Payment failed. Seat held, nothing charged.No results.
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.
Face. A flight complication: destination, time left, gate, boarding time.Next flight. One large figure, one shortcut to the pass.Status. On time in green, then three times on a line.Boarding pass. The code takes most of the screen.Gate alert. Says what to do, then one button.Club Vistara. Tier ring and miles.
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.
49mm Ultra. The wider screen fits a third field, zone, under the code.Gate alert, Ultra. The same copy, one fewer line break.
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.
Prototype fidelity. Every number in these suggestions is sample content. No model sits behind them, so they test whether the suggestion is clear and trusted, not whether it is accurate.
Suggestions already in the prototypes
Suggestion
What it tells the traveller
What a live version would draw on
Price insight
"This route is typically INR 17,400, and you are looking at fares 19% below average", with a 60-day basis, Track price and Price history
Fare history for the route
Flexible dates
A day that saves money, such as "Departing Mon 04 Nov saves you INR 4,238"
Live fares for nearby days
Nearby options on empty results
Dates within three days, and nearby airports, with fares
Availability across dates and airports
Budget explorer
"Where can your budget fly you?" for travellers who start from a number
Fares to every destination from the home airport
Recommended fare
Saver marked as the most popular choice
Booking patterns for the route
Pre-trip checklist
"Apply for UAE visa", with who needs it and by when
Passport and destination rules
Proposed next
Proposed, not built
Disruption rebooking
When a flight changes, offer the best alternatives with the cost of each, and wait for the traveller to choose.
Proposed, not built
Plain-language search
"Bengaluru to Dubai next Friday, flexible by two days" fills the search panel and shows what it understood.
Proposed, not built
Fare advice
Tell the traveller whether to book now or hold, and say what the advice rests on.
Rules for how it behaves
Say why. Every suggestion names its basis, like "based on 60-day price history".
Ask before acting. Nothing is bought, changed or cancelled on the traveller's behalf.
Label it as a suggestion, and keep the alternative one tap away.
Keep it reversible: a 72-hour fare hold, free cancellation within 24 hours.
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.
Limits of this check. It uses public pages and store listings read in October 2026. I could not sign in to any app, so features behind a login are not covered, and "not found" means I did not find it, not that it does not exist.
This design against what other airlines publish
Feature
This design
What I found elsewhere
Verdict
Fare hold
72 hours for INR 499, offered on the results screen, with the exact end time confirmed in a message
IndiGo sells a 6E Fare Hold for 48 or 72 hours, from INR 99 on domestic and INR 199 on international flights. Akasa Air has Lock Your Fare. Cathay Pacific holds a fare for 72 hours, but not on departures from India
Market standard
Apple Watch companion
Six screens: a flight on the watch face, next flight with a countdown, status, boarding pass, a gate alert with one tap to the pass, a text-size control
Lufthansa has a Watch app with a boarding countdown and boarding card. Air India's App Store listing includes Apple Watch. The IndiGo and Akasa Air listings do not mention it
Common abroad, rarer among Indian low-cost carriers
Boarding pass in Wallet
An Add to Apple Wallet button on the pass
Air India, IndiGo and Akasa Air all offer it
Market standard
Refund shown before cancelling
Refund maths first, then a choice of cash or travel credit with the bonus shown beside the cash figure
IndiGo shows the booking amount, the charges and the refund, with a credit shell as an option. Air India shows the deduction and refundable amount before you confirm. I found no travel-credit bonus at either
Differs in the credit bonus
Pre-trip checklist
A dated "Get ready" list after booking, with the visa deadline for the passport holder
Etihad offers a visa advice tool, fed by IATA's Timatic data, that is reached through its help page. I did not find a dated checklist after booking on the Air India, IndiGo or Akasa Air pages
Not verified either way
Accessibility evidence
No findings on a WCAG 2.1 A and AA scan of all 73 screens, a text-size setting on iPhone and Watch, and open items listed
The App Store listings for Air India, Air India Express, IndiGo and Akasa Air each say the developer has not yet indicated which accessibility features the app supports
Differs in what can be shown
Conversational assistant
None. The prototypes have suggestions only
Air India's app describes an AI virtual assistant for status, baggage, rebooking and refunds
Behind
What is distinctive
One trip told the same way on three devices: the same flight, seat, gate, tier and miles, and a price model that holds from search to payment.
A day-of-travel chain, from the next-flight card to the pass to the gate alert, designed as one sequence.
An accessibility baseline that can be shown, not just claimed.
What it does not claim
That the fare hold, the Wallet pass or refund-before-cancel are new. They are not.
That a Watch app is rare. Other airlines have one.
That it beats Air India's assistant. It has none to compare.
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.
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
iPhone contrast
I calculated contrast ratios instead of judging them by eye. Seven failures turned up, and I fixed them by darkening on-brand colours until they passed.
iPhone HIG audit
Sixteen fixes, sorted into critical and improvement tiers. Critical: contrast, missing keyboard and VoiceOver behaviour on custom tappable elements, and no Dynamic Type. Improvement: missing Cancel buttons on sheets, inverted button hierarchy on destructive actions, pre-filled password fields, and small touch targets.
Watch HIG audit
Text-size control, spoken labels on back buttons, swipe limited to one chain of screens, reduced-motion support, and Club Vistara reachable by tap. A second, deeper pass found four more real problems: tap and swipe conflicts, text clipping at large sizes on two screens, and row labels that would not wrap.
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.
Accessibility scan results, before and after the fixes
Platform
Screens scanned
First scan
After the fixes
Main causes
Web
36
46
0
Unlabelled fields and selects, icon buttons with no name, seven low-contrast text spots
iPhone
31
24
0
Low-contrast text, sheet backdrops tagged as buttons, zoom blocked
Watch
6
1
0
A button whose spoken name left out its visible text
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.
Web, 46 found
Fields with no label
21
Selects with no name
12
Icon buttons with no name
6
Low-contrast text
7
iPhone, 24 found
Low-contrast text
16
Sheet backdrops tagged as buttons
4
Scrolling row not keyboard-reachable
2
Button with no name
1
Pinch zoom blocked
1
What the iPhone contrast findings were
The 16 iPhone contrast findings, grouped by cause
Cause
Elements
Measured ratio
What I did
Tertiary label colour used for text: section dividers, the seat-map caption, password and sign-up placeholders
7
1.8
Text now uses #6B6B70 (4.75:1 on the grey ground, 5.3:1 on white). The faint grey stays for borders
Greyed "not included" fare rows
4
1.8
Same darker grey, and the strike-through stays as a second cue
Dimmed past-trip card at 62%
3
2.6 to 3.1
Dimming removed. The card is now outlined and keeps full-strength text
Gold tier label#B8902F on white
1
3.0
Deep gold #80642D, 5.6:1
Status-bar clock
1
1.1 reported
A false positive, since it is white over a dark hero. I drew the clock so the scan no longer misreads it
Two of my own fixes had caused findings. The heuristic fixes dimmed the new cabin names on the web result cards to 70%, which added two web findings. On the iPhone, a pass that made every custom tappable row reachable by keyboard also tagged the four full-screen sheet backdrops, which hold real buttons, as buttons themselves. Both are fixed now. A fix that changes colour or adds a global behaviour needs the scan run again.
Dynamic Type is now covered. The audit listed it as critical. Pinch zoom is back on, and the iPhone has a Text size setting, Default, Large and Larger, that every piece of text follows. I checked all 31 screens at Larger for clipped text and fixed the one fare card that clipped.
What changed to close the 71
Finding
What changed
Web: 21 unlabelled fields, 12 unnamed selects
Every field and select now has a label: first name, card number, promo code, miles to redeem, verification digits and the rest
Web: 6 icon buttons
Named Close filters, Previous days, Next days, and Swap origin and destination
Web: 7 low-contrast spots
The cabin names on result cards lost their dimming. "Non-refundable" and the dimmed current date now use the muted colour #5C4D63 (7.8:1 on white). The large 404 numeral is a darker decorative gold, #9E8A5E, 3.2:1 on paper
Web: page title and language
The prototype now has a title and a language, so a screen reader announces it properly
Web: 11 navigation links out of keyboard reach
They can now take focus and open with Enter. Log-in was checked by hand
iPhone: 4 sheet backdrops
Backdrops are no longer tagged as buttons. Tapping outside a sheet still closes it
iPhone: zoom, scrolling row, edit button
Pinch zoom switched back on. The passenger page and the saved-traveller row are keyboard-reachable and labelled. The edit button is named "Edit trip"
Watch: 1 name mismatch
The face button's spoken name now begins with what is on the face: date, time, destination, time left, gate and boarding time
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.
What I saw
Cause
Fix
Lesson
Audit fixes were reported as done, and were not
They had been reviewed on paper but not seen in the running prototype. I questioned it twice
Re-verified three ways: on the screen, element by element, and by keyboard
Say so when your own check gives a false result
Watch views did not appear, the back button sat in the centre, scrolling failed and progress dots covered content
A layout fault that only showed when the screen was rendered
Screenshots of the real screen, then one fix per problem
Look at the screen first, then theorise
The Watch looked wrong on an Ultra
Screen dimensions matched the 45mm case only. I noticed
A toggle that swaps case and screen size
Check device specs before drawing
Web prototype never scanned
I treated it as the reference for brand and content, and never scanned it. The first scan found 44 elements, and 46 after the heuristic fixes
Fixed. Scans clean now
The reference needs the audit most
The web total and seat changed between steps
Search, passengers and seats priced the return trip (28,174) and seat 16C. Add-ons, payment and the boarding pass priced one way (19,800, then 17,300) and seat 11A
Fixed. Both prototypes now price the return trip on the Saver fare, web 34,500, 37,050, 34,550 and iPhone 34,500, 35,399, 33,899, with seat 16C throughout
Write the scenario once and reuse it
A heuristic fix added two contrast failures
The new cabin names on the result cards were dimmed to 70%, which measures 3.65:1
Fixed. Dimming removed
Re-scan after every visual change, not at the end
Icons that looked wrong, text under the clock, and a badge that disappeared
The settings gear was a distorted shape, and a percent sign stood for Currency, a star for Appearance and an arrow for Car rentals. Titles scrolled under the status bar. The gold badge sat on a dark card with no solid fill, and the scan cannot read colour over a gradient
Fixed. Correct icons, a status bar that gains a backdrop once content scrolls, and a solid gold badge on dark surfaces
Run the scan, then look at every screen as well
A blanket accessibility pass confused the sheets
Every tappable item was made keyboard-reachable, including full-screen sheet backdrops that contain real buttons
Fixed. Backdrops excluded
A global pass needs exceptions and a re-check
Audit findings and the screens disagree
Dynamic Type was on the iPhone audit list, but the prototype had fixed text sizes
Fixed. A Text size setting scales all text, and every screen was checked at the largest size
Track each finding to a check that closes it, not to memory
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
Where a commitment shows up, and how the design supports it
Moment
Commitment
How the design supports it
Fare hold
The fare is held for 72 hours for INR 499, refundable if the traveller does not book
A banner at results, and a message that names the exact time the hold ends
Payment fails
The seat is held for 14 minutes and nothing is charged
The failure screen gives the reason, the hold time and two ways forward, on web and iPhone
Free cancellation
Free within 24 hours of booking
Stated next to the total on the web payment screen
Check-in window
Opens 48 hours before departure and closes 60 minutes before
Stated on the check-in screens, with an "Opens 31 Oct" tag on the iPhone. Both platforms now say 60 minutes
Meal choice
Locks 24 hours before departure
Stated on the iPhone meal screen and beside the add-on
Special assistance
Requests confirmed within 24 hours
Stated on the iPhone screen, with a note that requests go only to the crew who need them
Changing a flight
Saver change fee INR 1,500 plus the fare difference
The total is on the confirm button before anything is paid
Cancelling
Saver cancellation fee INR 3,500. Refund in 5 to 7 business days
Refund maths first, a choice of cash or travel credit, then the buttons. Both platforms now show INR 3,500
Compliance
Area
What the design does
Status
Payment data
The card preview and the iPhone form show only the last four digits, the security code is masked, and receipts show only the last four digits. A live version would use the payment provider's secure card fields
Confirm with the payments team
Passport details
The number is masked on check-in and the boarding pass, for example M••••740. It was shown in full before this round
Fixed
Marketing consent
Offers are off by default at sign-up and in Settings. The iPhone sign-up had them on by default before this round
Fixed
Assistance requests
Shared only with the crew supporting the flight, and the screen says so
Supported
Accessibility
A WCAG 2.1 A and AA scan finds nothing on all 73 screens. Keyboard and screen-reader testing on the web prototype is still to do
Partly checked
Fee and refund wording
Amounts and windows match across web and iPhone
Legal review of the copy needed
Impact
Where
Expected effect
How to see it
Deadlines in the checklist
Fewer calls about visas, check-in and meals
Contacts per booking, by reason
Payment-failure screen
More travellers finish the booking after a failed payment
Recovery rate after a failed attempt
Fees shown before the button
Fewer disputes about change and cancellation charges
Complaints that mention fees
Consistent wording across platforms
The same promise on every device
Copy audit before release
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
Check
Result
How
Screen count
36 + 31 + 6 = 73
Counted from each prototype's own navigation
Brand colour contrast
7 of 8 pairs pass; the eighth, gold on white, is barred by rule
Calculated from the colour values
Colour consistency
Matte gold and aubergine in all three platforms
Compared the colours across the three prototypes
Length of the happy path
7 clicks on web, 7 taps on iPhone
Walked search to confirmation accepting the defaults
Price on screen
A price at all 6 web steps, and one total carried from passengers on (34,500, 37,050, 34,550). iPhone: 34,500, 34,500, 35,399, 33,899
Walked the happy path and read the summary at each step
Heuristic fixes
3 fixed, 1 partly fixed
Each behaviour tried by hand, earlier version against latest
WCAG A and AA scan
71 found, 0 open after fixes: web 46, iPhone 24, Watch 1
Automated scan of every screen, before and after
Hypotheses to confirm with users
Hypothesis
How to test it
What would count as support
A separate fare screen lowers regret about the fare chosen, even with one more step
Five moderated sessions on the web flow with two tasks: book the cheapest flexible fare, then change a seat
Fewer back-clicks at the fare step; participants can say what each fare includes
A 72-hour fare hold reduces drop-off at results
Compare completion with and without the banner
Fewer exits from the results screen
The "Get ready" checklist moves visa and check-in tasks earlier
Ask participants to plan the week before the flight from the confirmation screen
They find the visa deadline without prompting
A boarding pass on the wrist is faster at the gate
Time pass presentation on a real watch against the phone
Shorter time to scan, fewer fumbles
Reserving gold for dark surfaces keeps hierarchy clear
Five-second tests on results and fare screens
Participants name the primary action correctly
What next
What I would do next
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.
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.
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.
