Flight Search: Stating the Problems

by Marty Alchin on January 1, 2010

One advantage of working with Django is getting to know a lot of really talented designers who love to throw out tidbits of their knowledge. Recently, one such tidbit reminded me of something I knew, but hadn’t abided by for a while: “the last thing you should do when beginning to design an interactive system is write code.” This got me thinking about my own flight search project, and how I should probably design the interactions as behaviors before trying to code them. Then I realized that even that was too specific to be useful at this point. First, I need to formally state the problem I’m trying to solve.

I’ve never really sat down and identified exactly what’s wrong with the current state of affairs. I see room for improvement, but if I just go in without formally defining the issues, I’ll know way to know how well I’ve done at addressing them. Perhaps more importantly, I need to know whether any new issues I introduce outweigh the ones I was trying to solve. As I had been working on this a bit already, I’ve identified problems in a number of areas that I’d to address.

Search Results

When I started out, my big problem with flight searches was the presentation of the results. They generally look like massive walls of text to me, with no good way to compare one flight to another. I like being able to get a good understanding of content at a glance wherever possible, and I have a lot of trouble with that in flight search results.

In order to comprehend a flight, I need to look at the airline, departure time, arrival time, number of stops, length of layovers and, of course, price. That’s six different variables, most of which (all but the airline, which typically uses a logo) are presented in plain text, which has to be read and remembered. Comparing to another flight means going through that all again, then computing the difference between the two in my head; the design does nothing to help. As you consider more flights, the problems just keep getting worse.

It tends to get worse still when you realize that most flight search result pages uave 10 to 20 flights on a page, which requires scrolling to see them all, so you can’t easily refer back to other flights to jog your memory. Add in multiple pages for possibly hundreds of flights and it gets really bad, really quickly.

Search Form

The start of the process begins with a search form, allowing you to decide where you want to go, and when. There’s probably nothing wrong with the existing forms, especially given that the industry seems to have settled on a fairly common format. Still, “good enough” nearly always means there’s room for improvement, and in this case, I’ve always been frustrated by the date pickers used on these sites. It’s probably just me, but it always seemed like overkill for travel searches, so I’d like to look into options that might be more suitable.

There are many options on the search form that I won’t be looking into, though, to keep the scope small. For example, most forms offer searches for flights, hotels, rental cars and various combinations of these. I’m only focusing on flights. Likewise, there are some flight-related options I’m ignoring as well, such as the number of travelers and the seating type. Those features certainly affect which results are displayed, but they don’t have much impact on the overall experience, so I’m ignoring them.


Personally, I can’t stand that flight searches make a distinction between one-way, round-trip and multi-stop itineraries, right at the outset of the search. I expect it’s due to trying to optimize the search at the outset, to minimize how many individual searches need to be performed. As such, I can understand why it’s commonly done this way, but it makes for a terribly inconvenient user experience.

This is one area where I plan to try out an alternative that might not make sense in the real world. For the purposes of this experiment, though, I’m going to assume that the technological problems inherent with the current search system can be ironed out on their own, such that an improved experience can be had. Maybe I’m too optimistic about the underlying technology, but experiments like this are all about optimism, aren’t they?


This post is purposefully void of any of my plans for solving any of these problems. I merely wanted to present a baseline for future comparison as I go along. Over the next few weeks, I’ll write some posts about my ideas for solving some of these problems. Hopefully, I’ll even be able to show some working interfaces to demonstrate the techniques I’m working on.