Limehome GmbH · 2024

Full case study

Multi-Room Booking Experience

Evolving the direct booking experience so groups and families can book several rooms in one confident pass — building trust at each step and moving demand away from OTAs.

Project type

Booking flow & conversion case study

Role

Lead Digital Product Designer

Platform

Responsive web — direct booking funnel

Year

2024

Limehome GmbH — Multi-Room Booking Experience

Key outcomes

Groups

Families and teams booking 2+ rooms in one flow

Direct

Less dependency on OTA channels

Trust

Prices, policies and totals visible before commitment

One pass

No restarting the search per extra room

Context

The funnel was designed for one guest, one room

The direct funnel assumed a single traveller. Anyone needing two or more rooms had to repeat the search, compare results in their head, and hope availability held — so many gave up and booked through an OTA instead.

Group demand is high value: longer stays, larger baskets, more services. Losing it in the funnel meant paying commission for guests who had already chosen Limehome.

Research

Who books for other people

Multi-room bookers are rarely booking for themselves. They are organising on behalf of a group and are accountable for the total, so their anxiety sits around cost and cancellation, not around choosing a nice room.

Business and UX goals mapped against the old booking flow — Goals & the old flow

Discovery and research numbers: interviews, Maze tests, session replays — Discovery & research

FigJam working board with opportunity mapping, flows and benchmarking — Working board

Problem framing and design principles — Problem framing

Goals, research and the working board behind the redesign.

Sofia, 38

Team lead booking for 5 colleagues

“I need one total I can put on a purchase order, and free cancellation.”

Goals

One invoice
Same building for the team
Flexible cancellation

Frustrations

Searching five separate times

Total only visible at payment

No way to hold rooms while approving

Daniel, 45

Family trip, 2 apartments

“If I can't see whether both apartments are on the same floor, I'll call.”

Goals

Rooms close together
Clear per-room price
Confidence in the total

Frustrations

Availability changing mid-flow

Empty results with no alternative

Unclear who is staying where

Two group-booking profiles from funnel interviews.

Opportunity

Make multi-room feel as simple as single-room

01Let guests express the whole party once and get one coherent set of options.

02Keep the running total, policies and per-room detail visible at all times.

03Remove dead ends when only part of the request is available.

04Make direct booking visibly the best, safest place to book.

Process

Finding where trust broke

01Analysed funnel drop-off to isolate where multi-room intent died.

02Ran usability tests with group-travel scenarios rather than solo tasks.

03Benchmarked OTA and competitor group flows to identify the expectations guests arrive with.

04Iterated prototypes in Maze until participants could explain their total and cancellation terms unprompted.

User flow

01SearchEnters city and dates for the whole party.
Pain pointOnly one room can be expressed
02CompareOpens several tabs to line up rooms.
Pain pointNo shared basket or running total
03SelectPicks rooms one at a time.
Pain pointAvailability shifts between selections
04CheckoutReviews totals and policies.
Pain pointTotal revealed too late to feel safe
05ConfirmNeeds proof of what was booked for whom.
Pain pointConfirmation lists rooms, not people

Where the old funnel lost group intent.

Wireframes

Destination & dates

Rooms + occupancy stepper

Reassurance strip

Party setup

Room 1 of 3 progress

Results grid

Persistent running total

Partial-availability alternatives

Room-by-room selection

Structure of the reworked funnel, one screen per decision.

Solution

Key changes introduced

01Party setup up front: rooms and occupancy defined once, carried through the flow.

02A room-by-room selection view with a persistent, always-correct summary.

03Partial-availability handling that proposes alternatives instead of an empty state.

04Transparent pricing: per room, per night and total, with policies inline before payment.

05Reassurance moments at the highest-anxiety steps — payment, confirmation, arrival details.

State machine

All available

Full party fits — continue with running total.

Partial

Some rooms fit; propose alternative dates or nearby properties.

Held

Rooms reserved during checkout with a visible timer.

Changed

Price or availability shifted — explain before payment.

Availability states the selection view has to handle honestly.

Concept directions explored and the final multi-room booking flow — Ideation → final solution

Configuring multiple units from the same room category — Future-proofing multiple units

Validation and outcomes with quantitative and qualitative results — Validation & outcomes

Concept directions, the final multi-room flow and the follow-up work.

Impact

What changed

01Groups complete a multi-room booking in a single pass instead of repeated searches.

02Fewer support contacts about totals, policies and what was actually booked.

03The pattern became reusable for longer-stay and corporate booking scenarios.

Reflection

What I took from it

Conversion work in booking is mostly trust work. Guests do not abandon because a flow is long — they abandon when they cannot predict what happens next.

Showing the total and the policy early felt risky and turned out to be the reassuring move.

Tools — Figma, FigJam, Maze, Hotjar, Jira

View the original Figma case study ↗All case studies

Next project

AI Content Platform

AnswerBite · 2023–2024