Pondy Rentals set out to hold a whole trip in one place. Hotels, cars, and bikes booked in the same flow, and every booking still visible after the payment goes through.
Industry
Travel and Hospitality
Timeline
2 Months(2023)
Role
Product Designer
Context
The product
Pondy Rentals is a mobile booking product for travel around Pondicherry. A person books a room, a car, and a two wheeler in the same place, then keeps track of all of it from a single dashboard.
Why it mattered
Travel and hospitality runs on trust. If a person cannot see what they are paying for, or cannot find a booking they already made, they leave. The client asked for a product that stayed simple, modern, and reliable while covering three services at once.
03
Services placed under one roof: hotels, cars, and bikes
01
Dashboard holding every booking after payment
00
Times a person has to leave the app to finish a trip
The challenge
The client came with a clear brief, build something simple, modern, and reliable. Underneath it sat three separate points of friction, each one pulling the journey apart in a different way.
Hotel app
Search, choose, pay & book
Hotel app
Search, choose, pay & book
Hotel app
Search, choose, pay & book
User pain point
Booking a room, a car, and a two wheeler meant switching between different apps. Every switch reset the context: a new search, a new set of dates, a new account. The mental model of a single trip never survived the handover.
Friction in the flow
The path from wanting something to confirming it was longer than the decision itself. Each extra screen was one more moment for a person to pause, compare somewhere else, and leave before paying.
?
Hotel app
?
Car booking
?
Bike booking
After the booking
The path from wanting something to confirming it was longer than the decision itself. Each extra screen was one more moment for a person to pause, compare somewhere else, and leave before paying.
The solution
Four design decisions carry the product. Each one answers a friction point named above, and each one is visible on the screen rather than buried in a setting.
A trip needed three apps, and context was lost at every switch.
Decision
Structure the information architecture around the three services, hotels, cars, and bikes, and keep the search context in place while a person moves between them.
Result
Switching became a tab, not a new download. One place, one account, one trip.
Too many steps sat between the intent to book and the booking itself.
Decision
Give search and filters the strongest position on the screen, then keep layouts minimal with generous spacing so the action to take next is never in question.
Result
Selection happens faster, because the list narrows before the browsing begins.
People compare prices carefully, and hesitate when the final amount only appears at the end.
Decision
Place one summary screen before confirmation carrying the pricing and the booking details together, so the decision is made with everything in view.
Result
Nothing arrives as a surprise at payment, which is where trust is either earned or lost.
The discovery
None of those decisions started on a canvas. They started with how people already behave when they book travel, and what they are quietly worried about while doing it.
01
he starting point was travel booking behavior itself. Three moments kept coming up, and each one shaped a different part of the product.
Comparing prices
People weigh options against each other before committing, and want the real number early.
Checking availability
Availability is the first filter. If it is unclear, browsing stops being useful.
Handling cancellations
Plans change. What happens afterwards matters as much as the booking.
02
he starting point was travel booking behavior itself. Three moments kept coming up, and each one shaped a different part of the product.
Users value clarity and fast decision making during booking.
The strongest finding from studying travel booking behavior.
03
he starting point was travel booking behavior itself. Three moments kept coming up, and each one shaped a different part of the product.
Put the services side by side
If hotels, cars, and bikes share one structure, comparing and switching stops costing a download.
Move clarity earlier
Price and details belong before the payment, not after it, where they still change a decision.
Keep the trip after the booking
Cancellation is part of the journey, so the product needs somewhere for the trip to live.
04
The key user paths were mapped end to end, from choosing a destination through to managing what was booked. The map made one thing obvious: the journey did not end at payment, so the product could not end there either.
01
Choose the destination
02
Browse the
options
03
Book and
pay
04
Manage the
trip
Modify or cancel without starting again.
The impact
None of those decisions started on a canvas. They started with how people already behave when they book travel, and what they are quietly worried about while doing it.
A note on numbers: this project recorded its outcomes qualitatively. No baseline was measured before the redesign, so the improvements above are described the way they were observed rather than dressed up as percentages.
