HotelArc is a self-initiated concept project. The starting observation was specific: people searching for hotels repeatedly return to listings they have already seen, compare the same two or three options multiple times, and continue browsing after finding acceptable choices. The problem is not access to options. It is that photos, pricing, and reviews are distributed across screens in ways that make direct comparison slow and stopping difficult to justify.
I wanted to understand which parts of the experience produce those behaviors and whether different information hierarchy and navigation decisions could address them.
Most hotel booking apps optimize for inventory. Users are shown hundreds of options across dozens of filters and multiple screen states. More information should help people decide. In practice, the way that information is organized often requires users to hold too much of the comparison in their head at once.
Through user interviews and competitive analysis, three patterns appeared consistently.
Taxes, fees, and cancellation terms appeared only at checkout. Users evaluating options based on the listed price had to commit to a specific hotel before learning the actual cost, which sent them back to search results to start the comparison over.
Photos, reviews, and pricing were separated across tabs or required extensive scrolling to find. Users moving between a hotel listing and search results to check different properties lost context each time they switched and often reopened listings they had already seen.
Sponsored placements and upsell modules pushed photos and reviews below the fold on most platforms. Users had to scroll past content the platform prioritized for commercial reasons to reach the information most relevant to their decision.
The project focused on four observable problems that appeared across research and competitive analysis:
Each translated into a specific decision about information hierarchy, navigation, or page structure.
Research, flows, wireframes, visual design, prototyping, and system design. Working through each stage independently made it easier to see how decisions in one area created constraints or opportunities in the next.
To understand how people evaluate accommodation options, I conducted user interviews and reviewed existing booking platforms. A few behaviors appeared consistently across both.
Users navigated back and forth between search results and individual hotel listings rather than moving forward through a sequence. Total pricing was not visible until checkout, which caused them to revisit earlier parts of the flow to recalculate costs for different options. Reviews and photos required scrolling past promotional content to find. Users also reported wanting flexible cancellation policies prominently surfaced rather than buried in a details panel.
The most consistent behavior: people kept searching after finding suitable options. Not because the options were inadequate, but because the experience provided no clear signal that the search was complete. There was always another listing to check. That pattern shaped the central design challenge: how to structure the experience so users have enough information to stop looking, rather than reasons to keep going.
Ashwin is a busy person who lives with his family. His wife loves travelling but high demand in summer means hotel rooms sell out quickly before he can commit. He needs an app with a better system.
Vishal believes life is short and should be enjoyed fully. He visits different locations with friends and family often. Finding and booking the best hotel or resort quickly would mean the world to him.
After building the personas I created an empathy map to organise user behaviours and context more clearly.
What users think and feel
What users see
What users hear
What users do
Mapped across four stages to identify where the experience breaks down and where the biggest opportunities sit.
The user flow was designed around a single sequence: search, selection, booking, confirmation. The goal was to remove branching paths and moments where users had to figure out how to move forward, since losing that forward momentum was one of the behaviors that sent people back to search results unnecessarily.
Wireframes focused on structure and hierarchy before any visual decisions. Four specific decisions shaped the layout, each tied to a behavior identified in research.
Decision 1: Lead with exploration, not a search form. Users who have not fully decided where to stay are forced into a search-first interaction on most apps, which requires a commitment before they have enough context to make one. The home screen leads with destinations, recommendations, and popular properties, giving users a starting point before they have committed to a specific place or date range.
Decision 2: Prioritize photos, reviews, and price on the hotel detail page. Users navigating between listings consistently returned to the same three pieces of information to evaluate options. Burying any of them below the fold required an extra step that broke comparison momentum. The hotel detail page surfaces all three near the top. Amenities and policies remain accessible but appear below the information users actually use to compare.
Decision 3: Show the complete cost before confirmation. Pricing that changed between the listing and checkout sent users back to search results to recalculate and compare other options. The payment screen presents a full summary before any action is required: hotel, dates, room type, and total cost including taxes and fees. Nothing appears for the first time at the final step.
Decision 4: Keep the booking flow linear. Users who hit a dead end or had to navigate back lost their place in the comparison process. Navigation is reduced to five consistent tabs accessible from every screen. Search, selection, booking, and confirmation follow a clear sequence with visible progress throughout.
Use slider to switch between Wireframe and Final Design
The prototype covers the full user journey from onboarding through payment confirmation, built in Figma. Working through the search and hotel detail screens in prototype form made the navigation decisions tangible and clarified how the payment summary information needed to be sequenced to avoid surprising users at the final step.
The onboarding introduces HotelArc's core value across three screens without asking for anything upfront. Each screen communicates a single idea clearly so users arrive at signup already oriented.
Sign up offers Apple, Google, and Facebook login to reduce the commitment barrier. For users who prefer email, the flow is short: verify, enter name, enter number, proceed. No unnecessary steps.
The home screen leads with cities, popular hotels, and recommended resorts. Exploration first, search second. From there users can browse, check availability, select a room, choose dates, and confirm payment in a linear flow with no dead ends.
The hotel detail page prioritises photos and reviews above the fold. Pricing and room selection sit below without being buried. The payment screen shows a full summary before confirmation: hotel name, check-in, check-out, total price including fees. No new information appears at the last step.
Profile, saved hotels, explore by category, and account settings round out the full product. The saved hotels empty state was designed to guide users back to browsing rather than leaving them on a blank screen with no clear next action.
The component library covers everything needed to build and scale the product consistently:
Euclid Circular A throughout. Six heading levels from 30px down to 14px, with line heights scaled for comfortable reading on mobile.
Coral pink background with the HotelArc location pin mark, built on a grid for consistency across iOS home screens.
This was my first attempt at running an end-to-end product design process independently. Working through research, flows, wireframes, visual design, prototyping, and system design in sequence made it clearer how a decision made in a wireframe creates constraints that show up later in the component library, and how a gap in research shows up in a flow that does not hold up under scrutiny.
Looking back, I would spend more time testing the hotel detail page and search results with actual users. Those two screens carry most of the comparison work and are where the hierarchy decisions either hold up or do not. Competitive analysis and interviews pointed toward what to prioritize, but the order and weight of elements on those screens deserved more external validation than the project included.
A future iteration would also explore a comparison mode, where users could view two or three hotels side by side without navigating between screens. That came up consistently during research as a behavior people were trying to approximate manually, and it is the most direct response to the pattern of reopening the same listings repeatedly.