TripAdvisor ux/ix

When planning and booking a trip, I will often resort to scouring the internet. Reading through various forums (reddit) and travel blogs, and finally searching through TripAdvisor.

In doing so I found that the app had a large variety of tools to aid my search and planning phase. These tools, however, held little cohesiveness between each other.

This brought me to the primary issue that my redesign sought to address: there was no comprehensive way to plan and book a trip start-to-finish.

the goal

The primary goal of this project was to design a unified trip planning experience. In particular there would be an emphasis on creating appropriate screens for the user to view their overall trip information, something not currently present in the app.

There would be some consideration of secondary/tertiary actions that users can make in the traditional TripAdvisor app, this is meant to be an exercise in rapid prototyping and arriving at possible solutions with minimal distractions. Granular details could be considered further down the pipeline.

Ultimately, I set out to create a design that would allow the user to flow from one part of the planning phase to the next with as few interruptions as possible.

All tools,

no Cohesion

To start with I identified the biggest few points within the app that would need to be connected together.

• Flights

• Hotels

• Events

• Things to do

• Restaurants

• Etc…

All of these processes work well individually. For example, the app will allow you to select the dates that you will be staying in a particular city and show you the available hotels in the area. From there, you can filter the hotels to your liking and finally make a booking.

However, what if you also want to schedule your flight as well? The app takes you to a separate screen altogether and does not retain permanence of information with regard to the dates you selected. Instead, you must reselect the same dates, check what’s available, and book the flight.

The data clearly exists, so why isn’t it being used together?

Regardless of which order you attempt to perform these operations the app will continue to forget these all-to-critical bits of information and force you to constantly reenter it. This was a particular friction point that the new design had to resolve.

Jumping into sketching

A key part of the design was to include the ability to interact with various elements on the screen. My designs worked to integrate high level information while retaining the option to refine and adjust certain aspects of the trip.

To this end, I opted to design the planning/booking process as a sort of continuous funnel with the end screen showing the most important details of the trip.

Quick, rapid sketches helped iterate design ideas and bring into focus several key questions:

• What data would the user prioritize when viewing their trip overview?

• How does the user expect to be able to interact with this data?

• How does the placement of certain items influence the usability of the interface?

• How closely to adhere to existing interaction trends? Experimental/niche vs. safe/known.

While these were questions that I would not be able to answer without performing actual user testing, they still helped me constrain the design of the sketches.

Going Digital

I knew that a mix of low- and high-fidelity mockups would be necessary in order to successfully explore design ideas. For this reason, I use Adobe XD as the tool of choice.

I started out with defining the design language by referencing colors and fonts from TripAdvisor’s brand guidelines. This was to provide cohesiveness in the overall design.

The next step was to create a mockup of the app as it currently exists. I did this to gain some familiarity with the design language that was being used, which afterwards I would expand upon to include the proposed new features.

Now that I was confident that I had the style of the app down to an acceptable level, I moved on to digitize the sketches I had made previously.

This was done in two steps.

First, I created the low fidelity concept. In this state I, or any other collaborator, could quickly edit and suggest sweeping changes that wouldn’t eat up too much design time. I find it important to have these intermediate steps to allow for any additional exploratory designs to find their way onto the board.

Then, I add detail and refinement to the rough sketches. This step helps bring a level of polish while retaining the flexibility of it being a mockup.

When planning out trips, dates and times become most important to users and therefore emphasis was placed on making sure that particular information was always present. With every design iteration I took a different approach with how to display the working dates of the planned trip. Additionally, I used image icons to provide a visual reminder of what the user had already planned for a particular day.

Finally, I took a further look at how the interaction with the calendar would work. With this concept, the idea was to lean heavily on the familiarity of existing calendar apps and build upon them using brand specific styling. Additionally, I added number enlargement when a user would press and hold a date on the calendar. This would allow the user to “see” which exact day they are selecting. This little popup would continue to be visible until the user stopped pressing.

Lessons Learned

• Having a cohesive design is important to maintaining user “flow.”

• Leverage existing functionality and allow for faster development times.

• Sticking to brand guidelines makes designing concepts faster. No fuss, straight to the point.

• Breaking the design down into more granular stages allows for designs to be adjusted and changed with minimal time and monetary cost.