From Answers to Itineraries: Designing an AI Travel Companion That Turns Conversation Into Plans
Context
Turom — to roam, to explore, to belong — is a travel companion app built around a simple promise: planning a trip should feel like talking to a well-travelled friend, not managing a spreadsheet. Phase 2.0 was the leap from a content-led travel app (guides, destinations, tips) to an AI-native one, where a conversation with the assistant becomes the primary way trips get made.
The entire phase was designed on top of a design system mapped 1:1 to shadcn/ui — every token, component, and block in the file mirrors its code counterpart.
The Problem
AI chat is easy to add and hard to make useful. The failure mode is well known: the assistant gives a beautiful, articulate answer — and the user is left holding a wall of text.
- AI responses were informative but inert — nothing in them could be acted on
- Trip planning lived across disconnected surfaces: chat, explore, saved places
- Itineraries were static documents, not living plans users could reshape
- Rich answers created a new burden: manually transcribing suggestions into a plan
The defining insight of the phase: in a travel app, the AI's answer is not the product. The itinerary it becomes is.
Behavioral Insight
Watching how travellers actually use AI assistants surfaced three consistent patterns:
- Questions are situational, not abstract. People don’t ask "what’s good in Rome" — they ask "I’m in Rome right now, what should I do this evening, nearby?" Context (time, location, energy level) is the real query.
- Reading is not planning. Users trust a recommendation only once it’s theirs — added, reordered, edited. An answer they can’t manipulate stays the AI’s opinion, not their plan.
- Plans are living objects. Real trips get reshuffled constantly — a place gets skipped, lunch runs long, a day swaps order. If editing the plan is harder than asking again, the itinerary dies after day one.
The design was asking users to read — before helping them decide and act.
Design Hypothesis
If we treat every AI response as a potential plan, make the conversation-to-itinerary conversion a single action, and make the resulting itinerary directly manipulable, then the chat stops being a novelty feature and becomes the app's core creation engine — with retention following the plan, not the conversation.
This meant a deliberate shift in the design language:
| Before | After |
|---|---|
| AI as answer machine | AI as plan generator |
| Text-first responses | Structured, actionable responses |
| Static itinerary documents | Draggable, editable living plans |
| Custom one-off UI | shadcn-mirrored system components |
The Approach: Designing the Conversation-to-Plan Pipeline
Phase 2.0 was structured around the journey a single question travels:
- Ask naturally — a context-aware chat that understands "this evening, nearby"
- Get a structured answer — recommendations with reasoning, not just lists
- Convert in one tap — "Convert this into a single-day itinerary"
- Shape the plan — drag, drop, remove, and add places across days
- Extend it — discovery surfaces and AI suggestions that feed back into the same plan
Key Design Decisions
Context-aware AI responses with visible reasoning. The assistant’s answers are structured as ranked recommendations, each carrying a "Why now?" — a one-line justification tied to the user’s actual situation (evening light, no bookings needed, fewer crowds). Reasoning made visible is what separates a trustworthy travel companion from a search result.
One-tap conversation-to-itinerary conversion. The pivotal interaction of the phase: any structured AI response can be converted into an itinerary through a single action, with a travel-card selection step to anchor it to the right trip. The transcription burden — the reason AI travel advice usually evaporates — was designed out entirely.
Itineraries as manipulable objects. The itinerary screen is organised by day tabs, with each stop as a card carrying its category (Scenic, Food, Religious, Heritage). The interaction model got disproportionate attention: eight drag-and-drop states for reordering stops, dedicated remove interactions, and inline add-place flows. Editing the plan is as fluid as making it.
A discovery layer that feeds the plan. Place details, an Experience Hub, and AI Suggestion cards all terminate in the same verb — Add to Itinerary. Users can also author their own experiences (location, type, day, position, image), making the itinerary the convergence point of AI, discovery, and personal knowledge rather than three parallel silos.
Community content as inspiration input. A reels-style scroll surface lets travellers share moments — a boathouse on Dal Lake, a street café — keeping inspiration inside the app’s loop instead of losing it to social platforms.
A shadcn-mirrored design system as the velocity engine. The file isn’t screens plus a style guide — it’s a full system: tokens, a Radix-extended palette, typography, spacing and radius scales, grids, effect styles, and the complete shadcn component library rebuilt in Figma with blocks and chart patterns. Every screen in Phase 2.0 composes from components engineering already has in code, collapsing the design-to-build gap to near zero.
Iterate where the risk is. The file tells the story honestly: the AI chat surface alone carries dozens of iterations — response structures, side-menu patterns, card layouts — because conversational UI is where AI products live or die. Foundations were systematised once; the novel interaction was explored relentlessly.
Impact
Live on Google Play as Turom: Your Travel Brain; the first two figures below are pulled straight from the listing, the rest are product indicators since launch:
The redesign didn't make the AI smarter — it made its answers usable.
Learnings
- In AI products, the response is raw material. Design the object it becomes, not just the text it arrives as
- Context is the query. "Nearby, this evening, low effort" matters more than the destination name
- Editability creates ownership — a plan users can drag becomes a plan users keep
- Mirroring the design system to code isn't a constraint — it's a release valve. Systematise the known so you can over-iterate on the unknown here