Creating a travel package picker

Context

For many years, Pollen has been creating and selling spring break travel packages to US students. Because of the effort required to create these customised packages, they were only available to large groups such as fraternities, sororities and other social societies.

Pollen wanted to start selling ‘curated travel’ trips to smaller groups of up to 20 travellers, enabling them to have the same experience without the overhead costs of the sales team manually managing the trip.

Earlier in 2019 Pollen rolled out a checkout, enabling customers to make purchases for pre-arranged trips. This would form the base from which we would build a way for customers to create their own custom packages.

Problem

Pollen was looking to sell these trips with very little input from inside the company, however we had no way for customers to pick the package and add-ons that they wanted.

We needed to create a way to solve this problem before December, in order to meet the deadline for the first wave of launches in Europe.

Objectives

Design, test and build a new in-product way to create custom packages. Integrate with the existing Pollen checkout and enable D2C customers to use the tools created.

The final campaign, package and launch details were still being planned, so we needed a flexible solution that would be able to handle whatever data and use cases we were given.

Process

The project kicked off in October, with multiple product teams within Pollen working on areas of the solution.

Activation was responsible for the initial landing pages, Pollen upsell and application forms.
My team, Revenue, was tasked with creating the package picker and integrating with the checkout team.
Checkout needed to enable the new type of product being sold, including split payments, payment plans and personal details.

Before planning a kickoff with the Revenue team, Zoe, my PM, and I discussed the overall aims of the project, any potential pitfalls, integrations and unknowns that we needed stakeholder input to unblock.

We decided that with only a 9 week window to complete the work we would need to capture requirements, design and test in quick iterations as we went. As a business we were comfortable with the initial launches being used to learn and refine the process, so we were free to move quickly and learn from each release.

Requirement gathering

Zoe and I had several conversations with teams around the business to understand their requirements and what would feed into the final product.

Following these discussions we created a list of screens, data that would be required and key touch points for customers.

• Data to capture – Number of travellers, departure date, trip duration, package, hotel, number of rooms and room size.
• Travellers – Trips would be customisable for up to 20 travellers
• Hotels – There would be multiple tiers of hotel, standard, premium & deluxe, with one hotel per tier.
• Packages – There could be multiple packages, but at least 1 on every trip
• Departure dates – There could be any number of departure dates, from a one off, up to every single day
• Duration – Similar to departure dates, there could be 1 or many trip durations

Because of how our Django admin system was configured, certain options were dependant on others for validation and availability. For example, room availability was dependant on the number of travellers in the party. This meant that the order we asked certain questions was dictated by technical constraints.

User flows

While my team was only focused on the package picker, it was helpful to know the flow for the whole journey. Knowing what pages flowed together, the content on each one and the stages that they would be released helped us to understand what level of details and information was needed on each screen.

Zoe created a combined user flow for all teams, covering everything from initial announcements and pre-sale, through package creation and payments.

Wireframes

After discussing all the requirements collected so far, I created a series of low-fidelity wireframes to share with the team. Initially these were on paper, but as more teammates were involved, they moved into figma so they could be shared, discussed and edited remotely.

Feedback on these rough wireframes suggested that the order of screens could be streamlined in order to make the process more simple for both users and engineers. By leading with the number of travelers, we would both match user expectation and significantly reduce the number of database queries required to check every combination of package and departure date for availability.

We settled on an order that we planned to test with users to see how it flowed before engineering began.

1. Number of travelers
2. Departure date and duration
3. Package
4. Hotel and room type
5. review

Testing

Based on the internal feedback, and a flow agreed, I created some more refined prototypes to guerilla test and understand how they matched user expectations.

This round of testing gave valuable feedback from real users, and helped us understand where we could further refine the flow.

While the users we tested with liked the concept, there were some areas we could immediately improve on:

• Users felt there were too many screens relative to the amount of information required to select from
• The felt the first screen, where you choose a number of travelers, was dull and not a compelling way to start the process
• Splitting picking a hotel and room type confused users, with the expectation that both items are combined into a single step

I took this feedback, refined the flow further and improved the information shown on several screens. Improvements to the initial landing page, package & hotel hotel screens and the review trip view were made to ease the customer journey.

I also created a number of smaller prototypes to test various concepts we were considering around date pickers, pricing, hotel and room options.

For the price picker, we wanted to explore how it felt to have the price auto-adjust based on the number of travellers, and was it obvious that the two were related.
The date picker was experimented with to see how multiple durations and departure dates may be represented in a calendar.
Accommodation options for relative or absolute pricing were considered, in order to make any potential upsell feel less expensive.
Room options were explored to see how we could group hotels together and better display the rooms and beds available.

V1 launch

As we neared the launch date, I worked closely with the engineering team to provide documentation, test and QA components as they were being built.

Roughly a week ahead of launch the product was feature locked and the operations team were able to populate the site with real inventory and content. At this point, however, it became clear that some of our product decisions didn’t match up with the packages and inventory that had been provided.

• The feature to display multiple departures and durations was not needed, as initial campaigns only had a single departure date and duration.
• To simplify the offering and messaging to customers, only a single package was added for each trip.
• Operations were unable to get exclusive use of some hotels, so we needed to add multiple hotels in the same tier to cover the shortfall in rooms. This meant the hotel step had many more options than initially considered.

After a week of using social media and email to drive hype and interest in the campaigns, we launched with 3 trips to Ibiza for ABODE, Defected and We are FSTVL.

Version 1 performance

The ABODE and Defected packages performed well, with over 100 of each package sold in the first week. They continued to sell consistently throughout December.

However, We are FSTVL did not perform as expected. Pollen wasn’t able to confirm the lineup before launch, and so with most content left in a TBC state, customers were naturally hesitant to buy.

Diving into the analytics I could see there was a significant drop off on both the first and last pages of the package picker. While not unexpected, browsers would stop after entering the funnel, and the last page is the final screen before payment, we wanted to explore some options to improve these two steps.

Learning from launches

Now that the campaigns were live with real content, Celine, UX researcher, and I organised a series of 6 user interviews with members and customers who had interacted with the campaigns, to run through the package picker screens.

• The initial group size and date screen was seen as too plain, and did not match the screen the customer had come from.
• Participants were confused by the date and package steps. With only a single option to choose from, they felt it better to automatically select these and skip the step.
• The hotel step was seen as a positive, however they felt there was limited information on the hotel, causing them to go elsewhere and look up the accommodation options.
• The review screen did not reinforce the positive messages seen earlier in the journey, so users were hesitant to book.

Version 2

We took this feedback along with our learnings from the initial launches into a second version.

The team agreed to simplify the journey, skipping unnecessary steps and adding richer information where required.

• Make the group size step more compelling, with a summary of skipped steps and pre-selected information.
• Skip any steps that only had a single option to choose from, cutting up to 3 steps from the package picker.
• Expand the hotel information screen and use a modal with details of the hotel location, amenities, photos and star ratings.
• Reorder the review screen, making key purchasing information more prominent.

V2 launch

Because the package picker was already live, we opted to iterate over each problem independently. I worked with different engineers within the team to address each problem and build the solutions.

We worked with the marketing and operations teams to put new workflows in place to gather and input the new content required for the packages, hotels and payment information.

Outcomes

The revisions and changes to the package picker were launched between February and April 2020, unfortunately coinciding with the outbreak of COVID-19.

Before the pandemic became a significant blocker, the changes appeared to increase conversion by 5%, although with the drop in traffic it was not possible to say if this was significant.

In April we launched three new trips for later in 2020, two festivals in Amsterdam and skiing in the Alps. These three launches out-performed all expectations, both selling out within 30 minutes and crashing the site due to the high levels of interest and demand.

Next steps

We are continuing with our planned roadmap to expand the capabilities of the package picker.

1. Add soft lead capture to re-engage potential customers
2. Expand further the information on hotels and packages with lineups, reviews and maps
3. Revisit the calendar component, now we know that the number of departures is limited
4. Make hotels optional, to match the model we may use for other addons within the flow