Designing for Multi-City Trips

A simple round-trip flight has two segments and one hotel. The trip detail view for this is straightforward: one flight card for each direction, one hotel card in the middle, done.

A multi-city trip has six segments, three hotels, and a timeline that spans ten days across three cities. Tokyo to Osaka to Kyoto, with flights and trains between cities, different hotels in each location, and activities scattered throughout. The simple list view that works for a round trip collapses under this complexity. Everything looks the same. The user cannot tell where they are in the timeline. Scrolling through six flight cards and three hotel cards without structure is disorienting.

Multi-city trips are where information architecture earns its name. The design needs to turn a complex collection of bookings into a scannable story: you start here, you go there, you end here. Along the way, these are the pieces that make it happen.

Timeline visualization

The most effective structure for multi-city trips is a timeline. Each city is a node on the timeline, connected by transport segments. The timeline runs vertically on mobile (top to bottom, matching scroll direction) and can run horizontally on desktop (left to right, matching reading direction).

Tokyo sits at the top. Below it, a flight segment card shows the connection to Osaka. Below that, Osaka with its hotel and dates. Then the transport to Kyoto. Then Kyoto with its hotel and dates. Then the return flight home.

The timeline creates a narrative structure. The trip has a beginning, a middle, and an end. Each node is a chapter. The connecting segments are transitions. The user reads the trip like a story rather than parsing a flat list of bookings.

City nodes get visual emphasis: larger text, a destination label, and the dates for that leg. Transport segments get a lighter treatment: a connecting line with a transport icon and duration. The visual hierarchy makes it clear which elements are destinations (the important parts) and which are transitions (the logistics).

Segment cards

Within each city node, the bookings are displayed as segment cards. The hotel card for Osaka shows the property name, dates, and key details. If there are activities booked, they appear as additional cards within the city's section.

Each card is tappable, expanding to full details when the user needs more information. But in the overview, cards are compressed to essential information only: property or flight name, dates, and status. This compression is critical for multi-city trips because showing full details for every booking would create a scroll depth that renders the timeline useless.

Status indicators appear on each segment card: booked, pending check-in, checked-in, in-progress, completed. For a multi-city trip in progress, the user can see at a glance which legs are complete, which are current, and which are upcoming. The current segment gets a visual highlight (green accent border) to answer the question "where am I right now in this trip?"

Overview compression

The overview tab for a multi-city trip needs to compress all bookings into a single, glanceable view. Six flights and three hotels cannot all show full details. The overview is a summary card that answers: where am I going, when, and what is the next thing I need to do?

Our overview card shows the city sequence (Tokyo, Osaka, Kyoto), the overall date range, the total number of bookings, and a "Next Up" component that highlights the next actionable item. "Check-in at Osaka hotel opens in 2 hours" or "Flight to Kyoto departs tomorrow at 9 AM."

The Next Up component is the most important element on the overview because it answers the most common question a traveling user has: "What do I need to do next?" For a trip in progress, this might change several times per day as the user moves through segments. The component stays current with the trip's state, pulling the most immediately relevant action to the top.

Navigation between segments

A ten-day, three-city trip creates significant scroll depth even with compressed cards. The user should be able to jump directly to a specific city or segment without scrolling through everything above it.

A segment navigator sits at the top of the trip detail view: a horizontal row of city names that the user can tap to jump directly to that city's section. The active city is highlighted with the primary accent color. Tapping "Kyoto" scrolls the view directly to the Kyoto section.

This navigation is essential for trips in progress. A user who has finished the Tokyo and Osaka legs and is now in Kyoto should not have to scroll through completed segments to reach their current city. They tap Kyoto and are immediately at the relevant section.

Conversation to multi-city booking

The conversation interface handles multi-city complexity through natural language. "I want to fly to Tokyo on April 3rd, then take a train to Osaka on the 6th, then fly from Osaka to Kyoto on the 9th" is a complex itinerary that the AI parses into discrete searchable segments.

In the chat, each segment appears as it is booked. The trip detail view then assembles all segments into the timeline structure. The conversation is the authoring tool. The trip detail view is the reading tool. Each interface is optimized for its purpose: conversation for flexible, iterative planning, timeline for structured review and management.

Building a multi-city trip view requires thinking of the trip as a narrative with chapters, not a database with rows. The timeline tells the story. The segment cards are the illustrations. And the segment navigator is the table of contents.

Nowah is an AI travel agent that searches and books real flights and hotels through conversation — no filters, no thirty open tabs. Plan your next trip.