Case study - Product design

Kiu Flight e-commerce

Redesigning an airline booking flow so travelers can find, compare and pick flights with confidence.

Role
Product Designer
Year
2023
Industry
Airlines - B2B software
Scope
Search, results and checkout
Redesigned Kiu flight booking screens on desktop
The result, up front

A booking flow people actually finish

+15%

Booking flow completion rate after launch

Fewer support requests

About flight selection after the redesign shipped.

Higher click-through

On key elements like the “Continue” button and stopover filters.

Final design - Search results
Final search results page with fare cards, filters and a sticky Continue bar
Setting the scene

An outdated flow was costing bookings

Kiu sells B2B software that powers booking, check-in and ticket purchase for airlines. Its booking experience looked outdated, wasn’t responsive, and parts of the flow were confusing. Travelers said so in app store reviews, and analytics showed critical drop-off points right where they had to choose a flight.

What I saw

  • Unclear visual hierarchy and a dated UI
  • No responsive behavior on mobile
  • Critical drop-off in the booking flow
  • Negative reviews about a confusing experience

My role

Product Designer, end to end: research, UX and UI design, usability testing, dev handoff and QA after launch.

The team

I worked with Kiu’s developers through handoff and with QA to compare the live product against the specs.

The constraint

Technical limits ruled out deep structural changes, so the information architecture and the core flow had to stay.

Key stages

Five calls that shaped the redesign

Not every wireframe, just the turning points: what I decided, why, and the trade-off I accepted.

Key decision 01

Redesign the whole flow, starting where it broke

The call

Redesign the full booking flow, from search to confirmation, and start with Search and Results, where the problems were biggest.

Why

Analytics showed the sharpest drop-off and the highest cognitive load in flight selection. Fixing it first set the patterns every later step reused.

Trade-off

Technical limits kept the information architecture in place, so I improved every step within the existing structure instead of reordering it.

Before · Results
Original results page with dense rows and unlabeled icons
After · Results
Redesigned results page with clear hierarchy for schedule, airline and price
Key decision 02

Let travelers pick outbound and return on their own

The call

Split flight selection into an outbound step and a return step, each with its own clear control.

Why

Legs couldn’t be combined freely, which broke user control and freedom. Rigid selection was a recurring complaint.

Trade-off

One more step in the flow. In exchange, each decision is smaller and the chosen outbound stays summarized on top.

Step 1 · Outbound
Outbound flight selection step
Step 2 · Return
Return flight selection step with the chosen outbound summarized on top
Key decision 03

Cut the icon noise and let the key data lead

The call

Group side icons by category (services, meals, seats, Wi-Fi) with tooltips, and give schedule, airline and price the strongest type.

Why

Rows of unlabeled icons created ambiguity, and flat type sizes made every detail compete for attention.

Trade-off

Secondary details moved behind tooltips and expandable fare cards: one tap away instead of always visible.

Before · Filter
Original filter and flight row with ungrouped icons
After · Filter
Redesigned filters grouped by category with tooltips
Key decision 04 · Turning point

Testing showed selection didn’t feel selected

I ran a remote usability test with 6 participants with basic or intermediate experience buying flights online. Most completed the flow, but two issues stood out.

40%

couldn’t clearly tell which flight they had selected: only a small radio button marked it.

20%

had trouble finding the “Continue” button.

“Did I already select it? I’m not sure if this is the one I picked.”
Usability test participant
What I changed in round 2

Clear selection feedback

Redesigned radio buttons and an outline around the selected flight card, so the choice is obvious at a glance.

Sticky “Continue” bar

A colored bar with a larger button keeps the main action and the running total always in view.

Trade-off

The sticky bar takes permanent space on screen. I kept it compact: price, selection summary and one button.

Selected flight card with an outline and the sticky Continue bar showing the total
Key decision 05

Carry the same patterns through checkout

The call

Reuse the stepper, cards and trip summary from passengers to confirmation, built on one component library.

Why

Visual consistency across the whole flow was a design goal, and one set of components gave developers one set of specs.

Trade-off

Guest checkout is the default and login is optional: less account data up front, one less reason to drop.

03 Passengers
Passengers step with guest checkout and trip summary
04 Extras
Extras step showing included services and optional add-ons
05 Payment
Payment step with installments and the total on the pay button
06 Confirmation
Confirmation page with the booking code front and center

Also designed: edge states for a declined payment, a price change and an expired fare hold.

Outcome

What changed after launch

+15%

Booking flow completion rate

Tracked after launch as part of post release monitoring.

Fewer support requests

About flight selection.

Higher click-through

On key elements like the “Continue” button and stopover filters.

Learnings & next steps

What I’d keep, and what comes next

Learnings

Constraints sharpen priorities

Not being able to rebuild the structure forced me to fix the pages with the most impact first.

Feedback has to be felt

A radio button was “correct”, but 40% of testers still doubted their choice. Selection needs a visible state change.

Six people are enough to find big issues

A small remote test surfaced the two issues I fixed in round 2.

Next steps

Design for mobile

Design mobile versions of flight selection, passengers and payment, so the new flow works as well on a phone as on desktop.

Test the fare families

Validate Basic, Classic and Flex with a clickable prototype: do travelers understand what each fare includes?

Revisit the architecture

Once technical limits allow, tackle the structural issues that this phase had to leave out.