Ironhack Challenge 3: Usability Evaluation and Site Redesign (TripAdvisor)

On the third Ironhack pre-work challenge we have been asked to carry out a Usability evaluation and Redesign study of a travel app, detecting its pain-points and suggesting alternative solutions for their design. Here I will show you my experience!

User type

The user type for this study is a young couple between 20 and 40 years old.

They are planning the trip for the early next summer. As they realized each one has enough money for the flight tickets and are planning to save money for the next months until it comes the date, so they can afford a comfortable trip and enjoy the staying without worrying too much about the expenses.

The trip destination had to be one of the 7 modern wonders of the world. I choose the Great Wall of China. It was a personal decision, as I love travelling to asian countries exploring their cultures, gastronomy and their living ways, I had China on the list already for too long, and I thought it was a good opportunity for knowing a bit more about the destination.
And such a cool experience would it be visiting the great wall!

Benchmarking

The travelling apps I evaluated for the exercise are Kayak, TripAdvisor and Hooper.

As you probably know, all of them have multiple functions such as booking flights, hotels, restaurants, tourist attractions… and evaluating the whole apps didn’t make sense as I was going to redesign only one of the tasks.

So I decided to evaluate the task of booking the accommodations, as booking the flights is something everyone has his/her way to do, and it won’t be a real scenario.
Booking the accommodation can be frustrating after checking the main sites you usually use to find out, and you can end up searching it anywhere you won’t expect.

So I first did the evaluation with the Kayak app. And it wasn’t intuitive at all, so slow charging the screens, it wasn’t easy to find what I was looking for. I had to restart the searching process from the home page a few times. So definitely not a good user experience.

Then I tested the Hooper app, and it worked pretty well. It was easy to understand, fast to find some options, the flow through the screens felt comfortable. Not finding exactly the options with the specifications I was looking for but probably Would have found the way with a few more minutes using it.

And checking Tripadvisor app, the experience was very similar to Hooper’s app. Fast and intuitive in the main track of the research. I felt a bit of a lack of information, which will probably be a wall on the way to book any accommodation. But the flow through the screens was easy.

I finally chose TripAdvisor as the app to test and redesign, as it is better known than Hooper by the users I was going to Test the app with. So it would be a more realistic context.

Testing

I did the test to 4 users, who were asked to find two different accommodations in the city of Beijing (Pekin) for the dates from 15 to 20 of June.

As they were gonna visit two different sections of the Great Wall of China, they will have to go two different days in different ways to see them.

They would stay 6 days/5 nights in Beijing. The first two nights (15–17 June) they will need to stay near the Jishuitan station, as it is the station where they will catch the early train to go to the Badaling section, 60 km from the city.
And the other three nights (18–20 June) they will stay close to the Dongzhimen station, from where it departs the train on the way to Mutianyu section. 90 km from the city.

While flowing through the app looking for accommodations I took notes about their comments, reactions, achievements and errors, and after it I interviewed them to know about their thoughts, problems and how they felt while using it.

Some problems I observed were:

• They had to go out of the app and enter google maps to locate where the area of the station was to search the accommodation.
• They had to rewrite the name of the stations every time they started from the home page, as the app didn’t keep it from the last search.
• Difficulties to find the filters, as they spent some time checking unaffordable accommodations.
• Trying to write the station name to have a reference on the map. But it didn’t allow any other than city names or accommodation names.
• Difficulties to find the “Search in this area” button, to move around the map and actualize the results.
• All of them ended up checking the accommodations on the map, so the list mode is just another step to find the map.

App observations from the users:

• They knew the platform from checking the google results of their searches for restaurants or activities. And one of them even did some posts of comments about restaurants when traveling, as the owners from restaurants ask for it. But they never used it to search anything through the web or app.
• They have a bad concept from the platform, as they think the opinions posted on any hotel or restaurant doesn’t have credibility because anyone can publish a comment even though you’ve never been in the hotel or eaten in the restaurant.
• It is not practical to book it through the platform as it redirects you to external websites.
• They don’t use it because it makes too many functions (booking flights, accommodation, tourist attractions, restaurants …). They think it won’t do any of them well.

Pain-points

Based on the user experiences notes collected, I “materialized” the main pain-points in the screens interface:

Redesign and prototypes

I first did a paper prototype to make sure about how it should work, how to make more visible the things that needed to be more visible and so on.

Once the flow was clear, I did the mid-fi prototype:

This would be the flow once the user specifies he/she is “searching accommodation”:

This would be the flow if the user doesn’t specify that he/she is looking for accommodation:

Redesign explanation:

what I’ve learned

It was surprising how expressive people can be when using the mobile phone, as if they would be interacting with another person.

This exercise was really challenging, to redesign a product which is already working.

Actually during the evaluation I couldn’t make things clear about what was working properly and what wasn’t. Even when I was struggling to achieve my goals using the app, I couldn’t find any obvious pain-point. And working with the interviewed users and observing them it felt so natural. When you realize each of them is repeating some of the same problems, and spends useless time at the same point… So illuminating.

And it feels very rewarding turning the first paper prototype into a mid-fi prototype, it lets see much more clearly the changes, and on the first instance if it could work or not. At that point I should see the following tests with user.

But the main conclusion I keep from this challenge is that it is much better to let the process flow naturally, than to focus on my own on what could be improved to fix it.

Thank you very much for reading, and it will be great hearing your comments!:D