Travel, paid in points

Research objectives

Points are both the reason members come and the currency they pay with. So we focused the studies on the moments where points and travel decisions meet.

1. Can members find where they want to go? How destination search and auto-suggest behave with real, loosely-defined trips.
2. Do members understand what their points are worth? Where the balance appears, and how points and cash prices are read.
3. Can members decide how to pay? How they choose between points, cash and a mix, and where that choice should live in the flow.
4. Where does booking slow down? Friction in results, fare details and checkout, on mobile and desktop.

The answers set the priorities for 3.0: what to fix first in search, how to present points, and where the payment decision belongs.

Methodology

Key observations

What participants did, where it happened, and why it matters. Quotes and timings are from the study reports.

Findings by theme

Grouping the observations showed four problems. Each one separates what we saw from the need behind it and the opportunity it opened.

Evidence from the studies

Screens captured during the studies. Numbered markers point to the problem; the key below each image explains it.

123

1. The top match for “austr” is Green Bay, Wisconsin, matched on the airport name “Austin Straubel”.
2. Next come Austin, Texas, and four small UK airports, one of them a heliport.
3. Country names aren’t matched, so Sydney and Melbourne never appear.

1234

1. Reward options carry internal product names.
2. Members apply a reward to a number of tickets.
3. The points, cash and new balance sit in small type.
4. Other ways to pay are a stack of look-alike buttons.

1234

1. The balance is restated where the decision happens.
2. A field to redeem an exact number of points.
3. “Keep my points” states the cash price instead.
4. But the choice still lived on its own page.

Focus finding · Study 3

Members prefer to pick one flight at a time

ORXe 2.0 showed round trips as a single card: the departure and the return stacked together, priced as one. Study 3 tested this against a flight-by-flight view, where members choose the departing flight first and the return flight next. In the report’s words, testing “continued to validate that users expect and prefer to see flight options in a flight by flight view, rather than round trip.”

What we saw

In the round-trip view, two legs per card made each card taller, and participants perceived fewer results. The flight-by-flight view showed more results when the page loaded.

What the study recommended

Display flight results flight by flight by default.

Related signal

On mobile, 2 of 8 participants read a round-trip price as the price of one leg.

123

1. Sort is styled like a text field.
2. Filter is a small underlined link.
3. Both legs share one card; the price sits further down.

Why choosing each leg separately works better

• More choice. Members aren’t limited to the pairings the site pre-builds. They can match any departure with any return by time, airline, price or stops.
• One decision at a time. Each page answers one question, “which flight out?” and then “which flight back?”, instead of weighing two sets of times, stops and prices in one card.
• Cleaner comparison. Sort, filters and fares apply to a single leg, so options line up directly against each other. The cards are shorter, so more of them fit on the screen.
• Better-informed choices. Members can favour what matters most on each leg, such as an early departure or a cheaper, later return, and see what each choice costs as they go.

What outside research says

• Staged disclosure. Jakob Nielsen (Nielsen Norman Group) describes revealing a subset of options at each step, as wizards do, as a way of making interfaces “easier to learn and less error-prone”. Progressive Disclosure, NN/g, 2006
• The pattern members already know. Google Flights lists departing flights first and shows matching return flights once one is chosen, the same sequence ORXe 3.0 uses.
• The trade-off to design for. A 2019 pilot with 23 users (Zlokazova et al., INTERACT) found a two-page flow faster than a one-page one, but with more errors and a higher memory load, because people must remember the first choice. IFIP Digital Library

The research also flagged the trade-off: on a two-step flow, members have to remember their first choice. See how ORXe 3.0 handles it in the final designs →

Synthesis

Prioritised by the risk each problem posed to a completed booking. Only Study 2 rated severity; the rest of the order is our judgement.

1. 1

   If members can’t find the destination, nothing else matters

   Rated high risk in Study 2

   Root cause: text matching with no notion of airport size, popularity or country. Implication: fix search first; it’s the top of the funnel.

2. 2

   Points are the budget, so they must read as money everywhere

   Seen in Studies 1 and 3

   Root cause: the balance was treated as account information and prices didn’t state their scope. Implication: show balance, dollar value and a complete points-and-cash price on every screen.

3. 3

   The payment decision belongs inside the trip, not after it

   Seen in Study 1

   Root cause: payment was a separate step with product jargon. Implication: let members set points in the cart, with the cash balance updating live and a default of using their points.

4. 4

   Remove small frictions that add up over a long flow

   Seen in Study 3

   Root cause: weak labels, hidden controls and no saved data. Implication: flight-by-flight results, question-style labels, visible sort and filter, and saved travelers and cards.

From research to design

Each 3.0 decision, traced back to the evidence behind it.

123

1. The busiest airport for “San” ranks first.
2. Cities group their airports under “All Airports”.
3. Each airport sits beneath its city: code, name, city and country.

Not addressed in these screens: participants also asked for PayPal at checkout and for adding trips to a calendar. Neither appears in the 3.0 screens shown here.