Holiday Booking Filter

An unnamed holiday resort provider was experiencing dropouts from their website on their search feature. Users were directed to a page which contained a large chart of all available dates, locations and prices, which they then could filter through using a checklist. This filter was a pain point discussed frequently during the initial user testing of the product, and thus was an easy opportunity for improvement and A/B Testing. The featured checklist was reorganized to align with user’s mental models and from feedback during user testing.


The site was a live, already functioning website with several thousand hits a day, designed by an outside agency.

Users were recruited to align with the marketing demographics that the client was focused on, which included income level and location outside the M25 around London, who had families with children under the age of 16 who has the propensity or desire to have vacations within the United Kingdom (rather than abroad). Sessions were 1 hour long; with an initial interview to both build rapport and gain additional insight (not garnered from the telephone screening) about their family context, desire to go on holiday or vacations with their family, and if they had used the client website before, free exploration of the site, and task scenario user testing. Tasks were to follow the usual holiday registration flow of the website, if they had decided to take a holiday with their family at the client holiday resort. This included selection of date, location, room, desired extra amenities, as well as entry of guest information and confirmation of pricing (and a mock payment scenario including email confirmation). These were completed both on desktop and on mobile (and iPhone).

The holiday checklist filter was mentioned frequently during usability testing. Participants said that it was difficult sort through the large chart, especially with the filter functionality in it's current state. It also had a fair amount of disconnect from the resort information, which was desired by participants as they would want to explore their options prior to booking.


The filter results themselves were an issue that needed to be dealt with separately, but in the project scope of an A/B test resolution the functionality of the filter was more important, Changes to the UI should ensure users are presented with relevant resort information. Giving the users an easier way of sorting through these options provided was thought to increase their propensity to book simply by reducing the number of choices presented, and by ensuring their specific needs for date, nights, location etc were met.  


Design a A/B test variation of a better filter that provides users easier access to more specific holiday results that fit with their needs and wants.


Holiday resort bookers, who aren't already set in either their: date, location, or number of nights who are shopping around for prices on holidays. As many different types of people go on resort holidays, the functionality should be easy enough to use by advanced and novice users alike. 


The functionality needs to fit within the current site design, as this isn't a major overhaul of the entire website. Additionally, it should be flexible enough to compliment any future changes to the pricing chart provided on the site. Lastly, it will be tested through mutlivariate testing rather than an extensive user testing, so there needs to be measurable KPIs and metrics attached. 

Design Process

My solution provided organization to the checklist that was provided, dividing the filter into separate sections of Month, Resort (aka Location), Number of Nights, and Accommodation type. This would allow the user to be able to filter their option up front using site specific options, rather than sifting through a long checklist which they needed to select and deselect accordingly

Earliest versions of the design. A basic outline of how it would look at the page, without the content added in.

Discussion with stakeholders lead to a more refined version of the design, focusing on the filter and not the rest of the content below. This would allow for easier attribution should any uplifts arise during A/B testing and would allow for a second A/B test to be made. Designs were done quickly, without much iteration, due to the new test every 2 weeks nature of RedEye CRO services. 

Next Steps

As there is still a lot of information architecture problems within the site, navigation to the page with these filters was difficult. I suggested a tree testing and card sorting experiment to ensure that the language used on the client website matched with the user language. Additionally, the information gathered from these experiments would be used to determine if in fact sorting by these above options were in fact matching how the user wants to sort through their holiday resorts.

The first tree test was suggested to look like the following. Participants demographics would be similar to the demographics during the initial user interviews, potentially with a wider range of current users of the website, not just the desired marketing demographics.

Finally, after completion, the site would implement this new filter as an A/B test to test it's efficacy at increasing conversion and improving retention on this page of the website.