Location experienceFrameworks, techniques & tools used:
Location is a significant factor when choosing a hotel to stay in. Users find it difficult to understand and compare hotel location, and it’s proximity to major attractions. In this project, I was working on how we can serve location information, to help users understand and compare hotel surrounding information more easily. The objective was to reduce the time and effort that the user spends looking for location information, so they can make more confident booking choices.
For this case, I made use of a recent survey and user research that included users feedback about location needs. I learned from the research that proximity to attractions and transport availability are two factors that helped users distinguish if the location of the property was good/or bad. Oftentimes, users didn’t want to book a property close to these landmarks, but the location of attractions in relation to the hotel gave them a sense of city-scale and area recognition, that helped them choose the right place to stay.
I conducted guerilla testing of an existing product, to understand where and why users struggle the most. I discovered that in most cases, people were searching for nearby attraction information directly on the property page, followed by searching on the map. If they didn’t find what they were looking for, they opened a second tab in a browser and used a third party map to compare both maps - one with hotel location and the second with landmark location. It was an extremely long and manual process that required extra work from users, just to get a sense of the location of the property they were interested in.
Based on the research, I started to ideate on how I could improve the experience to help users learn about hotel locations and their proximity to major attractions. In this example, I used the “Crazy 8s” framework, in collaboration with the team, to help me quickly generate a lot of ideas.
For bigger initiatives, I sometimes conduct design thinking workshops, and include my non-design colleagues in the process, to have a bigger picture and broader perspective.
After the ideation phase, I go through all concepts and try to write down the impact each solution could have on a user, and technical investment required to deliver it. Thanks to a strong A/B experimentation culture at Booking, I often have available data from similar experiments that I can reference. I can then further prioritise each solution with my team.
In this case, I focused on the idea of showing content blocks with information about the nearest attractions, food and transport options on the property page. I also included similar information on the map, if the user actively searches for it.
I aligned with the internal Geo Agency Team and backend developers, to understand what content was available. I also went through Google and Places API docs to know if any of their capabilities could help me enhance our user experience. Part of the decision-making process involved confirming if the final proposal was also scalable. In this case, I collaborated with stakeholders from teams focused on summer and winter holiday types, to draft a proposal that could also benefit their use cases, if they wish to expand upon it with their content.
Based on geo and backend knowledge, I drafted the MVP of this idea in which I mapped out and documented all existing data sources I planned to use in production. I also decided that some data for this feature would come from Google Places API. It was the easiest and fastest way to validate the idea, also provided users with rich and reliable geo data without the need to collect a lot of content from our Geo Agency. This way, I was able to test this idea quickly, and get signals from users early, learn from it, and follow-up with a better solution.
Part of my usual UX process is also getting feedback from colleagues in weekly design critiques. It is always good practice to double check any design, and to make sure obvious mistakes don’t occur.
After aligning with the UX community and Product Manager from my team, I decided to split the solution into two experimentation lines - one focused on the map, and one on the property page location block itself. This way, I was able to isolate the effect and understand user behaviour more precisely.
I started by experimenting on the property page content block, because it could have a more significant impact on users, due to the amount of traffic the page receives. My goal was to help users find relevant location information more easily on the property page, so that they can confidently proceed with booking a property.
The first iteration of this experiment wasn’t successful on net conversion, but provided me with great learnings on how users were interacting with the content. I learned which of the tabs were being interacted with the most, which informed my decisions about where to position elements on the page.
I followed with the second iteration. Based on the knowledge gathered from the first A/B test, I decided to make the attractions tab most prominent (first seen tab), and push back the entry point to the map, below the fold.
This approach resulted in greater user engagement, which means users found this information helpful during their decision-making process. I also saw a reduced number of Customer Service calls and a significant increase in net conversion. Since we also developed a scalable solution, we enabled other teams to further experiment on this block, with their own content.
The success of this feature confirmed that we were moving in the right direction and supporting our long term vision. We held a team retrospective, to analyse data from the experiment, and followed up with ideas that could personalise the experience, and make it more relevant to different types of travellers. We also decided to scale it to other platforms for consistency. It fed our backlog, and also gave the team a sense of ownership, and involvement, in the whole process.