Removing Doubt From Mobile Hotel Booking

Problem

Booking Details Existed but Were Buried or Unclear

Mobile users booking hotel are often distracted or limited on time and therefore need a streamlined experience. While most competitors provide similar flows that matched users expectations, they often suffered from unclear pricing models, information overload, and burying key details such as location information.

Research

Unclear Prices and Crowded Pages Created Doubt

I conducted three competitor usability tests which had participants book on two live mobile sites each. I chose competitor testing because there was no product yet, and watching people book shows what they do, not what they say they’d do. Using two sites per person showed which patterns helped as well as which hurt.

I clustered every note in an affinity diagram, grouping by experience rather than by site.

Out of thirteen categories the two largest, Pricing Ambiguity and Information Density, each had 12 notes from all three participants. The issues in these categories posed significant friction, with multiple participants suggesting they would not have followed through on the transaction due to them.

To better align the feedback with their mental models of hotel booking I mapped goals, behaviors and pain points across seven booking stages in a journey map. The final checkout stage as well as hotel selection is where users felt the most confused and frustrated.

Unexplained Price Differences Left All Three Unsure What They Would Actually Pay

P1 had to guess that a price gap meant breakfast. P2 saw three different nightly prices with no explanation. P3 found two protection plans at very different prices, plus a large total with no label.

In my prototype, I put what each rate includes next to its price, showed the stay total early, and kept cancellation terms identical from rate choice to checkout.

Crowded Pages Buried Key Details, While Sparse Pages Left Them Out Entirely

P1 was looking for a hotel near a tube station and missed the detail that said so. P2 found a one-page checkout overwhelming, and P3 put it plainly.

But less wasn’t automatically better. P1 felt the leaner site was missing things, and she missed key details on both sites.

So I kept fewer things on each screen, put decision-critical details first, and moved the rest behind a tap.

Location Filters for Transit and Errands Rarely Existed

P1 looked for a tube-station filter on both sites and found EV charging instead.

P3 was confused by filters that used “miles from destination” as it was unclear what that meant when her destination was set to the city of Paris. She indicated that more practical language like “15 min walk from Eiffel Tower” would have helped her right away. She also missed a map button at the bottom of the screen until the moderator pointed it out. Once she found the map, she used it to spot bus stops, rail and groceries.

So I showed distances to named places in travel time and made the map impossible to miss.

Room Options Were Hard to Tell Apart

On one of P1’s sites, rooms appeared before the hotel overview, and she didn’t read them as separate options at first. P2 hit the same confusion, which was furthered by room photos that repeated the same general photos from the hotel.

So I made choosing a room its own step, after choosing a hotel, and prioritized clear thumbnail images that gave users a clear impression of what their stay would look like.

Clear Totals and Cancellation Choices Built Confidence

People slowed down at the end to check what they were agreeing to. P1 and P2 read the full booking summary and cancellation policy before paying. P2 switched on taxes and fees right away, and liked having cancellation tiers to choose from. P3 liked seeing the total for the whole stay.

So I kept these as conventions in my prototype: stay totals, a clear summary before payment, and a choice of cancellation terms.

Design

A Booking Flow That Shows Price, Location and Room Differences Early

I mapped the user flow before any screens, so I could decide what happens on each screen, and what triggers the next step, without layout distracting me. The brief asked for one ideal path, so I mapped the most direct route from search to confirmation.

1. 1
   In the flow · Search

   The destination step asks “Where to?”, not “Select property”

   Heard in research

   P2 thought she needed to know a hotel name

2. 2
   In the flow · Results

   Map control at the top of results

   Heard in research

   P3 missed a map button at the bottom

3. 3
   In the flow · Results

   Stay total next to the nightly price

   Heard in research

   P2 saw nightly prices change with no explanation, and P3 liked not doing the math

4. 4
   In the flow · Room & rate

   Each rate says what it includes, beside the price

   Heard in research

   P1 had to guess at breakfast

5. 5
   In the flow · Checkout

   Same cancellation policy at rate choice and checkout

   Heard in research

   P3 saw two policies that seemed to contradict each other

Sketches Settled the Screen States Before Figma

Paper is the fastest way to test layouts against the flow. I drew one sketch per screen state, with real labels and margin notes on how each interaction works. If I were working in a team, I might have used these early sketches as a “paper prototype” to gut-check that my screens were aligning to the flow established above.

Medium-Fidelity Prototype Focused Feedback on Usability Over Visual Style

I built a prototype realistic enough to complete a booking, not a polished visual design. So I put the effort into layout, real labels and working interactions, and kept imagery and branding light. I built the most decision-heavy screens first, results and room selection, and used realistic hotel, room and price data.

Testing

Availability Decides, and My Prototype Buried It

After constructing my prototype I ran another usability test, which revealed that my prototype was still falling short in location based search and highlighting room availability up-front.

The Participant Skipped the Hotel Overview to Check Rooms and Prices

On both hotels she opened, P4 scrolled straight past the overview to the rooms first. She gave the overview a quick gut check, then went looking for availability.

So in v2, I added a condensed room availability section directly at the top of the hotel detail page.

The Map Was Missed Again, Even Moved to the Top

P4 only found the Map tab when it was pointed out, yet the map is how she starts.

Moving the map control to the top, a decision taken straight from round 1, wasn’t enough. So in v2 I folded the map into the default search results landing page, making it impossible to miss.

“Reserve Room” Felt Like a Commitment

P4 hesitated at the “reserve room” button that was intended to confirm her room selection and advance to the checkout screen. She didn’t know what would happen next, or whether she could back out.

Iterations

Version Two Improved Browsing by Price, Location, and Availability

Most changes in the prototype circled back to one of two ideas. One: Prioritize showing the user the critical information that is used to rule options out first, and follow with the supporting information that sells the property. Two: Make every step in the flow say what happens next.

I duplicated the tested prototype and iterated on a second page, so both versions can be compared. Beside each screen, red notes show pain points from testing, and green notes show the change that addresses it. The full canvas is laid out in five sections, from home to checkout.

Map and List Now Share One Screen

Browsing by map view or list view was a highly preferential choice that varied by user and their familiarity with the booking destination. Most existing solutions prioritize one or the other and users often missed the hidden one. My version two prototype offers a hybrid approach that gives equal weighting to both paradigms and lets the user smoothly flow between them without losing their context.

Results now open with the map on top and the hotel list in a sheet you drag up or collapse. Tapping a pin on the map shows that hotel’s card in the list and highlights local landmarks and utilities in close proximity on the map.

Scroll sideways to see all 3 screens

1. , open full size 1. Start
2. , open full size 2. Pick a pin
3. , open full size 3. Full list

Room Availability Now Shows Right Under the Hotel Overview

A preview card under the overview answers “x rooms fit your stay” for the users dates and guest count. It lists each room’s beds, capacity and nightly price, with a prompt to jump directly to viewing the room details section below.

Scroll sideways to see all 3 screens

1. , open full size 1. Overview and rooms
2. , open full size 2. Area and reviews
3. , open full size 3. Room cards

Room Details Show What Each Room Adds, and What It Costs

The room sheet now opens with a key-facts line, “1 king bed · sleeps 2 · 600 sq ft”. These data points were selected as they are often the “deal breakers” that rule a room out even if the user liked what it had to offer otherwise.

To reduce stress tied to room reservation, the button now reads “Continue to checkout” which feels less committal than the “reserve room” copy it used before. Under it, a line ensures the user that they won’t be charged yet. A price breakdown and cancellation policy section also make it clear to the user exactly what they are paying for in total, before they proceed.

Scroll sideways to see all 2 screens

1. , open full size 1. Room and rate
2. , open full size 2. Extras and next step

Try the prototype out: search Maasai Mara, Aug 24 to 27, one adult. Then open a hotel and compare its rooms. (Please note that due to limitation in Figma’s prototyping capabilities some interactions such as typing in text boxes have been simulated with simple tap to fill)

Reflection and Next Steps

A Boutique Hotel Brand Didn't Fit an Aggregator Brief

Part of why I chose a hotel booking flow was Skirchi Lodge, the dream hotel I designed and fully branded in my senior-year graphic design class. I’m really proud of that project and wanted to bring it in as much as possible. But the prompt was about hotel aggregator sites, not a boutique collection, and that changes user priorities, especially location. Location matters much less at an all-inclusive resort that takes care of all your needs, and a boutique collection usually has one hotel per destination, so there’s nothing to search and compare. Designing for Skirchi Lodge would have sidestepped the actual aggregator problem.

So I dropped it. There are still references to Skirchi Lodge, but this is really a hotels.com type of product. I’d still like to come back to it someday: fully brand a site around the boutique problem, see where it overlaps with and differs from this one, and what a booking experience led by luxury hotel branding would look like.

The Hybrid Map and List View Is Novel, So It Deserves a Quick Test

I do think the v2 prototype solved a lot of the problems, so retesting it isn’t critical. But the map and list view is more novel than the way a lot of other hotels use it, and I want to make sure it’s usable and familiar to people. One or two more usability tests would rule out those concerns and go a long way in solidifying the design.