Nowadays most Travel Apps look pretty much the same and have a very similar user-journey. It is no surprise though, why would you reinvent the wheel when something works. However, because something works does not mean it's perfect.
The main issue with most Travel Apps is their complexity. In order to give you Flight results, Hotels, Car rental deals (and more) the user must provide multiple information. City of departure, City of arrival, date of departure, date of return, amount of travelers ; these information are the bare minimum in order to perform a search. As a user this can be quite frustrating, so how do you make this interesting and fun to use?
As Tech-people we often tend to think that what is obvious to us is obvious to others. For us, UI components like "input fields", "radio buttons" or "sliders" are very basic elements, we perfectly know how it works and when to use them.
However, not everybody is a Developer, Designer or Product Manager and for most users those components are just abstract shapes. Words and sentences on the other hand are something that everybody can understand. This is why for this case study I decided to focus on the wording to drive interactions in order to give a more human feeling to the app.
If we dissect "traveling" to its fundamental it is nothing more than going from point A to point B. However, we live in a world where many options are available when it comes to travel.
For this case study I've decided to work exclusively with flights, trains and buses. Why?
Because I'm European and whenever I need to travel around Europe I always find myself considering those three options. They all have pros and cons but depending on the destination one option can often be better than another. The goal of this app is to present all relevant options to the users so they can easily compare and decide what's best for them.
Having a beautiful product makes no sense if nobody can use it properly. The first step of my case study started with the User Experience, building the user journey from start to finish.
The goal here is to create a funnel where the user provides all the necessary information in order to perform a search. However, rather than using simple input-fields, everything is turned into questions and answers with missing parts:
Where would you like to go?
"Round-trip" from "City name" to "City name".
This approach gives a very human and conversational feeling to the interface.
As soon as the user is done performing a search a second problem shows up, the results.
Let's say you need to travel from Paris to London and you are looking for a flight. I recommend you to do the test with any travel app and you will realise that the amount of flights for this trip is often more than one thousand.
Ending up with a gigantic list of a thousand results doesn't really make any sense as a user. For most users the priority is to get three key information:
This is why the very first results page of the app only shows you the flight, train and bus options. A very simple overview giving the user the possibility to compare the fastest, cheapest and most convenient way of traveling.
Making wireframes is one thing but making sure that the user flow works perfectly is another. And the best way of tesing it is to make an interactive prototype.
For this prototype I used the native Sketch Prototyping tool. The goal here is to test the user flow, not to create fancy and slick animations.
This case study wasn't necessarily focused on Design Systems but the truth is, I have a very hard time working without one. Plus, I wanted my Design to be as customizable as possible and this was the perfect opportunity to try something...
For this project I decided to create a Design System, but more than the speed and the consistency I wanted to try something new, customisable themes!
Starting a project from scratch without any existing brand guidelines is complex but also very fun mainly because of the Design exploration phase. However, this exploration phase can be very time consuming with a lot of back and forth testing different color combinations, typefaces and more.
In order to make this process as simple as possible I built the brand foundations in LESS, starting with the color palette, typography and spacings. The brand foundations are then linked to another LESS file containing all the styles for all components.
By using this technique I can simply create multiple brands all having different foundation styles, and simply by switching the brand file all the mocks automatically update magically.
Colors, components, layouts, etc ; when it comes to build the UI possibilities are endless.
However I made my mockups for an Android device, and following the Google Material Guidelines was essential.
I'm a fan of minimalism and cleanliness, and I tried to follow these principles in my Design. The large font-sizes, limited colors and limited amount of icons is an intentional Design choice. I decided to go for the essential, giving importance to the information and the content rather than trying to make "trendy" mockups full of icons and illustrations.
The UI Prototype presented above is extremely simple and made with Sketch native Prototyping tool. I'm currently working on a high fidelity prototype. Coming soon!