Designing the First generation of Travel Booking - Flights booking & Bus Booking
Building the platform's first travel products and the spine every travel category after it would stand on.
Role
Product Design & product owner
Team
Me (lead) · 1 junior designer
Timeline
4 months
Context
The Reward Store's "Redeem Stack" platform is our end-user-facing platform, used by employees, consumer loyalty program participants, and anyone using us as a burn partner. When I was tasked with designing the Flight Booking module, I set out to create the backbone for flight booking and for all the travel booking that would follow (later joined by Bus Booking).
The Situation
New capability, new system: After years of managing products like gift cards, subscription vouchers, offer codes, recharges, and bill payments, the team had grown comfortable with a familiar flow that worked across categories.
Journey Pilot & Bus Booking: Journey Pilot and bus booking were already in the pipeline, creating an opportunity to build a cohesive, reusable system that could leverage our existing data and infrastructure while moving towards a connected employee ecosystem.
Understanding a Longer Journey :Before designing a single screen, I had to get a clearer direction.
Solves the engineering problem
I studied how established travel platforms handled this complexity comparing competitor platforms and leading flight-booking experiences through a comparative usability study, to learn what worked, where users struggled, and which patterns we could improve on.
The study: 6 participants across 3 levels of flight-booking experience.
2 first-time travellers — had never booked a flight before.
3 regular travellers — typically booked 2–6 flights per year.
1 frequent booker — a CEO’s executive assistant who booked flights on a weekly basis.
What We Found
—
First-time travellers drowned in competing text — unsure what mattered, what to skip, what to do next.
—
Occasional travellers coped only by guessing and skipping. They got through, but not because it was clear.
—
Multi-passenger bookers couldn't tell which seat or meal belonged to whom — even experienced users lost 2+ minutes across three leading platforms we tested.
—
Frequent bookers told us consumer platforms keep seat choice flexible, editable later at check-in.
The real problem wasn't length — it was clarity.
Overload over clarity — the journey never signalled what mattered, so users guessed.
No sense of ownership — selections weren't tied to a person; 2+ minutes lost, even for experienced travellers.
Search, results, points checkout & confirmation
Replace this frame’s fill with your screenshot
THE CHALLENGE
The Reward Store's existing flows — bill payments, gift cards, subscriptions, recharges — were relatively short and ended with an order history. Travel was different: a much longer, more complex journey, with multiple steps, passengers, seats, meals, and baggage to manage.
So the goal became clear: strip the noise, and make every choice belong to someone.
(Alongside the design, I also worked across the API analysis, vendor coordination, and the commercial model — but the heart of this project was making a genuinely complex journey feel effortless.)
01 ·
A three-step flow that only shows what’s relevant
Answers: overload
First-time travellers drowned because everything competed for attention at once. So instead of one dense screen, I broke booking into three steps that appear only when they have something to offer — if a step has no options for that trip, the user never sees it.
HOW THE FLOW WORKS
[Walk through the flow here: what the user sees at each step, what triggers a step to appear or stay hidden, and how the summary carries every choice into payment.]
Step 1 · Passengers & preferences
Travellers, their details, and each passenger’s seat and meal — owned by the person they belong to.
Step 2 · Add-ons
Insurance, extra baggage, and cab service — surfaced only when available for the route.
Step 3 · Review & pay
A clear summary of every choice and the final points total, so users confirm with confidence.
By hiding empty steps and revealing options only when they exist, the journey stopped feeling long — it felt right-sized to each trip. Complexity was there when it mattered, invisible when it didn’t.
02 ·
Add Passenger — enter a traveller once, reuse them everywhere
Reduces repeat effort
When a user adds a passenger, their details are saved as a reusable profile — so on the next booking they're one tap away instead of a form to refill. The same profile carries across any travel booking (and into Journey Pilot, our trip-management tool), so the data compounds instead of being re-entered. If a profile is missing information, the system flags it at the point it's needed, so users fill just the gap — not the whole form again.
HOW THE FLOW WORKS
[Walk through the flow here: what the user sees at each step, what triggers a step to appear or stay hidden, and how the summary carries every choice into payment.]
03 ·
Add Preference — every choice belongs to a passenger
Answers: no sense of ownership
Research was clear — seats and meals floated free of the people they belonged to, so even experienced users lost track of whose was whose. So I stopped treating them as add-ons the system tracked, and treated them as preferences owned by the passenger. The moment a passenger is added, their preference module opens automatically — their seat, their meal, nested under their name. Every choice is anchored to a person, so there's never a question of whose is whose.
One research signal shaped this: frequent bookers wanted seat choice to stay flexible — so preferences live with the passenger and stay editable, never locked in upfront.
HOW THE FLOW WORKS
[Walk through the flow here: what the user sees at each step, what triggers a step to appear or stay hidden, and how the summary carries every choice into payment.]
Bus booking followed flight booking
Flights shipped as the foundation, not the finish line. Bus Booking was planned as the reuse — and later shipped on this exact system, proving the design held up.