Website & booking

Testing a mobile travel search: dates, travellers and rooms

Testing a mobile travel search: dates, travellers and rooms

Testing a mobile travel search: dates, travellers and rooms

A practical mobile search test for dates, child ages and room allocation, with repeatable checks that follow the intended trip through to the results.

A practical mobile search test for dates, child ages and room allocation, with repeatable checks that follow the intended trip through to the results.

A practical mobile search test for dates, child ages and room allocation, with repeatable checks that follow the intended trip through to the results.

By Travelgenix

The Importance of Great Landing Pages To Convert Travel Sales

A mobile travel search can look tidy while asking the wrong question. Dates can change unexpectedly, a child's age disappears when a second room is added or the final summary hides the room arrangement. Each problem deserves a precise test. A screenshot of the homepage won't reveal it.

Choose a complete search task and follow the information through to the results. The aim is to check whether a customer can enter the intended trip, correct a mistake and recognise what the website searched. Use fictional traveller details and stop before making a booking. This is a practical usability review, with a separate accessibility assessment where needed.

Write the trip before opening the website

Start with a short fictional brief that includes dates, travellers and rooms. For example, two adults and children aged seven and twelve need one room for seven nights, crossing a month boundary. Give the tester that brief without explaining how the controls work. Watching where they hesitate is more useful than guiding them to the expected answer.

Record the phone, operating system, browser and starting address. A built-in browser opened from a social post may need its own check if that is a real route into your site. Use a second device or browser to investigate a specific problem, rather than collecting screenshots of every possible combination. Keep the task constant so the comparison means something.

Write down the expected summary before testing. That includes the complete date range, the number of nights where relevant and the allocation of guests to rooms. A successful search button press isn't enough. The resulting request still needs to represent the trip described in the brief.

Test selecting and correcting dates

Open the date control and choose a departure near the end of a month. Check that the month and year remain visible as you move to the return date. Then deliberately change the departure to a later day. Observe whether the return date stays valid, changes automatically or produces a clear request to correct it.

The GOV.UK Design System's dates pattern distinguishes dates people already know from dates they need to choose. It describes calendar controls as useful when the relationship between dates matters and recommends a text-entry option alongside a calendar dependent on JavaScript. That gives you a design discussion to have with your provider. It doesn't mean a government form component should be copied unchanged into a holiday search.

Try the supported input methods on the actual phone. Notice whether the keyboard covers an instruction or whether closing the calendar loses the selected dates. Read the summary aloud, including the year, and compare it with the brief. For flight and hotel combinations, check that labels distinguish flight departure from hotel check-in whenever those dates differ.

Follow every traveller into the room allocation

Change the number of adults, add each child and enter the requested age. Then reopen the traveller control to check that the information remains visible and editable. If the supplier requires age at a particular point in the journey, the label should explain that basis. Your team should verify the requirement rather than apply one assumption across every product.

Booking.com's child-policy documentation illustrates why these details matter. Its search and availability requests need children's actual ages, and the documentation distinguishes child pricing from whether a party fits a room. A child-rate rule alone does not establish physical occupancy. Treat the supplier's documented requirements as something your provider must map correctly through the search.

Now add a second room and move a traveller between rooms. Confirm that nobody disappears, appears twice or changes from child to adult without explanation. Remove that room and inspect the remaining allocation again. Those edits can expose problems that an unchanged default search never reaches.

Keep the result connected to the search

Once results appear, compare their summary with the brief and any changes the tester intentionally made. Check the dates, guest ages where displayed and room count. Open an offer, return to the results and edit the search. The customer should be able to understand which criteria apply at each step.

Test a correction after the results have loaded, such as changing the younger child's age. Note whether the website clearly performs a new search or continues showing the previous result. Don't assume a visually similar page contains refreshed availability. Ask the provider how the interface makes that distinction visible to the customer.

For a proposed two-room alternative, check the wording around the accommodation arrangement. A search result for two rooms should not imply that adjoining or connecting rooms are confirmed without supporting information. Keep room preferences and confirmed room attributes separate. This review concerns the accuracy of the search journey, rather than the broader sales brief covered by a travel enquiry form.

Record the failure in a way someone can fix

Describe each problem using the starting state, actions and observed result. "Adding room two removed the age of child one" gives the team a repeatable case. "Mobile feels awkward" doesn't identify the cause. Add a screenshot or short recording using fictional details and state what you expected to remain unchanged.

Prioritise issues that prevent completion or alter the trip, then review confusing labels and unnecessary steps. Our website performance guide covers the separate investigation of loading and responsiveness. Use the enquiry accessibility guide to plan a broader review of barriers. Neither a tidy mobile layout nor this set of checks establishes accessibility conformance.

Give the person responsible for the search tool one reproducible issue first. After a correction, repeat the original task and the edit that exposed it, then compare the final summary with the written brief. Keep that brief for the next change to your travel booking engine. It becomes a small, useful check that the customer's intended holiday survives the journey from phone screen to search request.

Explore the Travelgenix platform

See how the platform helps travel businesses sell more online, from award-winning websites and booking tools to AI marketing.