Module 3 of Ironhack’s prework challenged me to redesign a travel app experience to optimize the experience for a specific demographic. I was presented with the choice of which app and which demographic of users to work with.
I chose to focus on a user profile described as Worldtrotter, Backpacker — 18–38 y/o.
Worldtrotter, Backpacker — 18–38 y/o
You’ve decided to finally go visit that wonder that has been sitting in your dreams for a long time now. Yo don’t have a long time to plan but also you don’t need it. You’ll be traveling in 6 months and are open to almost any possibility but have a budget constraint. You are price-cautious and prefer experiences where you have a chance to meet people and make acquaintances to enjoy the wonder together. You are not picky and you can accommodate the most affordable, adventurous, genuine experience.
I chose this simply because I know a number of folks in my personal network who match this description making the user research component of the challenge much simpler.
Next, it was time to choose an app for the experiment. I settled on Hopper because the app experience felt well suited for the Worldtrotter, Backpacker persona. Hopper’s flow is designed to take advantage of a traveler’s flexibility (a key trait of the Worldtrotter, Backpacker persona) to optimize for the cheapest travel fare possible. This includes a “watch” feature that is recommended to the user prior to booking their flight in the event that hopper’s analysis predicts a cheaper fare may be available in the future.
I conducted separate usability tests with four users to identify potential pain points within the Hopper user flow. The test that I designed took place in two parts:
- Look and Feel
- Task Completion
Look and Feel
For the Look and Feel portion of the test, I shared my screen with the user and allowed them to view the home page of the Hopper app for 5 seconds. Users were given no context about the application or the nature of the interview prior to sharing the screen (each user was told only that I wanted their perspective for a project I am working on prior to the call).
Here is what the user saw for 5 seconds:
After ending the screenshare, I asked each user two questions:
- What did you just see?
- What could you do with this tool?
Each user correctly identified hopper as a travel searching tool (one user was more specific and said “a flight searching” tool). Each user also offered essentially the same answer to question two: “search for and book a flight.” No users made any mention of the options available on the navbar located at the bottom of the screen. Such answers may have sounded like “manage future trips” or “watch/monitor flights”
For the second part of the test, I gave each user 3 tasks (presented one at a time) and asked them to “think out loud” as they completed them.
The three tasks I designed for the test were:
- Search for and select the cheapest round trip flight (at least 3 days apart) from (your local airport of choice) to Queen Alia International Airport (AMM) in the month of November 2020.
- Apply a filter such that no flights with layovers over 4 hours in length will return in the search.
- Add the flight selected in step 2 flight to the watch list.
I noticed two takeaway points while working with these users:
- Each user’s first impression of the color-coded price indicating chips located at the top of the travel date selection screen was that they were tappable price filters. When searching for the cheapest flight (task 2) each user's first attempt was to tap the green chip labeled “$675+”.
- All users found the “add to waitlist screen” confusing. 50% did not realize there were additional steps to take before a flight was selected.
With the result of the test in, I decided to narrow the scope of my redesign to address only the first pain point for a couple of reasons:
- Users clearly expected more from those chips.
- It’s aligned to the value add of the product: finding cheap flights.
- It seemed like low hanging fruit.
My initial thought for this solution went something like this:
- User taps filter chip
- Only dates corresponding to the price criteria of the chip are displayed in the date selector.
It seemed too easy…because it was. As soon as I started putting together lo-fi mockups on paper I realized how weird it looked to see a calendar with a bunch of days just…missing. I thought of the potential errors users could make — like weeks-long trips booked by mistake when they really just wanted a three-day getaway. And then there was the matter of how to even display information like what day of the week these dates fell on without having a bunch of unnecessary white space.
It was clear this wouldn’t work, so I scrapped that idea and zoomed back out. This time I decided that instead of removing dates that don’t match the selected filter, I would simply grey them out. This would be a minor change compared to the current display, but it does “quiet” the experience down a bit — and maybe that’s enough to help the user find the flight they are looking for.
Without conducting another round of testing. It’s hard to say whether this would really make much of a difference. But that’s the point of prototyping — you don’t know if you’ve got a good idea until you test it out.