Redesigning the TripAdvisor app
Or, it’s not called a mantra for nothing.
So far, my two main mantras while working on the Ironhack UX/UI Design Pre-Work have been pretty simple: “I’m not the user of the product I’m creating and evaluating” and “Done is better than perfect”. The first one something that Ironhack is teaching me, and the second something I have been trying to teach myself and have only been getting slightly better at over the years (baby steps). When I got to the third challenge of the Pre-Work I was pretty confident I could handle this, but, it turns out: I was getting cocky. I have a sneaking suspicion that this is going to be a recurring thing once the actual bootcamp starts, so let’s analyse what happened.
The challenge
As an avid traveller I was really excited about this third challenge: evaluating and redesigning travel apps. How exciting is this! I get to work on something I use a lot myself too! I went into it thinking this was going to be easy and fun, ’cause I already had lots of ideas about how to improve these travel apps. But, it turns out, this actually made it really difficult to come up with a neutral app evaluation. In the module it is repeatedly stated that you have to keep the mantra “I’m not the user of the product I’m creating and evaluating” in mind, and this was definitely a challenge for this particular assignment. Turns out it’s really difficult to turn yourself off. Not a terribly surprising insight, but I found it very useful to be confronted with this predicament again, as I think it’s one of the most important skills to have in UX/UI: being able to forget yourself and focus on the user. So definitely something I need — and want — to practice more!
The assignment was to evaluate and redesign a travel app. The first step was usability research, first by using Nielsen’s heuristic principles and then user testing. The second step was to redesign the app, based on the research findings. Four travel apps were suggested in the module: Kayak, Skyscanner, TripAdvisor and Hopper, and we had to choose one. Then, we had to select a specific target group and destination, and develop a task for our users to do to test the app.
First I chose my target group. I quickly decided to go with the Backpacker type, as most of my friends would fit into this category. It therefore seemed the easiest way to find enough people on short notice to do my testing. I fit into this category myself as well, and at this point I was also still thinking it would be fun to do user research on something close to my heart, so it seemed a logical choice. I then decided, by the same logic, to develop a task based on a destination close to my heart: China.
Choosing which app to evaluate and redesign
The next step was choosing which app to use for my redesign. I compared the four apps by looking at Nielsen’s heuristic principles. The results of my comparison can be seen below:
I think all apps did pretty well on the comparison and it was hard to choose an app based solely on these findings. With regards to the Kayak app there seemed very little to complain about in terms of design principles, according to my comparison, so I quickly decided that one was not going to be a lot of fun to redesign. Following this logic, the Hopper app seemed to be the logical choice for my redesign (most red boxes), but in the end I decided I would go for TripAdvisor, as it suited my chosen user group the most. TripAdvisor offers the possibility to compare and book excursions and has user reviews (so a lot of information on how people experienced their trip), so it seemed like the app my target group would be most likely to use.
User research
Figuring out the task was one of the hardest things in this assignment. I had a lot of ideas in my head about how to improve the TripAdvisor app, so I kept coming up with tasks that would lead my users to the pain points I had experienced myself already. This is obviously not the point of user research. Again, I am not the user of the product I’m evaluating or designing. The point of user research is to let the users of the app speak for themselves and use those insights to redesign the app, not to change the app in a way that’s more suitable just for me. It was quite the struggle to get around my own preconceptions regarding the app, and in this respect it was good that I decided to do it this way, as it was useful to be confronted with this issue. Useful, but frustrating.
In the end I decided to focus on the characteristics of my target group to develop my task. My target group is price conscious and mainly wants to have cool experiences and meet other travellers. So I developed my task in a way that price would play a role (it has a budget) and they would focus on experiences and meeting other travellers (it includes booking excursions).
The task I developed for my users to do was the following:
- Find a flight and hotel in Beijing, China, for September 21st — 25th. Your budget is 800 euros.
- Find three things to do, one of which is a trip to the Great Wall. Your budget for all three excursions is 100 euros.
User interviews
So, finally having gotten myself to the actual user testing stage I asked each of my testers to do the 5 second test, and then perform the task I set them.
During the task I watched what they were doing in the app and I asked them to tell me out loud why they were taking certain steps and what they thought of every step along the way. From my user interviews I found out the main pain points are the following:
- No possibility to book flight & hotel together;
- No possibly to save recommendations for flights, though it is possible to save hotel recommendations;
- Not clear what hotel prices include (one night, all nights, one person, more people?);
- Not enough filter options for search results in “Things to do” section;
- The system status was not always immediately clear;
- Unclear which site you would be forwarded to once you choose a recommended flight or hotel;
- Most of my users were surprised that you couldn’t book directly on TripAdvisor, but that you were forwarded to another site for the actual booking;
- Not enough information in the “Things to do” section, so you’d always need to do more research to find out if things are worth doing;
- No possibility to filter reviews under “Things to do” section, so difficult to quickly decide on the trustworthiness of the trip organizer.
Narrowing it down
Some of the pain points mentioned above would require a major overhaul of the design and structure of the app, and some would only require a small change in the interface. Even though these changes are relatively small, they would greatly improve the experience users have using the TripAdvisor app. I decided to focus on the pain points that would be relatively easy to solve, and chose the following improvements for my redesign:
- Make system status more obvious in search;
- Save recommendations for flights;
- Make hotel prices more clear.
This led to the following wireframes:
The online version of my mid-fi wireframes can be found here.
In the lo-fi wireframe my suggested changes are circled with pink marker.
The ongoing search screen
In the search screen it took all of my testers a while to see the narrow yellow bar in the original app, even though it’s actually moving. This bar indicates that the app is still searching for flights. It’s important to make system status very clear, because my testers were getting impatient they couldn’t click on any flights and didn’t immediately see the search was still ongoing. They would also be quite shocked by the prices of flights, not realising cheaper ones might still pop up. In order to fix this I’ve added an airplane icon to the search bar, which makes system status more eye-catching and therefore more obvious. While the search is ongoing, the airplane will move from left to right. It will disappear once the search is completed.
The search results screen
The second problem I worked on is not being able to save flights. The TripAdvisor app has the option to add hotels and excursions to a “Trips” page, where you can save them to look at later. This makes it easy to narrow down possible hotels and excursions, and then compare them later, also keeping an eye on the total budget. Oddly enough, it’s not possible to add flights to this. In order to fix this, I’ve added heart icons to the suggested flights, which will appear once the search is completed. The heart icon is also used to save hotel and excursions, so users will recognise it from elsewhere in the app. Pressing the heart will save the flight to the “Trips” page, which can be accessed through the footer menu.
Hotel details screen
The last change I made was on the hotel details screen. Once you’ve chosen one of the suggested hotels you can click on the name and you will be taken to a page with hotel details. The price is mentioned as well, but it won’t say what the price includes. It is not clear if this price is for one person, for one night, for all the people in the reservation, per room? It’s just a number, no further explanation. All of my testers ran into this issue, having to click on to the booking screen before getting the price details, and then back to the hotel detail screen, and search results, in order to be able to compare hotels. This is a lot of unnecessary clicking back and forth. In order to fix this issue I added the information to the hotel details screen, so users don’t need to click on the “View Deal” button and get taken to the booking site before they get all the details.
What did I learn?
In hindsight it’s easy to see where things went off-track. I spent way too much time mulling over the preparation of my interviews. I thought it would be easy to pick a target group and task that were close to me, but it took me quite a while to realize that I only made it harder for myself to do a well-thought out, neutral study of the needs of the app users. It was difficult to get away from my own opinions and really listen to my users. So I needed a lot of time to come up with a task that was neutral enough to be able to get some good results from my user research.
I also focused too much on doing the user research in real life. I figured if I interviewed people in real life, I would be able to see what they were doing on the app. But I didn’t realize until my second interview (which was with someone outside my household) that I couldn’t get close enough to really properly see what they were doing. Damn you, corona. And by then, I had done two interviews and didn’t want to change tactics midway. Plus I had already spent a considerable amount of time on this challenge when I got to this point, so I wanted it done. Done is better than perfect, right?
So basically, in trying to make it easier for myself, I ended up making it much harder, and I wasted a lot of time. A tough lesson, but a good one! In the future I will consider my choices a bit more thoroughly before choosing a path down the rabbit hole. And I will look into online options for user testing, ’cause I have a feeling that might come in handy in the next couple of months…