Whiteboard challenge

Flight Search: comparing by time at the destination

A flight comparison app for a traveler whose weekend is fixed and whose budget is limited.

FormatWhiteboard exercise

PlatformNative iOS and Android

DateOctober 2026

Three screens of the flight comparison app: the search form on iOS, and results sorted by time at the destination on iOS and Android

The prompt

Design an app or website for searching for flights or comparing options, taking into account one-way, round-trip and multi-stop trips, and baggage fees. The hard part named in the prompt is making a lot of data look simple.

Framing

I asked two questions before designing: is this for travelers or for airline staff, and is the traveler bound by time or by budget? With no answers given, I made three assumptions.

It is for travelers, and the business earns a commission on each booking.
The traveler is time-bound, because a long weekend cannot be moved.
Comparing is the more valuable half of the prompt. For this traveler, finding a flight and judging it are one problem.

A mobile app that helps leisure travelers with a fixed long weekend compare flights and pick the one that gives them the most time at their destination.

One user, one situation

A solo traveler in Toronto. On October 2 he realizes Thanksgiving is his last long weekend before Christmas, and he wants a beach trip to Cancún. He can be at the airport from 9 pm on Friday and needs to be home by 2 am on Tuesday, so he can rest before work.

First priority: the most time in Mexico.
Second priority: the whole trip under $1,000, with about $300 of it for the flight.
He travels with a carry-on only.
He plans in short gaps, at lunch and on his commute, which is why this is a phone app that saves his progress.

Pain points and priorities

He worries that something hidden will ruin the plan: a layover that eats half a day, or a bag fee that appears at checkout. Most flight apps also leave him to work out his time away from four clock times.

I chose to solve that uncertainty. Results are sorted by time at the destination, with price as the second sort. I deliberately left out a cheapest-first default, and I left out flight delays, because they happen after booking and the app cannot predict them.

The flow

Toronto, one traveler and round trip are defaults he never has to touch. He sets where, when, his flight budget and his bag. The count of matching flights updates as he moves the budget, then he compares, chooses, reviews and books.

The key screen

Every result shows the same facts in the same order, and the app does the math he would otherwise do himself.

Time in Cancún, written as days and hours. This is the largest element.
Total price, with the carry-on already included.
When he leaves and when he is home, as small supporting text.
Direct, or one stop and how long.
Airline.

A bar on each card shows flying time and time at the destination across his weekend, so options can be compared by eye. Picking two flights opens a side-by-side view that states the trade in one sentence.

Open the prototype

iOS and Android

The flow is the same on both platforms. The components follow each platform's own guidelines.

Element	iOS	Android
Title	Large title	Top app bar
Form	Grouped rows	Outlined fields with labels
Sort	Segmented control	Filter chips
Compare action	Bottom toolbar button	Floating action button
Compare screen	Sheet with Done	Full screen with a close icon

Edge cases

Nothing under his budget. When I checked, the cheapest fare on this route was about $338, above his $300. The app says so, shows the closest flight that keeps his times, and leaves his filters as he set them. I would test this against a plain "adjust your filters" message and let bookings decide.
The price changed while he was at work. When he comes back, the app shows what the price was and what it is now, up or down, and which flights are nearly full. Nothing is guaranteed until he has a confirmation.

How I would know it works

The share of time-bound travelers who book from the default sort without switching to price. Booking rate alone could rise because fares dropped that week.

What I would do differently

My first goal was "show the cheapest flight." Choosing one specific traveler changed it to time at the destination.
I first listed his constraints as pain points. A constraint is a limit he has. A pain point is what frustrates him while comparing.
Next I would test whether people trust the time number, then add hotel estimates so he sees the whole trip against his $1,000.

The prototype was built with Claude from my design decisions. Flights and prices in it are sample data.

All whiteboard challenges →