A hotel booking audit should follow one guest task through every state instead of judging isolated screens. This trace records what changes, which errors block progress and where the evidence ends.
Define one guest task before opening the booking engine
Choose a real route into the booking path and a task specific enough to reproduce. For example: a guest arriving from a mobile brand search wants 1 refundable double room for 2 adults, checking in on a Friday and leaving on Sunday. Record the country, currency, language, device width, entry URL, date and any loyalty or promotional state.
This is not a persona exercise. It is a test specification. Another guest may need connecting rooms, accessible accommodation, a child rate or a company invoice. Those are separate tasks with different failure conditions. A path that works for the simple task has not automatically passed the others.
Write the completion condition before testing. It could be reaching the final review without payment in a provider sandbox, or completing an approved test booking and finding the matching property record. Do not substitute “the button was clickable” for the guest's outcome.
Also record constraints you cannot safely cross. If the only available environment would create a live nonrefundable charge, stop before payment and mark the later states unverified. The audit remains useful when its boundary is explicit.
Trace every decision and every changed value
Run the task at 390px without skipping directly to a familiar screen. At each step, record what the guest entered, what the system preserved, what new information appeared and what the next control promises.
Scroll the table sideways to read every column.
| Stage | Decision to verify | State to retain |
|---|---|---|
| Entry | Does the path reflect the source promise? | Offer, property, locale and campaign context |
| Search | Can the guest set dates and occupancy accurately? | Dates, adults, children and room count |
| Room | Can the guest distinguish room options? | Room name, capacity, essential features |
| Rate | Can the guest compare total commitment? | Inclusions, cancellation, taxes, fees, currency |
| Guest details | Are required inputs and their purpose clear? | Selections, validation and privacy context |
| Payment handoff | Is the amount and provider transition understandable? | Total, currency, payment state, return behavior |
| Confirmation | Does the guest know the booking succeeded? | Reference, stay details and next action |
Capture screenshots or notes for each state using nonpersonal test information permitted by the provider. A single screen recording can help with sequence, but the worksheet makes changes easier to compare. If the currency, room, cancellation condition or total changes, identify exactly where.
Check whether the guest can compare the actual commitment
A room card is not useful merely because it has a price and a button. The guest must be able to tell what period and occupancy the price covers, which rate conditions apply, what is included and what amount they are expected to commit to next.
Record every price shown from entry to final review. Note whether it is per night, per stay, per person or for the room; whether taxes and mandatory fees are included; and whether the currency is stable. Do not infer legal or pricing compliance from this editorial checklist. Applicable disclosure requirements depend on the market and should be reviewed by qualified people.
Treat cancellation and payment conditions as decision information. “Flexible” is not a complete rule if the deadline, time zone or penalty is hidden. If 2 rates have the same room image and similar names, compare whether the meaningful differences are visible before selection.
When the engine changes the guest's selection because inventory changed, the change needs a clear state. Silent substitution is more serious than a spacing defect because the guest may continue under the wrong assumption. Record the original choice, substituted choice and any notice rather than judging the screen from memory.
Test empty, invalid, unavailable and retry paths
A booking path often looks complete when every input is valid and inventory is available. Deliberately test states that require the guest to understand and recover: no dates, checkout before check-in, occupancy beyond room capacity, unavailable dates, an invalid required field and a failed or interrupted handoff where a safe test is possible.
WCAG 2.2 Success Criterion 3.3.1 requires an automatically detected input error to identify the affected item and describe the error in text. Color or an icon can supplement that description but does not replace it. The related Labels or Instructions criterion requires labels or instructions when content needs user input. W3C's Error Identification explanation and Labels or Instructions explanation provide the accessibility basis for these checks. They do not establish hotel conversion impact.
For each error, ask whether the guest knows what happened, which value caused it, how to fix it and whether valid work was preserved. A generic “Something went wrong” after 5 completed fields shifts diagnosis to the guest. An unavailable room message that erases the dates creates a second task.
Check focus after submission with a keyboard and a screen reader where the test scope permits. If the error appears above the viewport while focus remains on the button below, it may be technically present but practically difficult to find. Record the actual behavior and environment rather than claiming universal failure from one browser.
Prioritize a fictional booking trace
Consider a fictional property, Cedar Court Hotel. The test task is 1 refundable room for 2 adults, 14 to 16 November, entered from a mobile direct-booking page. Assume this is a provider sandbox with no real inventory or payment.
Scroll the table sideways to read every column.
| Finding | Status | Reason for priority |
|---|---|---|
| The search retains dates and occupancy on the room list | Measurable and passed in this trace | Core task state is preserved |
| A room is labeled refundable, but the cancellation deadline appears only after selection | Uncertain | The guest cannot compare the condition at the choice point |
| The displayed total changes from TRY 18,400 to TRY 20,240 at final review when a mandatory charge appears | Blocked pending pricing review | The commitment changes late; legal interpretation is outside this audit |
| Submitting an empty surname shows a red outline with no text message | Blocked | The error is not described in text |
| After correcting the field, the engine keeps the room, rate and dates | Measurable and passed in this trace | Recovery does not create repeated work |
| The sandbox confirms a booking reference, but no analytics access is available | Measurement uncertain | Interface completion and event collection are separate checks |
The first repair sequence is not a visual redesign. Review the late mandatory charge with the appropriate commercial and legal owners, add a descriptive surname error and expose the cancellation deadline where rates are compared. Then rerun the same task. Analytics verification follows once the interaction path is stable and access is available.
The arithmetic check is straightforward: TRY 20,240 minus TRY 18,400 equals TRY 1,840, a 10% increase relative to the earlier amount. The example does not claim that such a charge is common, lawful or present on a real site. It only demonstrates how to record a changed commitment.
Keep interface completion and business completion separate
A browser confirmation, analytics event and property-system reservation answer different questions. The first shows what the guest saw. The second shows what the measurement implementation recorded. The third establishes whether the property received the booking under the expected details.
Where authorized, reconcile a test reference across those systems. Check whether reloading or returning to confirmation duplicates the analytics event. If the provider redirects across domains, verify the documented integration rather than assuming sessions, campaign parameters or consent states are preserved.
When records are unavailable, mark the boundary in the repair brief: “Booking confirmation observed in sandbox; property record and analytics event not accessed.” That statement helps the next owner continue the check. “Booking flow works” would exceed the evidence.
Do not use this interaction audit to calculate direct-booking profitability. Channel cost, cancellations, completed stays and net revenue belong to a separate commercial analysis with consistent outcome definitions.
Write a repair sequence that can be retested
Give each issue a task, evidence, owner, dependency and retest condition. Rank it by whether it blocks the task, changes the commitment, creates uncertainty at a decision point or affects a limited presentation detail. Avoid a numerical “UX score” unless its method and decision use are defined.
A useful repair item reads: “On mobile, an empty surname produces only a red outline. Add a persistent text description associated with the field, move focus or provide a discoverable error summary according to the implementation pattern, preserve the selected room, and rerun the invalid and corrected submissions.” It is specific enough for design, development and QA to share.
Retest the original task after changes, then add the next consequential variant, such as an unavailable date or child occupancy. Keep provider, browser and date details with the result because availability and integrations can change.
For help reviewing a booking experience from entry promise through confirmation, see MORE's design work or describe the path through the contact form.
