Hot spots & hotel hunting
A CASE STUDY OF
An experiment with points of interest and heat maps on Hotwire
Shridhar Reddy
Role: UX Strategy, Visual design, Prototyping
Role: UX Strategy, Visual design, Prototyping
Hotwire offers unbelievably deep travel discounts on hotels, cars and flights.
This is enabled by a very secret sauce unique to Hotwire – opacity. Hotwire's travel bookings are opaque. This means that when customers are purchasing a hotel room night, they dont actually know the brand name of the hotel or where the hotel is located – they only know the star rating and a neighborhood. Similarly, when they buy a car rental – they know only the location and time of the rental, they don’t know the rental company.
Hotwire customers gladly take a gamble on location and lap up these steep discounts.
Having an opaque channel solved a problem unique to the travel industry... how to not dilute a hotel's brand and yet be able to offload unsold inventory. Hotwire was the pioneer in this niche since 2000 with a loyal and price-conscious following. However, by 2014, the competition had wisened up. Priceline was successfully replicating Hotwire's opaque offering, the mobile revolution was demanding greater transparency. But most importantly, with the recession behind them, customers were now willing to pay a few extra dollars to know the name and location of their hotel upfront.
So, what was Hotwire to do?
Hey, I get it that you show me the hotel only after I book, but how do I know what neighborhood to choose if I’m new to the city?
This was the number one user problem for Hotwire, every single day.
In late 2014, Hotwire's product team asked the Web UX team to solve these problems:
“How can we show customers more about the neighborhood of the hotel without giving away it's location?”
“If I were a new visitor new to San Franisco, how do I know where to stay?”
I studied the existing company research studies and lore about how customers use maps to inform their hotel and flight purchases.
Filters & search on map increases the map’s value tremendously.
Points of Interest (PoI) are very useful part of advanced search.
Google Maps plays a big role in the post-hotel purchase scenario. Customers estimate public transport, directions, distance & walk times between PoI & hotel on Google. They never rely on hotel maps for any of this information.
From further reading and asking around the office, I came up with a list of data points that we had access to, that would be of value on a map.
Hotel location
Distance of hotel from airport
Public transport info
Services info
Dining & nightlife
Attractions, activities, landmarks
No-no. Breaks opacity.
Nope. Breaks opacity
Useful, but not really our cup of tea
Hmmmmmm
Useful
Useful
The last two themes looked promising.
The data we had around attractions
essentially became a list to which we added icons.
We inserted the Explore Neighborhoods list on the results page. The interaction was easy enough – click on a theme and you see PoI that correspond.
In theory, the PoIs solve the problem of “where is....” rather well. But PoIs do not solve the problem of “what is this area known for?”. Or the problem of “find me a hotel nearest to...”
Not only that, PoI add a lot of visual noise, cluttering up the map.
This tight cluster of PoIs is typical of dense neighborhoods. This impacts legibility and the browsing experience. How does one control it?
My colleagues and I had a conversation like this:
“PoIs solve our problem of showing where the good stuff is.”
Me: “I am not so sure. The only way i could tell how popular an area is is by visually comparing the number of PoIs in other areas and inferring a ‘normal’. That is makes the customer work for an inference.”
“We could solve the number of PoI problem with reducing the number of PoIs. Cap it as X PoIs per neighborhood?”
Me: “Throttling the PoI reduces the value of having PoIs in the first place.”
“What if we showed a total number of PoIs for each theme?”
Me: “That’s not a bad idea, but numbers are relative and merely convey a quantity and not a quality. We want to show the quality of a neighborhood.”
“Showing quality is very subjective. It might be expensive to build. We have limited data.”
Me: “What if the idea of quality could be conveyed from the same data? Is there a better mechanism?”
“Hmmm”
Me: “Hmmm indeed. Back to the drawing board.”
How does one convey the quality of a ‘hood?
This was the question I set about trying to answer for the 2nd pass. I considered a lot of solutions – clustering, tag clouds, user generated likes etc.
Heat maps were a perfect solution to the dilemma of showing neighborhood qualities. Why?
1) Heat maps show shapes – much easier to cognitively process than markers.
2) Different colors speak to density or activity.
3) Heat maps are almost universally understood.
Once the idea of heat maps was in place, I scaled up the functionality of the Explore tab to include Search and a mechanism to toggle the neighborhood polygon visibility.
Just PoI
Search bar now aids exploration
A legend helps make
sense of heat map
“Show neighborhoods” toggles hood visibility
The explore tab with all the functionality I envisioned.
-User searches for hotel on home page
-Comes to Results page
-Discovers and activates the “explore tab”
-Thumbs through the themes to discover a suitable neighborhood
-Uses search to find a specific location
-Searches for hotels around that location
-Toggles through the location hoods to find the right location
-Selects a hotel and (maybe) moves forward to purchase path.
To understand whether users understand the heat map and how to interact with it
To understand whether heat map themes help users find a hotel in a favorable location.
Whether as a filter before purchase or as an exploration tool after the purchase, participants unanimously agreed that they would use a heat map.
Search as a discovery tool was a big hit with easy engagement. However, that engagement might take the focus of the experience away from purchasing.
The combination of heat map and search results in an expectation for even more information. Participants wanted density information (how many wine shops), specific information (reviews, hours of operation etc), and distances (how far from my hotel). Traditionally, this information was gleaned after the purchase from Yelp/Google.
Correlation between heat map and hotel results list was unclear. Participants expected the hotel results list to change based on heatmap theme.
Hot spots overlaid with the hood polygons created huge information overload.
Given the real-world opportunities and complexities identified through this research prototype, the business decided that the Discover tab was worth building out and launched it in January 2015. However, the heat maps and the search feature were deemed too expensive to build with insufficient RoI.
Prototypes matter. Without having built out a complete and realistic experience, I would never have anticipated the challenges this design would have faced in the real world.
I was elated that the Discover tab was built out as envisioned by me and my colleague Ying Lin. But I was disappointed by the decision to forego building the heat maps and search tool. They held a lot of potential. But I had to concede that it was the right decision. We simply did not have that data. And even if we did, we could never match what Yelp and Google Maps do in that sphere.
The original ask from business was whether there was a way to help users new to the city decide on the right location for them. We were successful in answering that question and providing several alternatives.
After all, to quote Steve Jobs:
“I’m actually as proud of the things we haven’t done as the things I have done.”
Hotel lists do not show the name of hotel,
a ’hood, and star rating