Search flow optimizations
Wanderu is a Boston based travel startup focused on empowering users to easily compare, book, and save on bus and train tickets throughout North America and Europe. Between the apps and the website, Wanderu has millions of active users.
Background
At Wanderu, one of our biggest challenges has been keeping our inventory fresh. Wanderu integrates with over a thousand partners who frequently alter their ticket prices based on a number of factors. Keeping our inventory fresh requires having up to date and accurate pricing data for our trips. We do as much as we can to maintain the data, but part of this challenge falls on the partner’s side as well. Many of their tech stacks cannot handle the amount of scrapes it would require to maintain a completely fresh inventory.
Wanderu has solved this problem by doing a number of things. The first is nightly scrapes of our partners data. The second is when a user selects a trip, we then scrape the partner for that individual trip once more to make sure the price is still up to date. We refer to this call as a “livecheck”.
Traditionally, livecheck has occurred on the trip summary page - the intermediary screen between search results and checkout. There are four main case scenarios for the user at this step. The first case is there is no price change. The second case is when the price goes up. The third case is when the price goes down. The fourth and final case is when a user encounters an error with livecheck. This is the least common but most catastrophic error.
Empathizing with the user
After running usability tests of our search funnel it was evident that this step caused the most friction with our users. The most frustrating aspect from the users perspective was they didn’t understand why the price at trip summary changed from the search results step before. Many users referred to it as a “bait and switch”. To add insult to injury, users would then have to go back to the search results page where it was possible that they would run into the same scenario again.
Defining the problem
Solving this problem required looking at it from two angles. There was the aspect of communicating what was occurring to the user, and there was the aspect of alleviating the frustration once the price changed.
Initially we communicated this message on the trip summary page. While the trip was being livechecked, the message would read “Checking for the lowest available price”. Once the livecheck finished, the price up or price down message would then take its place. There were a couple things wrong with this. First, the message would only appear as long as the livecheck was occurring. Oftentimes this would only appear for a fraction of a second, and on top of that, the trip summary page was fairly cluttered. This was causing cognitive load on the users which made it easy to miss the messaging.
Ideation
The solution I proposed was to move livecheck up one step in the funnel to the search screen. When users selected a trip, a modal would appear and the trip would then be livechecked. The modal made it obvious that an action on the backend was occurring as well as set expectations that the price could change. In addition, it briefly gave the user an explanation of why the price could go up. Based on the number of words displayed in the message and the average reading duration of a person, we determined the message should be shown for a minimum of 3 seconds. This was done to prevent the message from only being displayed for a fraction of a second and ensuring that users could understand what was happening.
Once the 3 seconds was over and the livecheck completed, there were a few pathways the user could experience. If the price remained the same, the user would be taken to the trip summary page. If the price went up users would see messaging explaining why the price changed. They would also be given the option to proceed with the trip, or to keep searching on the search results page. If the price went down, the user would be taken to the trip summary page with a congratulatory message. If an error occurred, the user would be shown a message and prompted to keep searching on the search results page.
A major theme of this proposal is being more thoughtful when we push users forward in the funnel. When the price stays the same or the price goes down, it is highly likely the user will proceed to the next step. Inversely, when there is an error or a price up, users are less likely to proceed. User’s who encounter errors or price increases are most likely going to return back to search results, so why even take them off search results in the first place?
Prototyping & testing
We developed figma prototypes for the new user experience as well as built prototypes of our original experience. We then used these prototypes to run a number of usability tests. We tested the new version versus the original. We ran mobile and desktop variants of the test as well as tests which displayed the original version first and tests that displayed the new version first. The results were nearly unanimous. Users found the new experience significantly less frustrating and had a better understanding on why the price changed.
Now that we had qualitative data, the next phase was to gather quantitative data to back up the results from the usability tests. In order to do this, we ran a split test on the site for two weeks. The results further reinforced the data we found from our initial findings. The new experience saw a 9% increase in conversion rate as well as some other unexpected benefits. In addition to the conversion rate increase, we saw a significant improvement in the freshness of our trips. After doing some investigation we found that users were livechecking more trips on average which then improved the experience for other users searching that same route.
Key learnings
The decision to display some of the messaging for a minimum duration was fairly controversial but ultimately lowered the net amount of friction the users faced. In some circumstances it is okay to intentionally slow the user down in order to be transparent and set expectations.