Booking Engine (mobile)
[ app redesign - case ]
UI/UX - Frontend development
Project presentation / SETUP
A few years ago, I was working at a software company which developed a booking engine for
hotels. Let me reformulate, a big-non-sexy booking engine!
At the time we all knew that we need to improve the mobile booking engine, but no one was brave
enough to start digging into it. We knew that was really difficult to use it, even for us. The buttons
were too small, the arrows impossible to rich, was really difficult to click on only one thing per time,
the forms…well, we just knew that we needed to make something about it.
Inspired by the image below, which compares the 2007 booking.com’s booking engine with the 2017
version, I started to see this project as an opportunity.
In this article What Booking.com can Teach us About A/B Testing Strategy (not the newest one but I really
recommend) you can see the results of designing based on an iterative testing approach (small tweaks)
and “getting the most of their current design”. This article kind of gave me an idea of how I could approach
this re-design project, because, let’s face it, we really didn’t know how to start and UX wasn’t a trend
like nowadays.
Challenge / CONFLIT
The challenge was simple: improve this booking engine.
Based on the above mentioned article we just defined 3 rules at the beginning:
1. This booking engine has to work after we touch it (the most important one 😬);
2. We will not change the visual or not in an extreme/innovative
way like any designer would love to;
3. The goal is: improve usability.
SOLUTION / RESULT
First things first. We needed to figure out what was wrong, what were the main issues with the process of
booking a room on mobile devices. After following several real user testing approaches, we translated the
tests into 5 conclusions:
1. Users felt lost navigating on the first screen. So we decided to remove
all unnecessary information as flags and a tab for location;
2. Some of the users got frustrated because the “not available” dates
were not properly identified. So we added a pink(~ish) background and replaced
the price with “not available”;
3. During the process, users reported wondering why they were using
this booking engine instead of, e.g. booking.com. In order to counteract this
dubiety we added a tag reinforcing the motivation to book directly, “Best rate guaranteed”;
4. The exercise with children involved was really difficult for everyone
because there wasn’t information about how to add kids to the reservation on
the first screen. Contrary to the proposal to simplify in point 1, we have added an
option to select the number of children;
5. Depending on the weekday you were, booking to the next weekend
wasn’t available on the Quick Book tab which made no sense to users.
Our solution was to increase the number of days available for Quick book.
I can say that the real test was the most important input for this project. After that, we had data to understand
our customer journeys and to run some A/B testing: tag placement, number of days available to quick book,
colors, button sizes, tab sizes…
And here it goes the result. Re-designed based on an iterative testing approach and “getting the most of
their current design”.
This non-sexy booking engine turned into a really cool project that allowed us to learn about:
Data analysis, How to run a real test, Customer journeys, A/B testing...
Right, it’s not a full UX course. Most of the time we didn’t even know if we were doing the right
thing, but we’ve tried, we improved the product and ourselves as designers and the results were great:
