Building Our Own Booking Screens — Branding and Booking UX

Introduction

You see it all the time on hotel and rental websites: you press "Book now" and suddenly land in an external booking system that looks nothing like the site you were just on. All that work building a site with a distinct feel, undone at the exact moment of booking — and some visitors get uneasy and leave.

In this article, we share the screen design and branding thinking behind building the booking screens ourselves for a private rental villa's official site.

Building the shortest possible booking flow

Finishing in four screens

We trimmed the booking flow down to four screens: search, guest details, card registration, done.

We were ruthless about cutting input fields. The booking management system has plenty of slots for company name, fax number, and the like, but our form carries only the five required fields plus optional address and requests. We worked from the assumption that every extra field costs you bookings, and dropped anything the operator can live without.

Show search results near where people tapped

In the first version, results appeared below the search button. Testing on a phone, though, pressing the button didn't seem to change anything — you had to scroll before you noticed the price. That reads as "I tapped it and nothing happened."

So we moved the results above the form, right beneath the heading. Press the button and the price changes within your field of view. It's a small change with a big difference in how it feels. We also added an attribute that announces updates (aria-live) to the results area so people using a screen reader hear the change too.

Make the pinned mobile button two-stage

On mobile we keep a booking button pinned to the bottom of the screen. But showing the date fields there from the start would mean the bottom quarter of every page is taken up by a booking form.

So we made it two-stage: the first tap opens the date fields, the second moves you to the booking page. The date selection is shared between the booking card on the home page and the bottom bar, so it never contradicts itself no matter which one you use.

Getting "fully booked" right

Distinguishing "fully booked" from "we couldn't check"

Availability comes over the network, so sometimes the request fails. If you casually display "fully booked" in that moment, you lose a booking on a night that was actually open.

Internally the system draws a clear line between four states — available, fully booked, another guest is completing payment, and unable to check — with different wording for each. When a date is booked, it automatically looks for open dates just before and after and suggests them, so guests never hit a dead end.

The "another guest is paying right now" state

With a whole-property rental there's only one unit of inventory, so once someone starts the booking process, nobody else can take those dates for the next half hour or so. Labeling that "fully booked" causes confusion when the process is abandoned and availability reappears.

So we created a dedicated message: "Another guest is currently completing payment." Being honest about the state turns out to be the presentation that generates the fewest complaints.

Carrying the brand into every corner of the screen

Unifying the look with design tokens

Every visual ingredient — color, spacing, corner radius, type size — is managed centrally as "design tokens," and specifying them directly on individual screens is off-limits. We decided at the outset that the axis is quiet refinement: no flashy gradients, no blinking buttons, no coupon-site-style price shouting.

The booking form is no exception. Rather than leaving an external service's default styling in place, we matched the typeface, colors, and button shapes to the public pages, so the feeling of "I'm still at the same property" holds right to the end.

Decide your priorities up front

Design discussions tend to slide into matters of taste. On this project we documented the priority order at the very beginning: mobile usability > clarity of booking completion > readability > loading speed > brand texture > desktop ornamentation.

Never lose what someone typed

You make a mistake in the booking form, go back a page, and everything you typed is gone — few experiences drive people away faster. On error we return the entered values straight back to the screen, and search conditions are remembered in the browser so they're restored the next time you open it.

Wrapping up

Three things mattered most in building our own booking screens.

1. The shortest possible flow — pared down to four screens and five required fields, leaving little room for hesitation
2. Show the state honestly — distinguish fully booked, payment in progress, and unable to check, and never create a dead end
3. Carry the brand to the end — design tokens keep the official site's atmosphere alive all the way through the booking screens

How payments work, from card registration to automatic charging, is covered in "Stripe payment design for stay bookings," and the overall site structure in "Site Structure That Leads Straight to Booking."