It was early 2016, and I was sitting at my desk in Melbourne’s Inspire9 co-working space in a corner that Rome2rio peacefully occupies. In front of me were printed out screenshots of the existing Rome2rio flight booking user interface. We all knew that the user experience needed work, what we didn’t know is what direction we needed to go in to fix it. On top of that, concept-to-development would have to be fast to keep with the Rome2rio ethos of experimenting in the wild rather than in the lab. This process was going to be a challenge … here’s what we did.
The travel industry is huge. In 2015 alone it generated $341 billion dollars in the US. I was sure that all the top companies had A/B tested their booking flows to the limit — it was time to do some research. I collected screenshots from some of the leading travel websites and printed them out. These would be my reference; something to continuously look back on throughout the entire process, something to benchmark my ideas. I laid out the printed screenshots, organised a meeting with the rest of the front-end team and so it began.
Flight tickets — the similarities and the differences
Step 1 was isolating the tickets used on eight big name flight booking sites and attempting to find similarities and differences.
Six of the eight tickets contained summary columns on the right-hand side; each ticket contained a button with either a green button or a button in the brands colour. I was onto something! Green buttons can’t just be a coincidence, especially when nothing else on the page, or in the brand, is the same green.
Another feature of the summary columns was per ticket prices. The search on all sites was for three adult passengers yet only GoEuro displayed the price for the entire order, all the other sites displayed the per ticket price. If users were going to be comparing Rome2rio’s ticket prices to other flight search websites, we were going to need to display tickets in the same per-passenger format.
Outbound and return journeys are presented as rows, the exception being Webjet who presented the data in columns. This layout would make it easy to present one-way and return tickets using the same design without creating awkward white space. However, it is easier to scan a large list of tickets if the journeys are presented in column format so this was a real estate vs. convenience challenge; one which we may re-visit in the future.
Another similarity we found was the use of +1/+2 to represent international dateline changes. This is common in long distance flights that span timezones. We’ve talked about other ways we could present users the date of their arrival if it’s different to their date of departure. However, this research seemed to reinforce a standard, one that we’d be brave to deviate away from.
It’s all in the details
Another thing I quickly noticed is that what was presented on the ticket result wasn’t the full story. All but Webjet and GoEuro used the term ‘details’ in their call to action to view more information about the ticket. The wording and methods of progressive disclosure were consistent across the sites. The call to action was always located at the bottom edge of the ticket result and mainly towards left side — as far away from the main call to action as possible. I wonder why? In 100 Things Every Designer Needs to Know about People, Susan M. Weinschenk suggests that progressive disclosure provides people with the information that they need only at that particular time.
Armed with detailed knowledge about what users expect from a ticket I designed and built a concept for the Rome2rio ticket. After about a week I came up with a candidate to test in the wild.
Our split testing method
As a rule at Rome2rio, we split test all features and improvements. Some of the benefits to split testing everything are:
- Gives us a deep understanding of just how much impact a change we make has.
- Allows us to quickly turn off new features/improvements if something went wrong.
- Forces us to develop code that’s decoupled, more flexible, and better designed.
We ran the experiment at 20% English Language, desktop users. It was a fairly small sample size of our entire user base. However, it was big enough to get us accurate results while still insuring us against the possibility of failure.
So the results?
Users were 61.5% more likely to make it through the booking process with the new flow.
Admittedly this was an easy win project as the old design was in serious need of an upgrade however it’s incredibly rare to get this kind of increase overnight on a high-value part of the product. We graduated the experiment to 100%, ported the design to desktop, removed the legacy code and eventually submitted the new strings for translation.
The journey has just started
Conducting this research and experiment process wasn’t about an end goal, it was about creating a solid, well-researched foundation for future experimentation. I’ll soon be posting some more articles about future enhancements we’ve since made and the results they’ve had to our booking counts. Until then feel free to check out the work we’ve done and make any suggestions on how we can improve the flight search experience!