BookBerry × OutglowShipped project
BookBerry: direct hotel booking where price and terms are clear before payment
A direct booking engine for mobile and desktop: the all-in price and the terms are visible at every step, and the design system is ready to move into code.
- Problem
- Hotels pay OTAs a commission on every booking, and guests on the hotel's own site lack a reason to book direct
- My role
- Product design of the flow, screens and design system — together with the Outglow agency
- Timeline & team
- 2026 · BookBerry AI + Outglow agency
- Outcome
- Piloted with a partner hotel. I don't publish the numbers — we track booking conversion and the share of direct bookings
DBS app — a direct booking engine for hotel guests (B2C) · Mobile web + desktop · Figma (variables, components)
01 · Problem
Booking direct shouldn't be harder than booking on an OTA
Guests need to
- see the total price with all fees before paying, not on the last step;
- understand cancellation terms and extras before entering card details;
- book from a phone in a few steps.
The hotel needs to
- get bookings directly, with no OTA commission;
- show rooms and rates under its own brand.
Context
BookBerry AI (formerly BnBerry) brings hotels guests from AI assistants, Google and creators. DBS app is the B2C part of the platform: a booking engine under the hotel's brand. The pilot was built for a partner hotel together with the Outglow agency.
02 · Key decisions
Price and terms are clear before payment — at every step
Decision 1
Nightly prices right in the calendar
Guests see which dates are cheaper straight away, so there's no need to leave and compare on an OTA. A summary like “4 nights · 2 adults · 1 room” and a single button are always at the bottom.
Decision 2
One “includes all fees” price
From the results onwards the price covers the whole stay and is marked “includes all fees”, so the total doesn't jump on the last step.
Decision 3
Terms before the card form
“Review & book” shows the booking summary with “Edit”, the total, the rate and free-cancellation terms before the payment form. Apple Pay first, card second.
Decision 4
An error isn't a dead end
Every error has its own screen and a next step: on payment failure — “Try again” and “Update your payment method”, on a failed request — “Back to rooms”.
All screens (10)
Desktop and other screens
Desktop follows the mobile logic in two columns: price, dates, terms and extras are pinned on the right; before payment — “You won't be charged yet” and a “Pay today / Due at property” breakdown.
03 · Design system
A design system that maps to code without translation
Structured like the code
Three token layers — Core → Semantic → Component (over 1,200 variables). The library is split into the same sections as the code: Primitives, Actions, Forms, Navigation, Feedback, Patterns.
A spec sheet for every component
One-sentence purpose, anatomy, props named exactly as in code and a draft · ready · deprecated status. Plus domain patterns: RoomCard, a 6×7 Calendar, PriceSummary.
All screens (3)
04 · Results
How we measure
I don't publish the pilot numbers. We check the solution against four metrics:
| Metric | Why | Expected |
|---|---|---|
| Booking conversion | Share of sessions from picking dates to confirmation — the main signal the flow works | ↑ up |
| Share of direct bookings | How many bookings the hotel gets without an OTA and its commission | ↑ up |
| Time to book | From picking dates to payment: shows whether there are extra steps | ↓ down |
| Recovery after errors | Share of guests who still complete the booking after a payment failure | ↑ up |