A chauffeur you can find, and a search you can talk to

The short version

Etihad asked for two features in its mobile app. I designed both, from research through to clickable prototypes.

The first helps Business Class passengers book and track the free airport chauffeur. Today they have to find it, book it themselves and then wait with no live status. The second is a flight search you can talk to. Type "anywhere in Europe for under $700 for two people" and get a short list of real options.

Both designs follow two habits: lead with reassurance, and keep the traveller in charge. In the chauffeur flow that means a pickup time suggested from your flight, a warning when a time is risky, and a live map with a named driver on the day. In search it means an assistant that shows what it understood and admits what it can't do, with every part of its answer editable.

The research is desk research and my own analysis, with no interviews, and I haven't run user testing, so nothing here claims a measured result. I reviewed the screens against Nielsen's ten heuristics, then clicked through every flow in the prototypes, which turned up many problems I would never have spotted by looking. The plan for testing with real travellers is near the end.

The brief

Etihad's mobile app covers a customer's whole trip, from inspiration and booking to services on the day. The task picked out two moments and asked for user flows, wireframes and two or three high-fidelity screens for each.

Feature 1: chauffeur booking and live tracking

A Business Class passenger gets a complimentary chauffeur with their ticket, but has to book it themselves. The service is tied to their flight and has a time limit, and they expect something close to Uber. The flow had to cover discovering the perk, booking it with pickup location, time and passenger details, a confirmation that reassures, and live tracking on the day of travel.

Feature 2: AI-powered flight search

Etihad wanted a search that understands natural language, such as "Find flights to anywhere in Europe for under $700 for two people." That meant reworking the home screen to give it a clear entry point, then designing the prompt, the AI's response, how flight options appear, and what happens next: refine, save or book.

I went past the brief in one way. I built both flows as clickable prototypes, so I could test the decisions instead of only drawing them.

How I worked

I followed the double diamond: open up to explore, narrow to a clear problem, open up again to try ideas, then narrow to something I can prototype and check.

Along the way I used competitor analysis to find the gap, jobs to be done to focus on what each person is really trying to achieve, personas and journey maps to find the painful moments, a heuristic review to check my own screens, and design-system thinking to keep both features looking like one product. I worked in loops: build a little, review it, fix it.

Research and insights

What I wanted to find out

I started from one idea: a premium airline should turn its two most stressful moments, getting to the airport and deciding where to go, into easy ones. So I wrote down my questions before drawing anything.

Two shifts in how people use apps

People now expect an airline app to feel as live as Uber. When a car is coming for me, I expect to see it move, know when it will arrive, message the driver and share my trip. A free Business Class chauffeur shouldn't feel worse than a taxi app. It should feel better.

People also want to talk to apps. Thanks to AI chat, many start with an idea, like "somewhere warm in Europe, under budget, for two", instead of a route. Flight search still asks for exact dates and airports, so there's a gap between how people think and how the tools work.

How competitors handle the chauffeur

I compared three kinds of apps that people already hold an airline against: everyday taxi apps, which set the bar for tracking; premium chauffeur services, which set the bar for service; and other airlines' free transfers.

The empty corner is where I aimed. I put the free chauffeur on the trip card so it's hard to miss, made the time step aware of your flight, and added a live map with a calm "we're watching your flight" message.

How competitors handle AI search

Here I compared classic search engines, which are fast and trusted but form-first, with AI chatbots, which handle conversation well but are often a black box you can't verify or book from.

What stood out is that the distrust comes from opacity. People can't see what an AI is doing, so they can't check it. So I built the assistant around a simple loop. You ask in plain words. The assistant shows what it understood and lets you edit any part. Then you pick and book real flights, each with a reason. The AI suggests and you decide.

Who I designed for

I pictured three travellers and wrote down the real goal behind what each is doing. I included an older traveller on purpose, since clear text, simple steps and reassurance help everyone.

Where it hurts today

I walked through each journey as it works now and marked how the traveller feels at each step. The unhappy moments are where design can do the most good, so that's where I focused.

What I took from it

Rules I set myself

• Reassure first, inform secondLead with status and human touches. Calm is the feature.
• Always know the flightUse it to suggest times, watch for changes and warn before things get risky.
• The AI suggests, you decideShow what it understood, let people edit it, explain the why.
• Premium means fewer stepsLuxury is smart defaults and no payment fuss, not decoration.
• Borrow what people already knowUse familiar patterns like live tracking and chat, then make them a notch better.
• Always have a plan BDesign for delays, tight times, full cars and changed minds. Confirm before anything that can't be undone.
• Reveal on demandShow the recommendation and keep extra controls one tap away.
• Make it work for everyoneClear labels, keyboard use, screen-reader support, gentle motion and strong contrast from the first sketch.

Chauffeur booking and live tracking

A free perk that's easy to miss, a booking that guesses the time, and no way to see the car on the day.

The problem

Amara flies Business on Friday. Her ticket includes a chauffeur to the airport, but it's buried in menus. When she does find it, she fills in a form and has to pick a pickup time without knowing how long the drive will take. On the day there's no live status, so she keeps checking, and when a car arrives she isn't sure it's hers.

The idea

Put the perk on the trip card people already open. Let the flight suggest the pickup time, and warn when a time looks risky. On the day, show a live map with a countdown, the driver's name and plate, and one-tap call and message.

The flow

1. Trip card
2. Intro and inclusions
3. Pickup location
4. Pickup time
5. Passengers and vehicle
6. Review
7. Confirmed
8. Trip details
9. Live tracking
10. Arrived and rate

Wireframes

I sketched the layout and the order of steps in grey boxes first, before any colour.

Final screens

Every screen below is from the working prototype, in the light theme.

Decisions that mattered

The perk lives on the trip card

Most people never use a perk they can't find. So the chauffeur sits on the trip card people already open, as a row that says "Chauffeur included" and shows its state: not booked, booked for Friday at 14:20, or driver assigned. Tapping it starts the booking.

Online check-in sits right below it, visibly disabled until it opens, so a tap never goes nowhere.

Pickup times come from the flight and the drive

The time step starts with a recommendation: four hours before departure, which for an 18:20 flight is 14:20. People can pick another slot or type their own time in a 24-hour picker, so there's no AM and PM to mix up.

Every time is checked against the flight and the drive to the airport. If the buffer drops under two hours, an amber note says how long you'd have before check-in closes, and you can still continue. If you'd reach the airport after check-in closes, the button changes to "Choose an earlier time" and a red message explains why.

I only block a time when the booking can't work. My drive-time figure is an estimate, so a warning is the honest answer to a risky time. A 16:30 pickup reaches the airport about ten minutes before check-in closes, so it warns. At 16:50 it's blocked. The real service already asks for 12 hours' notice, so a hard rule for an impossible time fits how it behaves.

A bigger car when the party needs one

The passenger step is two steppers, guests and bags. Past three of either, the vehicle card changes in place from a BMW 7 Series to a BMW X7, with seats for seven and room for six large bags, and a short message says the larger car is still included. The warning and the vehicle card update together, so they never disagree.

One tap can't cancel a booking

Once booked, the trip screen shows the details and two actions. Reschedule opens the time screen in its own mode, with a "Save new time" button, and returns straight to the trip. Cancel opens a dialog that restates the policy, free until an hour before pickup, and shows which booking is about to go. "Keep my booking" has focus, and Escape keeps it too.

Before travel day the tracking button is visibly locked and says "Tracking opens on travel day". A live map with nothing to show would look broken, so I show the lock instead and explain that a driver is assigned about two hours before pickup. In the prototype a small "Preview travel day" button jumps ahead.

The day itself

On travel day the screen becomes a map. A countdown ("Arriving in 6 min"), the driver's name, rating and plate, and one-tap call and message sit in a sheet at the bottom. The pins read "Driver" and "You", so it's clear whose arrival is being counted.

The rating question, "How was your ride?", appears only after the trip is done. An early version asked while the car was still moving, which is a poor moment to ask anything.

The flow also runs the other way. For a flight landing in London, the drop-off is a London address, the driver and plate are British, and the suggested pickup is 30 minutes after landing, with earlier times blocked. For an early morning flight, the pickup moves to the evening before and says so. And a Business booking made in the AI search opens this flow with the real flight already filled in.

AI flight search

People arrive with an idea. Search tools ask for airports and dates, and chatbots give answers nobody can check.

The problem

Amara has a long weekend and a budget, and no particular destination. She types "somewhere warm" into a form that wants an airport code. She opens ten tabs. An AI chatbot gives her a confident answer, but she can't see how it got there and can't book from it.

The idea

A clear AI entry point on the home screen, and a loop that earns trust: you ask in your own words, the assistant shows what it understood and lets you edit it, and you choose from a short list that explains itself. A normal search stays one tap away for people who just want that.

The flow

1. Home with AI entry
2. Ask in your own words
3. What I understood
4. Results
5. Flight detail
6. Choose fare
7. Confirmed and saved

Wireframes

Same approach as the chauffeur: structure and order first, styling later.

Final screens

From the working prototype, light theme.

Decisions that mattered

Two doors on the home screen

The home screen puts a dark "Ask Etihad" card above a normal search form. The form works: To, Dates and Guests open the same pickers the assistant uses, and "Search flights" asks for a destination first. Someone who knows exactly what they want shouldn't have to talk to an assistant.

A small dismissible hint offers two examples the assistant can really answer.

Show what it understood

After a prompt, the assistant answers with a card of what it understood: destination, budget, travellers and dates, each one editable. A live count says how many options match, and a few top matches preview the answer before the full results.

Nothing is hidden behind the AI. If it got the budget wrong, you fix it with one tap.

Say what it assumed, and say no when it has to

When a prompt says "€400", the assistant converts it and tells you: "I converted €400 to about $430." When someone asks for five travellers, it sets four, the most it can book, and says so. When they ask for something outside what it covers, like Tokyo, it says "I can't search Tokyo yet" and offers Europe, instead of quietly showing something else.

Early versions did the quiet thing. That's the behaviour that makes people stop trusting AI, and it wouldn't have shown up in a screenshot.

A short list, with reasons

Results are a ranked shortlist by destination instead of hundreds of fare combinations. Each card says why it's there ("Direct from AUH, best value for two"), and the detail screen shows how much budget is left: "$88 under your $700 budget". I used that in place of crossed-out discounts, which don't suit a premium airline.

Loading that explains itself

While results load, the assistant's message shows moving dots and "Finding your options", and placeholder cards hold the space where results will land. Before that, the screen sat blank for a moment, which looks like something broke.

With reduced motion turned on, the dots and shimmer are skipped and results appear straight away.

Honest fares and sensible extras

Fares carry a plain note that they're indicative until you book. Extras like an airport chauffeur, a bag or a seat appear for Economy only, because Business already includes them.

When someone books Business, the confirmation offers "Arrange your chauffeur". It opens the chauffeur flow with the flight, date and times already filled in, and the booking appears in My Trips.

One design system for both

Both features use one small system, Beyond Borders: deep slate surfaces, soft gold accents, warm paper, and a few semantic colours for confirmation, caution and alerts. Figtree carries the text, and IBM Plex Mono is reserved for flight codes and prices.

Shapes scale with the element: 7 px corners on chips, 11 px on buttons, 14 px on cards, 20 px on sheets, and full pills for avatars. The four-point spark marks every AI moment. I redrew it as one symmetric shape after finding two slightly different versions in use, one of them lopsided.

Light and dark

Surfaces, text and the semantic colours change with the appearance. The slate panels, gold accents and the spark stay the same, and the primary dark buttons invert to cream in dark mode so they remain the most prominent thing on screen. Each app has a small appearance control (Auto, Light, Dark) inside the phone, so you can switch without leaving the prototype.

The two features also follow one habit. Both recommend first and then hand over control: a best-value trip or a pickup time matched to the flight, with the extra controls one tap away. They connect too. A Business booking made in search opens the chauffeur flow with the real flight attached.

Accessibility

I built accessibility into every pass from the first sketch. What I measured:

• Every tap target is at least 44 by 44 px, and no text is smaller than 11 px.
• Slate text on paper measures 14.5:1 and secondary text 5.8:1. The lighter bronze only reaches 3.2:1, so it is limited to icons and large text, and small bronze text uses a darker shade at 6.3:1. In dark mode the pairs measure between 8:1 and 15:1.
• Option groups work with the arrow keys. Focus moves to each screen's title when it opens, and returns to the button that opened a sheet when it closes. Escape closes sheets and dialogs.
• Changes are announced to screen readers, for example "Upgraded to BMW X7" or "Pickup set to Fri 12 Jun, 14:20. Warning: that may be too tight for your flight."
• Reduced motion is respected. The loading shimmer and the tracking animation drop out.

I haven't tested with VoiceOver or TalkBack yet. That's in the plan below.

How I checked my work

I did two passes, and I want to be clear about what each one is and isn't.

Pass 1: an expert review

I inspected every screen against Nielsen's ten heuristics and rated issues from 0 to 4. I'm the designer, so this is a self-review. It finds weak spots well, but it isn't evidence that real people succeed. The scores below are my own ratings out of 5.

Three findings are still open: a short "how your chauffeur works" help sheet, a per-person price hint in the AI flow, and live fares in place of the sample fares.

Pass 2: testing every flow in the prototypes

I clicked through every flow, measured tap targets, computed text contrast from the finished screens, and checked 110 flight-row layouts (every destination and time option, light and dark) plus 50 screen states for broken icons. This found far more than the review did. These are the problems that mattered most.

What I'd do next

Test with real travellers

I haven't run user testing, so that's first. I'd watch five to eight travellers per feature think aloud, with tasks like these:

• "You're flying Business on Friday. Arrange your free chauffeur so you get there in good time."
• "Your flight time shifted. Set your own pickup time."
• "Find a trip anywhere in Europe, under $700, for two."
• "The AI got your budget wrong. Fix it, then add an extra bag to an Economy fare."

I'd add a quick where-would-you-tap test for the AI entry on the home screen, a larger online test for success rate and speed, and a day-in-the-life check of the chauffeur on a real travel day.

What good would look like

These are targets I'd hold the design to, not results. About nine in ten people finish each task without help. A usability score above 80. Faster than the current form. Almost no accidental bookings or wrongly set times. People saying they felt in control of the AI. More chauffeurs actually booked.

What a real build needs

Live driver and flight feeds for the map and the flight-watching message. A geofence or a trip-ended event from the driver app, so the rating appears at the true end of the ride. Live fares and a secure checkout hand-off. Saved addresses and one-tap rebooking. The two riskiest parts are trust in the AI and the operations behind live tracking, so I'd pilot both small before building wide.

If I had to cut scope, the first release would be discover, book and confirm for the chauffeur, and prompt to results to booking for one route. Live tracking, voice, extras and multi-city come later.

What I learned

Calm turned out to be the feature. Whenever I wasn't sure what a screen should do on travel day, the answer was to show less and make the status clearer. A moving car and a named driver say more than a paragraph of policy.

Honesty is a design problem for AI. The assistant's early versions changed things without saying so: a euro budget shown as dollars, five travellers capped at four, a request for Paris answered with all of Europe. None of that would show in a screenshot, and all of it would make a real person stop believing the results. Writing the notes list and the "I can't search Tokyo yet" reply took more thought than the visuals did.

Many of my bugs were one fact written in two places. I'd typed a date as Thursday when the 12th is a Friday, entered flight arrival times by hand that didn't match the flight duration, and written a vehicle name in eleven spots. So one flight record now drives every screen in the chauffeur flow, and arrival times in the AI flow are calculated. It's dull work, and it's what makes a prototype believable.

If I started again, I'd begin with the research. Desk research gave me a clear direction, but I'd want to replace my three personas with real people before drawing the second screen.

Related artifacts

This case study draws on the work below.

• Chauffeur prototypeClickable, with light and dark modes.
• AI search prototypeClickable, with light and dark modes.
• Product storyA scrolling walkthrough with both prototypes embedded.
• UX researchQuestions, competitors, personas, journeys and principles.
• Heuristic evaluationSeverity-rated findings and the roadmap.
• Chauffeur user flowEvery stage, decision and edge case.
• Chauffeur wireframesTwelve screens.
• AI search user flowEvery stage, decision and edge case.
• AI search wireframesTen screens.
• Design tokensColour, type, shape, light and dark, contrast.