By Marie Carlsson, HSG, September 27, 2026
How HSG classified the guest-facing features observed across 42 hotel booking journeys.
Table of Contents
Purpose
This coding guide is intended to support consistent observation of hotel booking-engine journeys from the perspective of a prospective guest using a mobile interface.
The survey was not designed as a technical audit, accessibility audit, legal review or professional UX assessment. It records what can reasonably be observed during a normal booking attempt without completing payment.
Scores should reflect the experience actually presented during the observation rather than assumptions about the capabilities of the booking-engine provider.
Where a feature or condition cannot reasonably be assessed, N/A is recorded rather than infer a result.
Unusual behaviour are recorded under Notable observations rather than creating new categories during the study.
Attribution limitation
This survey records the booking experience as presented to the guest. It does not attempt to determine whether an observed feature, limitation or usability issue originates from the booking-engine platform itself, the hotel’s configuration of that platform, the hotel website, or work carried out by a web developer or other third party.
Where the cause cannot be directly established, observations should be attributed to the observed booking implementation rather than to the booking-engine provider.
Accordingly, a finding such as poor navigation, prominent upselling, weak brand continuity or unclear information presentation should not be interpreted as evidence that the underlying booking-engine product necessarily behaves this way across all hotels using it.
How to read the scores
Some fields are descriptive, recording what was present or how the booking journey was structured; others are evaluative, assessing the observed guest experience using the categories defined below. Descriptive categories should not be interpreted as inherently good or bad. Where a field could not reasonably be assessed, N/A was recorded rather than forcing a classification.
1. Booking flow and selection
Booking environment off-site: yes / no
Records whether beginning the booking process takes the guest away from the hotel’s main website environment.
Yes — the booking journey opens on a clearly separate domain, externally hosted environment or visibly separate booking site.
No — the booking process remains within the hotel website/domain or appears fully integrated into it.
Does not judge quality. This is a descriptive field only.
Number of major booking steps
Count distinct stages requiring the guest to progress to another stage or screen. Guest/personal details and card/payment details count separately when presented as separate stages, but count as one step when combined on the same continuous page.
Typical major stages may include:
- date/guest selection
- room selection
- rate selection
- extras/upsells
- guest details
- review
- payment
Does not count opening room descriptions, cancellation details or other informational overlays as separate booking steps.
Where several activities occur on one continuous page, they are counted as one step unless the guest must explicitly progress to a distinct new stage.
Room presentation: poor / adequate / strong
Assesses how effectively rooms are presented for selection.
Poor — insufficient or confusing room information; weak or missing imagery; important differences between rooms difficult to understand.
Adequate — sufficient information to understand the room and make a reasonable choice, but presentation is limited or requires additional effort.
Strong — clear room naming, useful imagery and relevant information make room options easy to understand and distinguish.
Does not score visual attractiveness alone.
Upsells/extras: none / present / prominent
Records the degree to which optional extras are presented during the booking flow.
None — no meaningful extras or additional purchases offered.
Present — extras are available but do not dominate the booking process.
Prominent — extras occupy substantial attention or space, significantly interrupt progression, or are strongly emphasised.
Exceptional implementation problems, such as an unusually long list of extras pushing the booking summary far down the page, should also be described under Notable observations.
Ease of changing dates/room/rate: difficult / adequate / easy
Assesses how easily a guest can revise core booking choices after beginning the journey.
Difficult — changing a selection requires substantial backtracking, restarting, loss of context or unclear navigation.
Adequate — changes can be made but require some additional navigation or effort.
Easy — clearly available controls allow dates, rooms or rates to be changed with little disruption.
Ease of discarding selected room: difficult / adequate / easy
Assesses how easily the guest can remove or abandon a selected room and choose another.
Difficult — no obvious removal/change mechanism, substantial backtracking required, or selection appears difficult to undo.
Adequate — possible with some additional navigation or an indirect action.
Easy — clear remove/change control or obvious route back to room selection.
Booking summary visibility: persistent / partial / final-only / absent
Records when the guest can see a meaningful summary of the developing booking.
Persistent — summary remains visible or readily accessible throughout most of the booking process.
Partial — summary appears during some stages but disappears during others.
Final-only — meaningful consolidated summary appears only near the final review/payment stage.
Absent — no clear consolidated booking summary is presented.
A summary should normally include at least key information such as dates, room/rate and price.
Progress indicator: absent / limited / clear
Assesses whether the booking engine communicates where the guest is in the booking process.
Absent — no meaningful indication of progress.
Limited — some indication exists, but stages or remaining steps are not consistently clear.
Clear — current stage and overall progression are easy to understand.
A simple page heading does not necessarily count as a progress indicator.
Back navigation: difficult / adequate / easy
Assesses whether the guest can retreat through the booking journey without becoming trapped or losing control.
Difficult — no clear back/previous controls; browser back is unreliable or requires repeated use; returning to earlier stages or the hotel site is awkward.
Adequate — back navigation is possible but inconsistent, indirect or requires extra effort.
Easy — clear and reliable controls allow movement to previous stages or return to the hotel environment.
This is distinct from changing dates/room/rate. It assesses navigation through the flow itself.
Guest detail/form burden: light / moderate / heavy
Assesses how much input is demanded of the guest.
Light — mainly information necessary to identify the guest and complete the booking/payment.
Moderate — some additional optional or non-essential fields, but the form remains manageable.
Heavy — numerous additional fields, questions, or required inputs that materially increase effort.
2. Information and price transparency
Cancellation terms visibility: poor / adequate / clear
Assesses how easily cancellation conditions can be found and understood before commitment.
Poor — conditions are missing, hidden, difficult to locate or appear only very late.
Adequate — conditions are available but require additional effort, expansion or navigation.
Clear — cancellation conditions are readily accessible, understandable and available at an appropriate point before the guest commits.
Does not assess whether the cancellation terms themselves are generous or restrictive.
A score is not reduced because personal details were requested first; timing relative to personal-information entry is recorded separately below.
Rate/inclusion clarity: poor / adequate / clear
Assesses whether the guest can understand what a particular rate includes and how it differs from alternatives.
Consider:
- breakfast or meals
- refundability
- packages or benefits
- occupancy conditions
- other significant inclusions
Poor — rate names or inclusions are unclear and meaningful differences are difficult to determine.
Adequate — sufficient information exists but requires some interpretation or additional opening of details.
Clear — inclusions and important differences between available rates are readily understandable.
This field measures what the rate contains, not whether the final price is transparent.
Taxes/fees visibility: poor / adequate / clear
Assesses how clearly compulsory taxes, fees or charges are disclosed.
Poor — charges are hidden, introduced late or difficult to interpret.
Adequate — charges are disclosed but require expansion, calculation or additional effort to understand.
Clear — compulsory charges are clearly identified and presented early enough for the guest to understand the likely total.
Price progression: poor / adequate / clear
Assesses whether the guest can follow how the total booking price develops through the booking process.
Poor — price changes are difficult to follow, important additions appear without clear explanation, or the guest can easily lose track of the total.
Adequate — overall price can be followed but requires some attention or appears inconsistently.
Clear — the developing total remains understandable as rooms, rates, extras and other charges are added or changed.
This field measures how the total develops, rather than what each rate includes.
Payment information visibility: poor / adequate / clear
Assesses whether the guest understands the payment requirement before committing.
Consider:
- when payment is due
- whether payment is immediate or later
- deposit/prepayment requirements
- card guarantee requirements
- relevant payment conditions
Poor — payment requirements are absent, unclear or only become apparent at the final moment.
Adequate — payment information is available but requires additional effort to locate or interpret.
Clear — payment requirements are readily understandable before the guest reaches commitment.
Personal details before key terms: yes / no
Records whether the guest must begin supplying significant personal details before important booking conditions are reasonably available.
Yes — name, email, address or similar details must be entered before key rate, cancellation, payment or total-price information can reasonably be reviewed.
No — key terms can be reviewed before significant personal details are required.
Does not count a simple guest-number or occupancy selection as personal details.
Currency display: local only / alternatives available
Local only — prices are displayed in one booking/local currency with no visible alternative currency option.
Alternatives available — the guest can display prices in one or more alternative currencies.
This field is descriptive and should not imply that the alternative currency is the currency in which payment will ultimately settle.
3. Confidence and continuity
Brand & ambience continuity: diminished / neutral / retained / seamless
Assesses how much the hotel’s identity and presentation carry into the booking journey.
Diminished — hotel identity is noticeably weakened and the booking environment feels substantially separate or generic.
Neutral — some hotel identification remains, but the booking environment has little connection to the hotel’s wider presentation.
Retained — hotel identity, styling or visual cues remain recognisable throughout the booking journey.
Seamless — the booking environment feels effectively continuous with the hotel website, with little perceptible transition.
Does not score the attractiveness of the hotel’s branding.
Booking-engine/provider branding: absent / subtle / prominent
Records the visibility of the external booking-engine/provider identity.
Absent — no provider branding is readily visible.
Subtle — provider name, logo or domain is visible but unobtrusive.
Prominent — provider branding is conspicuous or competes noticeably with hotel branding.
This is descriptive and does not in itself indicate a good or bad booking experience.
Secure payment wording/icons: poor / adequate / clear
Assesses visible reassurance concerning security of payment or transaction handling.
Poor — no meaningful payment-security reassurance is visible where it would reasonably be expected.
Adequate — security wording, iconography or reassurance exists but is limited or easy to overlook.
Clear — meaningful and readily visible security reassurance is presented around the payment stage.
Does not independently verify technical security claims as part of this survey.
Recognisable payment methods: yes / no
Yes — a familiar payment method is clearly identifiable before commitment, either through recognizable payment/card branding or through an unambiguous payment interface such as standard card-entry fields.
No — the payment method is not identifiable or remains unclear before commitment.
This field records visibility, not whether the available payment methods are objectively sufficient.
Hotel contact/identity information: yes / no
Yes — meaningful hotel identity or contact information, such as the property name together with an address, phone number or usable contact/help route, remains readily accessible through most of the booking journey.
No — meaningful hotel identity/contact information is absent or appears only briefly, such as on the initial room-selection stage.
A logo alone does not qualify as contact information.
4. Navigation and interface behaviour
Mobile navigation: difficult / adequate / easy
Assesses the practical ability to move through and operate the booking journey on the mobile interface being observed.
Difficult — controls are awkward, obscured, poorly responsive, difficult to tap, require excessive scrolling or otherwise hinder navigation.
Adequate — journey is usable but contains minor friction or requires extra effort.
Easy — controls, movement and interaction are consistently straightforward.
Unusual mobile-specific problems are recorded under Notable observations, such as the onscreen keyboard obscuring essential booking information.
Interface stability/performance: poor / adequate / strong
Does the interface behave properly while I’m moving around and operating it?
Poor — slow loading, visible layout shifting/wobbling, elements not fitting the viewport, keyboard obscuring required fields or controls, taps not registering reliably, or other technical behaviour materially disrupts completion.
Adequate — minor delays or display issues occur, but the booking remains usable without significant disruption.
Strong — pages load and respond reliably, layout remains stable, controls fit the viewport, and no material technical interference is observed.
Information organisation: confusing / adequate / clear
Assesses how logically booking information is arranged.
Confusing — important information is fragmented, poorly grouped, difficult to scan or presented without an obvious hierarchy.
Adequate — information can be understood but organisation requires some effort.
Clear — information is logically grouped, easy to scan and presented in an understandable hierarchy.
This field concerns where and how information is organised, not how additional detail opens.
Information presentation/readability: poor / adequate / clear
Assesses how clearly, completely and readably booking information is presented to the guest.
Poor — information is difficult to scan or understand because of dense text, weak hierarchy, awkward formatting, obvious omissions, or an overall impression that important information is incomplete or difficult to locate.
Adequate — information is readable and broadly complete, but presentation is plain, dense, uneven or requires some effort to scan or piece together.
Clear — information appears complete and is presented in a highly readable, easily scannable form using appropriate headings, spacing, bullets, concise wording and a clear visual hierarchy.
Completeness refers to the guest-facing impression that sufficient booking information has been provided; it does not constitute a legal or technical assessment of whether every required item is present.
Detail presentation method: inline / modal-overlay / separate page / mixed
A descriptive field recording the principal way additional room, rate or booking detail is presented.
Inline — information expands within the existing page.
Modal-overlay — information opens in a modal, panel or overlay while retaining the underlying booking context.
Separate page — guest is taken to another page or distinct screen.
Mixed — more than one method is used to a meaningful degree.
Quality is not scored in this field.
Pop-up interference: none / minor / intrusive / severe
Assesses whether unrelated or secondary overlays interfere with the booking process.
None — no interfering pop-ups observed.
Minor — pop-up appears but is easily dismissed and causes little disruption.
Intrusive — pop-up obscures meaningful content, interrupts selection or requires noticeable effort to dismiss.
Severe — pop-up substantially prevents or disrupts progress through the booking journey.
Cookie banners, chat tools, promotional offers and email capture are assessed according to their effect rather than their type.
5. Overall guest experience
Overall ease: difficult / adequate / easy
A holistic assessment of how straightforward the observed booking journey was from the guest perspective.
Difficult — significant friction, confusion, navigation problems or information-access problems materially hinder the booking process.
Adequate — booking can be completed without major difficulty but contains noticeable friction or weaknesses.
Easy — booking journey is straightforward, understandable and requires little unnecessary effort.
This score should be informed by the whole journey but should not replace the individual observations above.
Notable observations: free text
Use this field for behaviour that is:
- unusual
- particularly good or poor
- difficult to capture in the coded fields
- useful for explaining another score
- potentially valuable as a later case example
Examples include:
- onscreen keyboard obscures most of booking summary
- exceptionally long upsell list pushes total far below the fold
- no visible way to exit booking engine
- personal details remain populated after returning to an earlier stage
- currency conversion explicitly described as approximate
- room-details modal preserves position particularly well
Keeping observations factual and describe what happened rather than attributing motives to the hotel or provider.
General coding rules
1. Code what is observed, not what is assumed.
Do not infer technical capabilities, settlement currencies, data-retention practices or
provider intentions.
2. Use the same test journey where practical.
Use broadly comparable dates, occupancy and booking behaviour across properties
where possible.
3. Do not penalise the hotel for its commercial terms.
A restrictive cancellation policy can still be presented clearly. The survey assesses
presentation and usability, not whether the policy is generous.
4. Separate presence from quality.
Descriptive fields such as engine location, currency options and presentation method
should not automatically affect quality scores.
5. Use N/A / not observed rather than forcing a score.
6. Do not create new categories partway through the study.
Capture unusual cases in Notable observations and decide after the full observation set
whether they represent a recurring pattern.
7. Apply the category that best describes the overall observed implementation.
Do not change a score because of one minor exception unless that exception materially
affected the guest journey.
8. Record the observation date.
Booking engines can change, so findings should be treated as observations of the interface
at a particular time.
9. Avoid double-penalising where possible.
A single problem may legitimately affect more than one field, but each field should still be
assessed according to its own definition.
10. When uncertain between two adjacent categories, choose the less extreme
category and explain the ambiguity in Notable observations.