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 mentioned a few times during user testing. Participants said that it was difficult sort through the large chart, especially with the filter functionality in it's current state. 


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 organisation 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. 

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.