Trip Itinerary

Organize flights, stays, reservations, activities, and free time into one day-by-day trip plan. This example brings Itinerary and Bookings together so travelers and booking teams can find the next task without losing context.

It includes representative records such as Hotel check-in and Museum district walk. Use the screenshot to study the layout, then adapt its components and product states to your own design system.

Trip Itinerary
Use this template in Figr

Template facts

Screen

Calendar

Primary action

Add plan

Pattern

Calendar

State

Default, loading, empty, error, permission, success

Design system

Configurable product UI theme

What this screen helps users do

Product teams need to add plan while keeping days, bookings and exceptions visible. The interface should show what changed and who should act next.

Key elements

  • Main workspace: Itinerary gives users an obvious place to start.
  • Supporting view: Bookings keeps the related context close.
  • Primary action: Add plan stays visible when people need it.
  • First signal: Days shows a useful value (6).
  • Second signal: Bookings gives additional context (9).
  • Sample record: Hotel check-in.
  • Next record: Museum district walk.

States worth designing

  • No slots in selected range: say what changed, protect progress, and offer a clear next step.
  • Timezone mismatch: say what changed, protect progress, and offer a clear next step.
  • Booking conflict: say what changed, protect progress, and offer a clear next step.
  • Booking confirmed: say what changed, protect progress, and offer a clear next step.
  • Reschedule failure: say what changed, protect progress, and offer a clear next step.
  • View-only permission: say what changed, protect progress, and offer a clear next step.

Where this screen sits in the flow

Itinerary → Bookings → Add plan → Review outcome

Patterns used

Calendar, Itinerary, Bookings, contextual actions, error recovery

Why these choices work

Show the timezone, resource and conflicting time slots before confirmation. Recovery should preserve the selected date and context.

Pay attention to itinerary and bookings. People need to distinguish Hotel check-in from Museum district walk. Keep days visible, especially when a record changes owner or status.

Before this screen reaches handoff, verify keyboard focus, empty and permission states, and what happens after someone chooses “Add plan”. Make error recovery as clear as the happy path.

Related screen examples to explore next: Travel Booking Checkout, Reservation Management, Flight Search.

Start from this in Figr

Design a trip itinerary screen inside our existing product. Use our current components, tokens and content language. Include Itinerary and Bookings views, credible records like Hotel check-in, and a clear “Add plan” action. Use our product permissions and show loading, empty, error and success states. Keep the output editable in Figma.

Open Figr