Redesigning the “Search Experience” on Hostelworld’s web app: The whys and wherefores of it.
Hostelworld is a booking platform for hostels that works pretty much all around the world, with an audience of travelers that counts on them to book accommodation at their next destination. Being challenged to improve and optimise Hostelworld’s “Search Experience” proved to be an opportunity that best allowed me to implement my classroom learnings about UX design into real life scenarios.
PROJECT BRIEF
To further our learning as students of design and in pursuance to our school’s (The New Digital School) “Call for Problems”, we were presented with a challenge to optimize Hostelworld’s search results page. The challenge was then assigned to me and three other colleagues of mine to accomplish in a two weeks time frame. Our team of four set out to see this challenge to its fruitful end. Our team and our respective roles for the project are as follows;
Damon Redding — Project Manager, UX researcher.
Harita Sahadeva — UX researcher, UI Designer, Documentation.
Joao Aruojo — UX researcher, UI Designer.
Sarthak Veggalam — UX researcher
The Challenge
- The challenge mandated an analysis and optimization of Hostelworld web app’s search results page (internally referred to as the “property listings page”).
Owing to some legal constraints, Hostelworld was unfortunately stifled in communicating instructions/research to my team. Questions concerning the search results page, existing user information (if any), analytics of the page, user complaints (if any) to name a few, lingered. This takes me to our biggest challenge during the duration of this project:
How to deliver on a design brief with little clarity on what needs to be rectified?
A quality design product emerges from the intersection of business goals and user needs. In our case, given this peculiar predicament, we turned to the users of the HostelWorld web app. The users of Hostelworld web app aided us in determining and defining the objectives, the context, and the problems for us to design and deliver potential solutions for. We, therefore, set out to tread on a user-centered path. We further aimed at taking steps to bolster user conversion rates through our potential redesigns.
DESIGN PROCESS
During the two weeks time, my team and I diverged and converged through five broad stages of our design process, namely;
Stage 1 — DISCOVER
Stage 2 — DEFINE
Stage 3 — DEVELOP
Stage 4 — DESIGN
Stage 5 — TEST
Stage 6 — DELIVER
STAGE 1: DISCOVERY
The objectives of the discovery stage are as follows;
- Conducting user research to gauge user behavior and identify potential pain points
- Acquiring an insight into the potential pain points and gaining context.
Step 1: User Research — Know your users and acquire context
Objective: Understanding user behavior, habits, preferences, and patterns (if any)
Step one towards clawing through ambiguity was acquiring context. We identified our target audience as travelers staying in hostels. For the said context, we ventured out to do some field work. We visited two hostels in Porto, Portugal, located in close proximity to the city center i.e. Hostel Nice Way Porto and PILOT design hostel and bar.
Prior to our visit, we prepared a script with questions aimed at acquiring information which would help us understand hostellers better. Through our visits across both hostels, we interacted with the managers of each hostel and five hostellers in all. We documented the responses we received and proceeded to examine them.
We needed to acquire a deeper understanding of the users and their behavior (especially while interacting with Hostelworld’s web app). Further, we needed to test the information gathered and assumptions that were consequently formed.
Step 2: User Story Mapping — What features of the web app are of primary importance to the user?
Objective: To understand different types of user journeys and prioritize features of the web app that need focus.
In order to develop greater empathy with the target audience, it was pertinent that we understand user journeys from diverse perspectives. Furthermore, we needed to understand as to which features from the search results page are most relevant to users and prioritize them for optimization. For the said purpose, my team resorted to user story mapping. Each of us came up with our individual user stories carefully founded on the assumptions we formed during user research.
We then identified themes that emerged from each user story. Each user story was split into parts and then was broadly categorized under the established themes.
After having placed all stories under broadly defined themes, the next stop was to associate each theme to features available on the Hostelworld web app.
Consequent to the co-relating, we then proceeded to vote on the themes to gain unanimity on those themes which according to us needed focus and prioritisation. We therefore agreed on the finality of the following 4 themes and their co-relating features on the Hostelworld web app.
- Trip Planning Flexibility: What all features of Hostelworld enable trip planning flexibility?
- Personal Passion: To what extent do personal passions motivate users to book hostels?
- Social Influences: Are there any social influences and if yes, how do they increase traction?
- Events: Does Hostelworld accommodate experiences tailored around any events?
These themes however needed to be confirmed by the users. For validation, we decided to focus on “events” and “trip planning flexibility” as being the most actionable themes of the four. Using these themes as the base, we proceeded to prepare scripts for usability testing and user interviews.
Step 3: Usability testing and user interview
Objectives:
- To gauge user behaviour while interacting with the web app.
- Find out whether users are able to complete specific tasks successfully (e.g. navigate through the sight — find hostel, find information, book hostel)
- To identify pain points of the users during their interaction with their web app.
- To reaffirm their experience vide a Q&A session and gain their feedback.
- To test assumptions gained during field research.
- Identify what influences users decision making( what makes them chose one property over another when looking at a list of properties)
For usability testing, using the “themes” that we arrived at during user story mapping as the base, we tailored two distinct scripts directed towards two different categories of hosteller, i.e. “the solo traveler” and “the people traveling together”.
The usability test was to be followed up by a user interview. The questions we formulated for the interview were aimed at eliciting from the users their experience of using the web app and their emotions at different points. Further, we wanted to learn the overall thought process of hostellers and we also requested them to draw from their previous experiences of living in hostels (if applicable).
To conduct the usability test and the user interviews, my team of four diverged into teams of two and covered the same two hostels that we earlier used for user research. My team took to Hostel Nice Way and my other two teammates set out to Pilot Design hostel. My teammates and I scoured and picked at random 10 hostellers to perform usability testing with and to interview.
With the prior permission of the users, we recorded their interaction with the Hostelworld web app while performing the assigned task and recorded the interview that followed the usability test.
As aforementioned, we defined two different exercises for the usability test. One meant for hostellers who are solo traveling and the other meant for hostellers traveling with company. We assigned these task in the intended manner to the 10 hostellers. By combining a usability test with an interview, we acquired more information than what we initially anticipated. The next stage was organising and examining all the acquired information.
STAGE 2: DEFINE
The objectives of the define stage are as follows;
- To organise and examine information acquired during the discovery stage.
- To identify and narrow down on potential pain points that can be remedied.
Step 1: Examining and synthesising Data
Objective: To organise and comprehend information gathered.
Our team converged and shared data that we acquired from users from each hostel. We went over each audio and video recording and filtered through the influx of information.
We committed all pertinent observations/ behaviours/comments/suggestions/pain points to an excel sheet, user by user, split across two hostels and notable patterns.
Step 2: Identifying and categorising user pain points
Objectives: To categorises pain points in accordance with the level of priority they merit.
Through our preliminary analysis, we identified struggles that users faced while interacting with the Hostelworld web app. These struggles could result in different ramification for Hostelworld. From the user abandoning the web app altogether to simple usability issues that when remedied, could bolster experience. We therefore felt the need to categories all pain points depending on the gravity of the consequence they may result in. It was also our intention that such categorisation would help us define where to focus our attention and time on the most. For the said purpose, we implemented the “decision tree” to categorise user pain points into “Medium Problems”, “Serious Problems” and “Critical Problems” accordingly.
Components of the decision tree matrix:
Red route: It is the route which the user adapts for either of the following;
- The route the user pursues frequently to accomplish a certain task (eg. search) or
- a route which the user adapts to accomplish a critical task, which may not necessarily be frequent (eg. editing user bio).
The red route is a reflection of business objectives as well as user goals. At times business objectives may be asynchronous with user goals, yet user goals should not be undermined or treated any less.
Persistent problems: Persistent problems are problems that keep cropping up. “persistent” means that the problem occurs repeatedly, throughout the interface — users come across the problem on multiple screens or pages.
Difficult to overcome: How much a user will struggle in overcoming a usability issue? Some usability problems are show-stoppers: users just can’t proceed. For example, if an important control is hidden behind a right click, the functionality may as well not exist for some users. Hard to solve problems are severe because they have a bigger impact on completion rate.
Medium problems are the problems that frustrate the users but do not affect task completion.
Serious Problems will significantly slow down some users when completing a common task and may cause users to find a workaround. These mandate remedying as soon as possible.
Critical Problems are the problems that will make some customers unwilling or unable to complete a common task.
Using the flow of the decision tree matrix, we categorised identified user pain points in the aforementioned brackets.
We noticed that a seizable number of identified user pain points related to “map view” on the Hostelworld web app. We further observed that all of these pain points regarding the map view, in turn contributed towards an “abandonment” issue which we identified as being “critical” in nature i.e. “Users either not using or abandoning the map view on the Hostelworld web app to instead use Google maps”. Having taken cognizance of this behaviour, my team regarded “map view” as a priority concern for the problem definition.
STAGE 3: DEVELOP
the objectives of the “develop“ stage are as follows;
- To frame the problem definition.
- To find innovative and business-centric solutions.
Step 1: How Might We’s and Innovation/Crucial Matrix
On having prioritised Hostelworld’s map view, my team and I resorted to “How Might We’s” (HMW) to chart out the problem definition. We came up with the following HMWs concerning map view:
We then proceeded to arrange the HMWs arrived at on an “Innovation/Crucial Matrix”. “Crucial” here refers to being crucial to the business and “innovation” refers to the novelty of the solution. We arranged the HMWs on the vertical axis denoting “crucial”. The higher up on the matrix, the more crucial it is to the business.
In response to the HMWs, we set out to brainstorm solutions. The solution which each of us came up with was then organised on the horizontal innovation axis, in order of most to least innovative.
Step 2: Wireframes
Objective: To translate solutions into workable web app designs.
Using the innovation/crucial matrix as the backbone, my team and I decided that each of us would design wireframes of a brand new map view, which incorporated solutions arrived at to the HMW’s. Three of us came up with our respective wireframes and presented them to the team.
Wireframe presented by João Araújo
Wireframe presented by me:
Wireframe presented by Damon Redding Elliot:
We picked the best components from each submitted wireframe and brought them all together to serve as a composite solution. We proceeded to translate the agreed-upon template for the redesigned map view into a high fidelity functional prototype, while simultaneously implementing solutions for the medium and crucial category of problems.
STAGE 4: DESIGN
Objective: To translate solutions from paper mockups to high fidelity workable prototypes.
Priority One: The redesign of the Hostelworld map view.
Pain Point 1: Instead of using the map view of Hostelworld web app, users leaving Hostelworld to instead use Google maps.
The decision tree matrix points towards this being a “critical” problem. The problem occurs on the red route. The fact that users are abandoning or not using the map view on Hostelworld indicates that the problem for them is difficult to overcome. Users are neither using the map view on the search results page of the map view on the hostel property page, so the problem is persistent in nature.
With users leaving the Hostelworld web app to access google maps, albeit temporarily, it posed serious ramifications to Hostelworld. Hostelworld ran the risk of losing the user completely. That is because when the user input the name of a hostel on google maps, the map would make recommendations of hostels as advertised by competing web apps such as Booking.com, Logitravel etc.
This created an opportunity for the user to abandon the web app completely, thereby adversely affecting conversion rates.
Solution: The users need to use google maps as against the map on Hostelworld web app stemmed from other map-related pain points which the users experience. We staged the redesign of the map view by targeting each such pain point and by bringing the composite solution together.
Following are the map view related pain points along with their proposed solutions;
- Pain point 1.0: Users being made to choose between list view and map view.
While analysing the search results page of the Hostelworld web app, we realised that the users have to choose between two distinct views of the search results page. The results could either be viewed as a “list” or on a “map”. There exists on the search results page a “display mode switcher” which enables switching between the two modes.
During the usability test, we noted user behaviour where the user would access google maps without ever switching to map view on the Hostelworld web app. Is that because the users did not notice the display mode switcher, we weren’t sure. Moreover, users opening google maps on a different tab would constantly keep referring to the results on the Hostelworld web app and try and acquire more information with the amalgam of the list view of the search results page and google maps.
Solution: To account for the possibility that the users did indeed not notice the option of two views, and catering to their desire to “have it all”, we decided to get rid of the mode switching option. Why make the user choose between two views when they can have both. Especially when having both views offers greater information and context which allow the user to make more informed decisions.
As against keeping the list view and the map view as two distinct pages, we combined the two into a single “search results” page. The reasons for this decision are as follows;
- Most users seek context in terms of location while looking at properties and to have such context through a map even while scrolling through a list of properties, makes for a pleasurable experience.
- It reduces the chances of users leaving the web app to use google maps in order to gain locational context or seek our points of references.
- It saves clicks for the users
- Pain point 1.1: While using the map view on the Hostelworld web app, the users felt overwhelmed with the clusters of location pins.
The chaos of location pins as can be seen above threw the users off completely and inhibited them from exploring the map.
Solution: We needed to clear out the cluster mesh. Instead of having multiple location pins overlapping each, we designed a singular “cluster pin”.
The pin eliminates the representation of multiple hostels in close proximity to each other as an overlapping cluster and instead, showcases the number of available hostel in a given location and the price range they fall under as a singular pin. This gives the user an understanding of the number of hostels available along with the price range without creating a cluster mess.
We further redesigned the location pins representing individual hostels to be consistent with the cluster pin. These pins represent the price and the rating of individual hostels.
When zoomed in further, the following two things happen to the cluster pins;
- the cluster pin dissipates, giving way to more hostels being represented as individual hostel pins.
- When zoomed in completely, the cluster pins completely disappear giving way to individual hostel pins.
Pain Point 1.2: Users found it difficult to gain context when using the map view.
Through user research and user interviews, it became clear that hostellers while traveling like to make the most out of their travels. They, therefore, prefer booking hostels in close proximity to the city centre or better yet, hostels in close proximity to popular tourist destinations. While the Hostelworld web app did provide indications of the distance of each hostel from the city centre, the usability test showed that it was not enough to keep users from using Google maps to acquire more context while booking a hostel.
Solution: In order for users to gain more context while booking hostels, we introduced a new feature that fulfils that need. I.e. “the point of interest pin” (POI pin) . The POI pin on the map indicates popular tourist destinations and provides information in brief about each such destination. Users will now be able to book hostels closer in location to popular tourist spots, thereby making travel more convenient for them.
- Pain Point 1.3: The zoom in and zoom out options were difficult to locate by the users while using the map view thereby leading to a lot of confusion.
The users during the usability test struggled to navigate through the map on the Hostelworld web app. The cluster of location pins could only be cleared by zooming into the map, a learning curve that several users struggled to grasp. Majority of the users attempted zooming into the map using “scroll”. Scroll for zooming in works on google maps, but that’s not the case when a widget of google maps is embedded into a page, as is the case with the HostelWorld web app. On the current Hostelworld web app, zooming in and out can only be achieved by using the zoom in and zoom out buttons.
The problem however being that the components that enable zoom through the map are easy to miss given their small size and placement.
Solution: With the integrated map and list view redesign, and the map view now occupying 60 % of the total interface, it can now be made possible for the users to scroll to zoom in. when the user places the cursor on the list and scrolls, it will enable him to go up and down through the list. When the user places the cursor on the map, scrolling in this case would activate zoom.
We further redesigned the navigation components, in this case the “zoom in” and “zoom out” buttons to look more prominent on the map. The intention of the redesign being to make these components more visible to the users and therefore, hard for them to miss.
Priority Two: Designing solutions for the Medium category of problems
Having dealt with the whys and wherefores of the map view’s redesign, we then proceeded to design solutions for pain points identified for the remainder of the interface. I.e on the list view, the filters and the sort.
All of these pain points, when having the decision tree matrix applied to them, they all featured in the medium category.
None of the following problems are difficult to overcome, nor persistent.
Pain point 1 : Users finding it difficult to understand “sorting by price”.
The difficulty faced by users in understanding price sorting while selecting hostels on the search results page, i.e. whether properties are displayed in ascending or descending order of price.
Sorting by price was the most popular sorting option which the users applied when selecting hostels during the usability tests. However, when applying “sort by price” to the search results, the confusion created in the user’s mind was weather the sorting of hostels was in ascending order of price or in descending order of price.
“Did I set this right, wrong? Price… which way is it going?”
Dan, Australia (User)
Solution: We incorporated a two-fold change. First, we specified the manner by which the price sorting worked i.e. properties are being displayed in ascending order of price. The least expensive property would be displayed first and the price increases with every subsequent property on the list. The second change was to make sort option (whether by price, rating, distance, name) visible when selected by the user. This is so, so that the user knows which sort option he/she has opted for.
We added an extra layer of copy showing that the hostels are being sorted from low price to high price. Notice that the sort type (i.e. price) is made visible when opted for by the user.
Pain Point 2: Users unable to tell if the price of the hostel is per night or not.
Users being confused if whether the price displayed of a hostel on the property card in the search results is indicative of the price per day or the over-all price of the said hostel.
On the search results page, when the hostel property cards are displayed, each property card indicates the price of the hostel (private and/or dorm). The confusion faced by users when viewing these prices is whether the price displayed is reflective of the price per night at the hostel or a flat price all nights. It is only when the user visits the property page of the selected hostel, where the copy clearly indicates that the price is on a “per night” basis.
“Something that confuses me is — look here, I have ‘Privates from’ and I don’t know if this price is per night or for all the nights.”
José Carlos, Brazil (User)
Solution: We added a layer of copy clearly indicating that the price of the properties is per night.
Pain point 3: Filters not visible in map view
The filters which the users would apply on the search results would not be visible when the user switched from list to map view. When applying various filters, the users often lacked clarity regarding which all filters they opted for and in what measures, because the filter section on the Hostelworld web app would keep getting toggled off as soon as the user switched to map view. Further, although the active filters are indicated with a check mark when the filter section is toggled on, yet it does not display the exact measure of each filter selected by the user.
Using filters in the current interface of Hostelworld
Solution: Now that in the proposed redesign of the search results page, the map view and the list view are integrated into one, there was no need for the filter bar to toggle on and off. We, therefore, designed a filter bar which remains fixed. Further, the active filters along with their specific opted measurements are shown highlighted in comparison to the in-active filters for the users to aware of the choices she/he is making.
Pain Point 4: Identification of the gender-specific dorms not being distinct enough.
During usability testing, to our surprise, we noticed a few male users booking themselves into dorms in hostels, exclusively meant for females. This we felt could result in a terrible user experience i.e. having to have to restart the booking process from scratch and finding another hostel. The reason this behaviour repeated itself was because the gender indicated on the dorm beds was not distinct enough in order to grasp the user’s eye. Especially in cases where the users are in a hurry.
Solution: We designed “gender badges”. These badges when used for dorms, highlights the exclusivity of a dorm and make it hard for the user to miss. Further, these badges carry crucial information, regarding the availability of rooms.
Pain point 5: Time spent scrolling to reach crucial information on the hostel property page.
During the usability test, we observed that on opting for a hostel on the search results page, the user would select the hostel which would open that hostel’s property page. On being content with the hostel description and the gallery of photos of the hostel, the user then proceeded to book the hostel and scrolled down further to reach the table that displays prices and availability. However, it was after scrolling down to this section that the user realised that only one male room was available and he needed more rooms. The amount of effort the user had to put to get to this information, amplified the user’s disappointment.
Solution: We redesigned the hostel property page. In order eradicate unnecessary scroll time, we divided the property page into two halves. First-half which roughly occupies 60% of the page focuses on the description of the hostels. The user when scrolling through the first-half gets pertinent information about the hostel, such as its features, gallery, location, description, ratings, reviews, facilities etc. The elements of description in the first half are the same as the ones on the current Hostelworld web app. The second-half which remain “fixed” is the section which prompts information about the availability of rooms and once selected, to book the room(s). As soon as the user opens the property page of a hostel, as against having to scroll to get to crucial information, that information is now readily available in the fixed “select rooms” section.
While we kept all components which currently exist in the hostel property page the exact same on the redesigned hostel property page, we did however introduce a new element based on user feedback;
The “nearby tourist attractions” cards
These cards appearing on each hostel property page showcase tourist attractions which are in close proximity to the hostel. This aids users in optimizing their travel and provide easy context while booking hostels. The card provides details such as the name, image and brief description of the tourist attraction, along with their distance from the selected hostel.
Addendum
In addition to pain points identified by the users, we endeavoured to solve points of struggles which we ourselves identified while examining the web app.
Lack of affordance in “Compare” feature.
During the usability tests, none of the users used the “compare” option available on the search results page of the Hostelworld web app. Prior to the usability test, when I tried to use the compare feature as a new user myself, I struggled a while to comprehend how the feature works. It took two heads (my colleague I) to realise that the “compare” copy itself was clickable and actionable.
Solution: Every time the user selects the compare checkbox, a distinct compare section toggles on where the property he selects is added. Each hostel the user selects to compare appears in that section. As soon as the user opts for more than one hostel to compare, the “compare hostels” button in the compare section becomes active and clickable. When the user clicks on the “compare hostels” button, a tabular representation of all selected hostels along with their comparisons pops up, just as it already exists in the current Hostelworld web app.
Current designs v/s proposed re-designs
- The current search results page of the hostel world web app.
Our proposed redesign of the search results page.
2. The hostel property page on the current Hostelworld web app.
Our proposed redesign of the hostel property page.
STAGE 5: TEST
The objectives of the validation stage are as follows;
- Test if our map provides valuable functionality
- See if users find all the information that the map provides as being easy, visible and intuitive
- Understand what the user prefers and would be more interested in using.
Before presenting our work to Hostelworld, we needed to make sure our solutions worked. For this, we once again turned to the users. We performed usability testing with the new designs to see if all the targeted pain points concerning the map have been rectified. We tested with 4 users. We first made users experience the current map view on the Hostelworld web app and then asked them to accomplish the same task using our redesigned map view.
Versus
Across the table, while users expressed confusion and frustration while interacting with the current map view of the Hostelworld web app, they found the redesigned map view as being more easier to navigate and more informative. Despite being introduced to new features such as the “cluster pin” and the ”point of interest pin” users anticipated their purpose without any external help. The learning curves that were introduced in the redesigned search page were easy for the users to grasp. Further, the users also expressed delight on having access to more information and context with a combined map and list view as against having to choose between the two.
STAGE 6: DELIVER
We presented our work to Hostelworld in two stages.
Stage one, João Magalhães, the Product Designer & Design System Lead at Hostelworld, Porto, came to our school as a representative of Hostelworld to view and give feedback on our work. After having viewed our work, João felt the need to have our process and results presented to a larger group at Hostelworld.
“This was a journey” — João Magalhães
Stage two, we therefore went to Hostelworld’s office in Porto, where my team and I presented our work to the teams in Porto and Ireland (via video call). The presentation was attended by the following;
- Philip Bannon, Software Development & Engineering Manager, Porto
- Nelson Lopez, Regional HR Business Partner at Hostelworld Group
- João Magalhães, Product Designer & Design System Lead at Hostelworld,
Porto. - Maísa Carvalho, Product Designer at Hostelworld Group, Porto
- Donnacha Carroll, Product Designer at Hostelworld Group, Ireland
- Breffni Horgan, Chief Product Officer at Hostelworld Group, Ireland
- Carlos Yllobre: Product Design Manager at Hostelworld Group, Ireland
- Kristen Bourrillion, PMP, Product and Design Team Manager at Hostelworld Group, Ireland
We explained in detail our entire UX process and showcased what it resulted in. We exhibited our redesigns and the reasons for each iteration. We were questioned about our decision making process, user feedback, user pain points and about implementing the redesigns. On concluding the presentation, the representatives of Hostelworld most appreciated the user research and field work, along with our UX methods. The emphasis on UX and the UI being a projection of the UX as our approach, is what we received most praise for.
Author’s Note: Thank you for taking the time to peruse this unconventionally elaborate case study. I am always looking to learn and therefore, all constructive feedback and criticism is welcome.
Connect with me: www.linkedin.com/in/harita-sahadeva-aab2b050
