Phase 1: Research

Competitive Benchmark

The first project was conducting a competitive benchmark. I selected 4 best-in-class mobile apps to review (Booking.com, Trivago, airbnb, and IHG) and picked these in particular because they covered a wide range of hotel booking users. Booking.com and Trivago are hotel aggregators, IHG is a large hotel conglomerate with many well-known brands under management, and airbnb being the leading online marketplace for homestays.

I conducted a heuristic review of each app's user flow from search to payment, and highlighted positive, neutral, and negative elements each step of the way. I was on the lookout for how well the app applied principles such as affordances, predictability, feedback, constraints, and forgiveness.

Online Survey

Next, I wrote and sent out a 10-question online survey using Google Forms to collect qualitative and quantitative information focusing on experience with hotel booking (either on desktop or mobile). Questions centered around ranking the most important information, why a user picks a particular website or mobile app, pain points they may come across, and suggestions for improvement.

I received nearly 30 responses mostly from users who travel a few times per year. Results showed the following key takeaways:

- Most users selected their primary method of hotel booking simply out of habit and name recognition
‍
- 2/3 of users preferred hotel aggregators as opposed to booking through a specific hotel or chain
‍
- The two most important pieces of information that respondents looked for when using a hotel booking app were pricing and date availability.
‍
- The main reason respondents visited a hotel booking website or app was to compare prices, rather than book a room.  This shows that the app is typically used as a first step in the booking process and the actual booking might not occur on the app/website.

Note-Taking

After reviewing my findings from the survey, it was time to do a deep-dive with users to see how they would approach a specific scenario. The course provided two 20-minute videos of moderated user testing which included an introductory section with demographic and relevant hotel booking questions. Next, the moderator gave a specific scenario for the user to complete for two mobile apps.

During the note-taking exercise, I was on the lookout for goals, behaviors, context, positive interactions, and pain points. I reviewed the videos multiple times to review not only what the user said, but also their body language and tone.

- First user seemed in a hurry and did not explore any features that were off the main path. The second user took his time and looked around the app more.
‍
- The call to action to sign up or log in to My Barcelo nearly stumped the second tester by making him think the only way to proceed was to sign up for an account. He may have closed the app if  he weren’t shown he could exit out.
‍
- Both users were tripped up on the calendar for the Doyle collection. The issue seemed to be  that they were used to selecting a check in date and then a check out date, where in this app  you had to select a check in date and then close the pop-up and then select a check-out date  separately. The Barcelo app utilized the format where you could select both dates at the same  time and seemed like it was easier for the users to understand.
‍
- Both users had a difficult time determining where the Barcelo hotels were located in relation to  the city center or the seaside. The first user did not find the ‘Compare’ option to bring up a map  view, but the second user was able to get to that view and determine which hotel best met the scenario criteria.
‍
- Transparency and detailed information was a theme for both users. In several instances they  could not find the information they were looking for easily. Whether that be the specific  location of the hotel, or the specific amenity like breakfast or prepayment.

I took note of pain-points such as the date selection being unnecessarily cumbersome, an unclear login (whether this was intentional or not is another question), and some information about the hotel being difficult to find.

User Testing

After watching some pre-recorded user testing videos, it was my turn to give it a try. I used the same scenarios from the user testing videos in the prior project, with two of the apps I benchmarked in project 1.
My wife was a great sport and gave great candid feedback on her experience following the given scenarios.

Some of the pain points from the pre-recorded videos were seen again, such as too much scrolling to select a start and end date, vague information regarding pricing, and she was even booted back to the home screen on accident and had to enter in all the search information all over again.
‍
It was surprising to me that the some similar pain points persisted across the new set of applications, and seemed to be unnecessary, easily-fixable things. This user testing, along with the heuristic analysis from the competitive benchmark, highlighted some key takeaways and opportunities to improve.

Affinity Diagram

Once user research had been conducted and the information gathered, it was time to move into the analysis phase. I, along with a partner (green vs red sticky notes), used Miro to build an affinity diagram, eventually grouping our virtual sticky notes into 13 categories. We began with an individual brainstorming session, where we synthesized data from the previous four projects. Next, we grouped the sticky notes into general categories, and then further refined them to that all notes were in the best-fitting group, and ensuring that there was no 'other' group.

Customer Journey Map

I utilized information from the affinity diagram to construct a customer journey map. The x-axis laid out the stages of the user flow (grouped into planning/pre-search, search, and room selection), and the y-axis represented the user information (experience, context, goals, behaviors, pain points, positives, and quotes).

The main pain-points on the map were non-intuitive date entry, intrusive add-on selection, and difficulty seeing basic information such as hotel location or taxes and fees.

User Flow Diagram

When creating the user flow, I made sure that the user always knew three things: where they are, how they got there, and where to go next. This was done through a variety of strategies including a heading and back button in the top right corner of each screen, and descriptive button text (for instance in the hotel detail page and payment page).

Phase 3 - Design

Interaction Design

Before I began sketching the low-fidelity mockup, I reviewed the affinity diagram and customer journey map to make sure all the findings were accounted for. I sketched two iterations of each step in the user flow, which ended up including 11 screens. I included some ideas for things to include, some notes in the margins, and lots of placeholder image sketches of mountains and suns. The goal for this section was to convert the user flow into a visual representation of screens, focusing on the overall structure.

Prototype

Based on my sketches, I designed a medium-fidelity mockup. For this stage, I did not include colors or images, as I was still just focused on the structure and flow of the app. Once again, I referred to the affinity diagram, user flow, and customer journey map while designing in order to make sure the user stayed at the forefront of the design.

Wireframe

The last project for the course was to create wireframes to act as requirement documentation to developers. This course taught me some new strategies for documenting requirements that I have already brought back to my day job. Documentation is something I am always trying to improve upon, whether it be creating detailed high-fidelity user flows, filling the page with requirements using Figma pins, or painstakingly assigning an ID to each element on the page and using Excel to provide that extra level of detail.

High-Fidelity Prototype

This step was not required for my certificate, but how can I go this far without doing the final step? I was surprised at how different the medium-fidelity and high-fidelity mocks looked. There were some details that I didn't have to think about at the lower fidelity levels, such as text over images, while my main focus was on the flow of the app. Overall, this project was a lot of fun, and I got some great insights and strategies that I already began incorporating into my day job.

Summary and Review

What I Learned

UX isn't always about solving one major problem, rather it is often about solving several smaller problems. There was no overarching issue with the hotel booking apps that I reviewed, but through my user research I was able to uncover several small pain-points that were consistent across most of apps I reviewed.

What I'd Do Differently

There were many design changes between the low-fidelity and high-fidelity mockups. If I were to do this all over again, I would put more scrutiny into the low-fidelity sketches and focus on more than just the basic layout. Details such as how to pair text and thumbnail photos took more time than anticipated to solve. Getting the contrast just right was a bit of a struggle, and in most cases I opted to place the text under the image. For this specific design issue, I reviewed other hotel booking apps, but also apps such as Hulu and Netflix to see how they handled placing text on top of a variety of colors for their shows and movies.

What's Next?

The next step for this project would be to conduct user testing on the high-fidelity mockup to test that the pain points that were outlined in the research phase were fixed.

Additionally, I could add extra details such as custom illustrations and micro-animations. One piece of information that was gleaned from user research was that the use of micro-animations for loading screens or skeleton screens reduced the annoyance of load times. One best-in-class app that I would look to for enticing micro-animations would be Duolingo. Their cartoon animations keep the user engaged and coming back time and again.
‍
Another feature I would add would be comparison functionality to compare hotels based on amenities offered. This was not a high enough priority to make it into the project in its current state, and for now is handled well enough in the filters section.