GetYourGuide
Wishlist
Wishlist
The Wishlist page is one of the most important pages in the GetYourGuide funnel. It's the page where travellers save things for later, where they compare between potential activities and where they essentially plan their trips.
In late 2019 we started looking at how we can improve the planning experience, with the main goal of increasing conversion.
In late 2019 we started looking at how we can improve the planning experience, with the main goal of increasing conversion.
Goal: Improve the wishlisting experience with the goal to increase conversion
High-level research
We kicked off the project with a really high level research, looking to understand what's not working on the current wishlist experience, while also trying to define what a long-term planner would look like.
We started with digging through past research, then continued with user interviews, Walk the store sessions, benchmarking and more. At the end, we had a large set of problems that we could start exploring.
We started with digging through past research, then continued with user interviews, Walk the store sessions, benchmarking and more. At the end, we had a large set of problems that we could start exploring.
The current wishlisting experience was sub-optimal
At that time, travellers were only allowed to add to wishlist from the ADP. Although this seems to be fine (given that the ADP is the page with most details), quite a lot of people saved lots of things to wishlist so they could compare later.
Comparison was difficult
In most cases, the wishlist was used to compare between potential activities. The current wishlist page didn't allow for easy comparison, requiring an in-and-out behaviour between activities.
Hard to plan
Trips usually have complex scenarios, and our current wishlist couldn't accomodate those. Things like adding dates, collaborating with other travel partners or planning an itinerary were missing.
On top of that, the wishlist page could easily become overwhelming after 10+ activities, people wanted to be notified of availability or offers, etc.
At that time, travellers were only allowed to add to wishlist from the ADP. Although this seems to be fine (given that the ADP is the page with most details), quite a lot of people saved lots of things to wishlist so they could compare later.
Comparison was difficult
In most cases, the wishlist was used to compare between potential activities. The current wishlist page didn't allow for easy comparison, requiring an in-and-out behaviour between activities.
Hard to plan
Trips usually have complex scenarios, and our current wishlist couldn't accomodate those. Things like adding dates, collaborating with other travel partners or planning an itinerary were missing.
On top of that, the wishlist page could easily become overwhelming after 10+ activities, people wanted to be notified of availability or offers, etc.
During our workshop sessions, we started turning the insights into HMW's that we can then start ideating on. We got a good mix of engineers, PMs, UX Writers in the same room and started exploring potential solutions for the problems we identified. This session had 2 main goals:
1. Create a backlog of small improvements that we can start shipping
2. Define a long-term vision that we can then validate with users.
1. Create a backlog of small improvements that we can start shipping
2. Define a long-term vision that we can then validate with users.
Wishlist basics
We kicked off the project by bringing the wishlist up to speed with industry best practices. While some things were pretty straightforward, others took more research, design and engineering time.
As an initial step, we wanted to make the wishlist more visible within the platform and drive more traffic to it. At that point in time travellers were only able to add to wishlist from the ADP, so we implemented a way to add from all pages.
As an initial step, we wanted to make the wishlist more visible within the platform and drive more traffic to it. At that point in time travellers were only able to add to wishlist from the ADP, so we implemented a way to add from all pages.
Unlike apps, the web version had even more optimisation issues. Besides adding wishlist on Discovery and Results screen, we also looked into optimising the way travellers add to wishlist on the ADP - where the button's affordance wasn't great.
After the affordance changes brought more than 30% traffic to the wishlist page, we could start looking into other improvements.
The next one on the list was the empty state. While previously we only had a simple message, we now wanted to educate users on how the wishlist works, and encourage them to create an account so they can sync across devices. On top of that, we also added reviews and price, looking to improve comparison between activities.
The next one on the list was the empty state. While previously we only had a simple message, we now wanted to educate users on how the wishlist works, and encourage them to create an account so they can sync across devices. On top of that, we also added reviews and price, looking to improve comparison between activities.
Grouping
During the research phase we noticed how overwhelming the wishlist page can be when planning more than one trip (most activities weren't organised properly, so for example you could end up with Amsterdam and Paris activities on the same page). Given that most travellers had +3 trips planned during a year, we looked at ways to add grouping.
On top of that, we wanted to slowly introduce the trip concept, so people could add dates, collaborate with others and so on, which wasn't possible on a single listing page.
We started the grouping process by exploring lots of potential routes. The main candidates we looked at were automatic grouping (where we automatically create groups based on the location) to manual grouping (where the user can create their own group based on their own parameters).
On top of that, we wanted to slowly introduce the trip concept, so people could add dates, collaborate with others and so on, which wasn't possible on a single listing page.
We started the grouping process by exploring lots of potential routes. The main candidates we looked at were automatic grouping (where we automatically create groups based on the location) to manual grouping (where the user can create their own group based on their own parameters).
Although automatic grouping was optimised for speed, during research we understood how complex the planning process is, and automatic grouping couldn't accommodate all those scenarios. For example, although a fair amount of travellers would only go to 1 location, we had a large number of people going to multiple cities at once, or going for day trips outside of the city.
For those reasons we decided to go to manual grouping. Users had the option to create their own lists, while we tried supporting them by creating default list names based on location.
For those reasons we decided to go to manual grouping. Users had the option to create their own lists, while we tried supporting them by creating default list names based on location.
If the user already had created lists in the past, they could easily select a list from the ones they've created. Although in the future we wanted to make that 2nd save process more automatic (For example, on the traveller's 2nd save in Kyoto, we would automatically add the activity to the Kyoto list), for the MVP we went with the basics to avoid complexity.
On the Wishlist page, lists are shown based on recency. Travellers can dive in deeper and see the list of activities saved. While this pattern is pretty common, it builds the foundation for trips - one of GetYourGuide's long term plans.
