Trip Planner — AI Assistant Design
PRODUCT DESIGN
Designed an AI agent from concept to launch — defining what it should do, how it should behave, and how it earns user trust while editing a live itinerary.
DOMAIN
Travel-tech
ROLE
Product designer
TIMELINE
2 months
Product Context
Trip Planner gives users a personalized, day-by-day itinerary. As trips got more complex, users struggled to adjust their own plans — moving activities, adding stops, or replanning around a flight delay — without breaking the structure of the trip. The team wanted an AI assistant to take over that editing burden.
The Problem
Product needed to design an AI assistant inside the itinerary from zero. The core challenge wasn't technical, it was behavioral: users needed to trust an agent enough to let it touch their trip, understand what it could and couldn't do, and feel like they were still in control even when the agent acted on their behalf.
My Role & Team
I worked as Product Designer alongside product and engineering to define the assistant's scope, behavior, and interaction model from the earliest concept stage through to shippable screens.
THE APPROACH
01
Discover
Ran a gap analysis of existing app usage to find where users struggled most self-editing their itinerary — flight edits, first-day planning, pace adjustments.
02
Hypothesize
Reviewed conversational/agent UX patterns and tested concepts around trust and reasoning display, identifying that silent edits — not missing features — were the real trust breaker.
03
Redesign
Defined the assistant's core functionality, quick-prompt system, reasoning-visibility model, and confirmation framework — plus the monetization layer for agent usage.
04
Test
Iteratively tested concepts on trust and reasoning display to calibrate a tone that felt conversational without pretending to be human.
05
Ship
Delivered production-ready UX, UI, and a full design system for the assistant, handed off to product and engineering.
06
Measure
Defined entry points and functionality directly from research gaps, not assumption — ensuring the shipped scope matches where users actually struggled.
Research Methods
Gap analysis of existing app usage (where users struggled most self-editing their itinerary)
Definition of core assistant functionalities based on highest-friction tasks
Competitive review of conversational/agent UX patterns
Iterative concept testing on trust and reasoning display
Key Insights
The highest-friction moments were flight-based replanning, adjusting the first day around arrival time, and re-optimizing a trip around personal pace and preferences — these became the assistant's core functions.
Users didn't know what to ask an AI assistant or how to phrase requests, leading to hesitation and unused entry points.
Trust broke down when the agent acted without explaining itself — users needed to see why the assistant made a change, not just the result.
The assistant needed clear boundaries: what it could do autonomously versus what required explicit user confirmation.
Tone mattered — the assistant needed to feel personal and conversational, while remaining unmistakably AI, not a simulated human.
Design decisions
Defined core functionalities around real friction, not assumed use cases. Flight ticket edits, first-day adjustment based on arrival time, pace-based itinerary suggestions, custom activity search, and hotel search were prioritized as the assistant's core capabilities — each tied directly to a task users struggled with themselves.
Design decisions
Added quick prompts to remove the blank-page problem. Since users didn't know how to phrase requests, I designed suggested prompts at key entry points, removing the guesswork of "what can I even ask this thing."
Design decisions
Made the agent show its reasoning. Rather than silently applying changes, the assistant surfaces what it's doing and why — turning an opaque action into a visible, checkable decision.
Design decisions
Built a clear confirmation model. I defined which actions the assistant could take autonomously and which required explicit user confirmation before changing the live itinerary — protecting user control over their own trip.
Design decisions
Designed the monetization layer for agent usage. Defined the paywall experience and credit-usage model for assistant interactions, integrating monetization directly into the agent experience rather than bolting it on separately.
Design decisions
Calibrated tone for credibility without pretending to be human. The assistant needed to feel warm and conversational to build rapport, while always being clearly identifiable as AI — avoiding the uncanny trust problem of an agent pretending otherwise.
What was delivered
Shaped the assistant's core experience end-to-end — from concept to key screens — defining how it should look, behave, and fit within the existing app.
Built the assistant's design system, including its main components, giving the team a consistent, scalable foundation for development.
Identified where the assistant should appear based on the specific gaps revealed during user research — placing it at the moments users struggled most, not by assumption.
Defined what the assistant should do and how it should act — its scope, behavior, and boundaries — establishing the foundation for every other decision.
A NOTE FROM THE DESIGNER
An assistant that edits your trip without explaining why isn't helpful — it's just another thing you have to double-check.