00 · INTRODUCTION
Chat can describe a trip. It cannot hold one.
Triply is an AI travel planner. The hard part was never producing a good suggestion; a language model does that in one turn. The hard part is that it evaporates. This study covers how the conversation produces a durable, editable itinerary object, and the four surfaces around it.
ROLE
Design lead
Five designers: two junior, three associate. I owned the product direction and the itinerary model.
TIMELINE
Three months
From first concept to an interactive prototype and a written model.
SCOPE
137 screens · desktop and mobile
Chat, search across five verticals, itinerary, map, feed, settings.
STATUS
Prototype
Delivered to engineering with the itinerary model written down.
01 · THE CASE IN BRIEF
The whole case, before the details
PROBLEM
An answer is not a plan
A model can name ten places in a paragraph. It cannot say which day they belong to, which are booked, or what happens when the user changes their mind.
KEY DECISION
The itinerary is the product
Chat, search, receipts and manual entry are four inputs to one structured object, not four separate features.
EVIDENCE
Read from the built prototype
137 screens across desktop and mobile. Claims are counted or shown from those screens, and anything specified rather than built is labelled where it appears.
WHAT WAS DELIVERED
A specified prototype
An interactive prototype covering the planning loop end to end, delivered to engineering with the itinerary model written down. Provenance, commitment states and most failure states are specified in the model rather than rendered in the prototype.
137
screens
desktop and mobile
67
mobile screens
the same object at 375
5
search verticals
stay, eat, see, do, fly
4
input routes
saved, AI, receipt, manual
7
item types
one row component
02 · THE PROBLEM
What a paragraph of travel advice leaves undone
THE ANSWER, AS PROSE
WHAT IT LEAVES UNDONE
- 01 Sequence Day 1 lists five places. Their order within the day is the reader’s guess.
- 02 Truth Joe’s Pizza, Becco, the Halal Guys: named, not resolved. Any could be closed.
- 03 Commitment Nothing here is booked, priced or held. It is a reading list.
- 04 Revision Swap one restaurant and the whole paragraph has to be regenerated and reread.
- 05 Memory Close the tab and this is gone. The chat log keeps the words, not the trip.
03 · THE STRUCTURED PROMPT
The question is structured before the answer is
A model can only return a plan if it was asked for one. The dashboard captures the four facts every trip needs, where, when, who and how much, as fields with real pickers, so the first message to the model is already data rather than a sentence to guess at.
- WhereNew York A destination resolved to a place, not a string. The map can plot it before anything is generated.
- WhenApr 6 to Apr 10 A date range or a flexible window. Dates give the plan its days; flexible hands the model a constraint instead of a fact.
- Travellers7 travellers A count that flows into every search: rooms, seats, party size.
- BudgetOn a budget A band that scopes suggestions. On a Budget is a real filter on the results, not a tone for the prose.
04 · THE MODEL
One object, two representations
The conversation and the itinerary are not two features side by side. They are two views of the same structured object: the chat writes to it, the panel renders it, and every other surface in the product reads or edits it.
05 · THE MOVES
Four decisions that made the plan durable
Each move answers one of the five jobs a paragraph leaves undone. Together they turn a suggestion into something the trip can be built from.
MOVE 01
The model returns structure, not prose
The generated answer is parsed into days, items, times and types before it is ever rendered. The paragraph a user reads and the object the product holds are produced together.
MOVE 02
Every item carries its own next action
Site, Book and Details sit on the row itself, which carries its commitment state: not booked, held, booked or cancelled. The plan does not send the user elsewhere to act on it, and it records what was actually committed to. States are specified in section 07; the prototype renders the first.
MOVE 03
Four ways to put something in
Saved, Ask AI, Receipt and manual entry all write to the same day, and each item keeps the route it arrived by. That provenance is what lets the plan distinguish a booked flight from a guessed restaurant. Specified in section 08.
MOVE 04
The map is a second reader of the same plan
Pins are not decoration. They are the itinerary drawn geographically, updating as the plan changes.
06 · THE SHELL
Three panes on desktop, and the map never leaves
Every working desktop screen is the same frame: a navigation rail, a content pane that changes with the task, and a map that stays. The map is not a view the user switches to; it is a permanent second reading of wherever they are.
THE THREE PANES
- 01 Navigation Chat, Search, Calendar, My Map, Saved, World Feed. Persistent on desktop, and it never collapses there.
- 02 Content Whatever the task needs: a conversation, a result list, a settings form. This is the only pane that changes.
- 03 Map Always present on desktop, always plotting what the content pane is about. Collapses only when the content needs the width.
07 · THE ITINERARY
The panel that makes the answer editable
This is where the study earns its title. The generated plan opens as a document with days, times, per item actions, and an edit history, sitting beside the conversation rather than replacing it.
THREE VIEWS OF ONE TRIP · ITINERARY RENDERED · CALENDAR AND BOOKINGS SPECIFIED
WHAT MAKES IT A DOCUMENT AND NOT A MESSAGE
- 01 Days are containers Items belong to a day, not to a sentence. Collapsing a day hides its contents without losing them.
- 02 Items carry a type Activity, flight, café, hotel, restaurant, camp or custom. Type drives the icon, the action and the map pin.
- 03 Every row has an action Site, Book or Details. The next step lives on the item, not in a paragraph telling the user to go and find it.
- 04 Undo and redo An edit history means the plan can be changed without fear, which is what makes editing it worthwhile.
- 05 Three views, one trip Itinerary, Calendar and Bookings render the same object by day, by date and by commitment.
- 06 Add is always present Each day ends with an Add control, so the plan is never finished and never closed.
COMMITMENT STATE PER ITEM · SPECIFICATION
- Not booked A suggestion. No money, no hold, no reference.
- Held A provisional reservation with an expiry. The row shows the time it lapses.
- Booked Confirmed, with a reference and a cancellation deadline on the row.
- Cancelled Kept in place, struck through, so the day still shows what was planned there.
08 · FOUR WAYS IN
A plan is only as good as what you can put in it
People find places in different ways: some in the product, some in an email confirmation, some from a friend. The Add control opens four routes into the same day, so the plan does not force anyone to re-find what they already have.
The Add panel over the itinerary: four tabs across the top, and a type picker beneath. Whichever route is used, the result lands in the day it was opened from.
09 · THE PROFILE THE PLAN READS
What the plan knows before you ask
Travel Preferences is the quiet half of the system. Home airport, seat preference, flight and accommodation preferences shape suggestions and searches. Special assistance, passport and birthday are read only by the booking flow, at the moment a booking needs them. Together they are what the product knows before a traveller asks.
WHERE EACH FACT IS USED
PREFERENCES · READ ONLY WHERE THEY CHANGE THE RESULT
- Home airport Origin prefilled on every flight search Flight searchSuggestions & My Map
- Seat preference Carried into flight results and bookings Flight searchBooking flow
- Flight preferences Cabin and stops applied before results load Flight searchSuggestions & My Map
- Accommodation preferences Stay results ranked by them Stay resultsSuggestions & My Map
IDENTITY · READ AT BOOKING ONLY · NEVER IN THE MODEL CONTEXT
- Special assistance Attached to every booking that needs it Booking flow only
- Passport Read at booking, never asked twice Booking flow only
- Birthday Age brackets for tickets and fares Booking flow only
10 · SEARCH
Five verticals that had to feel like one product
Stays, restaurants, attractions, activities and flights ask for completely different things. A flight needs origin, destination, dates, cabin and trip type; a restaurant needs a cuisine and a neighbourhood. The design problem was letting each be honest about its own shape while keeping one place to save.
11 · THE MAP
A second reading of the same plan
On desktop the map is the one pane that never changes task. Whatever the content pane is doing, the map is plotting it, which means the plan can always be read two ways at once: as a sequence of days, and as a shape on the ground.
My Map inverts the relationship. Here the map is the subject rather than the companion: a shareable record of visited cities that feeds recommendations back into planning.
While planning
Pins are the itinerary. Adding an item drops a pin; reordering a day changes nothing on the map, because geography does not care about sequence.
While searching
Pins are results. The map answers the question a list cannot: is this actually near anything else I am doing.
As a profile
My Map is the trip history made public. Visited cities, a travel style, and a link a friend can open to recommend places back.
12 · SAME OBJECT, 375 WIDE
What survives when the map cannot stay
Sixty seven mobile screens carry the same itinerary object into a frame that cannot hold three panes. The rule that held on desktop, the map never leaves, breaks here. What replaced it says more about the model than the desktop ever did.
13 · FROM PRIVATE TO PUBLIC
A finished trip becomes someone else’s starting point
A plan that survives the conversation can outlive the trip. World Feed turns completed itineraries into browsable objects, which is both the growth mechanic and the answer to the cold start problem every planner has.
World Feed. Each card is a real itinerary: duration, author, city and the themes it covers. Four tabs define relevance four different ways.
14 · STATES AND EDGE CASES
Where a generated plan is most likely to be wrong
A model that writes into a document can write the wrong thing into it. These are the states designed for that, grouped by what has failed.
Nothing usable returned
GENERATION FAILURE
The model answers but the parse yields no days. The prose is kept in the conversation and the panel stays closed rather than opening empty.
A place that does not exist
GENERATION FAILURE
An item cannot be resolved to a real location. The row renders greyed with Not found, keeps its position, and offers Replace rather than vanishing.
Impossible sequence
GENERATION FAILURE
Two items overlap in time or sit four hours apart. The day shows a conflict marker; the plan is never silently reordered.
Receipt not recognised
INPUT FAILURE
The parse fails on an unfamiliar confirmation. The raw text is preserved and the manual form opens prefilled with whatever was read.
A day with nothing in it
EMPTY STATE
Days 2 and 3 exist before they have content. Each shows its date and an Add control, so an unplanned day looks intentional rather than broken.
The model is slow or unavailable
SYSTEM FAILURE
Progress is shown, and search remains available as a fallback route into the same day. The conversation is never lost.
15 · UI FOUNDATION
The system five designers had to share
Three months and five designers working in parallel meant the foundation had to be settled before the surfaces were. Geist for the interface, one accent, one row component, and a type scale measured from the built screens.
16 · WORKING WITH OTHERS
Five designers, three months, one object
Two junior and three associate designers worked in parallel across chat, search, settings and mobile. My job was to keep five people building one product rather than five good screens. Six of us in total, counting me.
MY ROLE
Design lead
Product direction, the itinerary object and its four input routes, the three pane shell, and the final call on anything that touched the shared system.
THE TEAM
Two junior, three associate
Search verticals, account settings, the mobile set and the component library, each owned end to end with the foundation shared between them.
HOW IT HELD
The object was the contract
Any new surface had to state what it wrote to the itinerary or read from it. A screen that could not answer that question was not ready to be designed.
17 · WHAT THIS DEMONSTRATES
What the structure makes possible
Everything below is a property of the designed screens, checkable by reading them.
WHAT THE STRUCTURE MAKES POSSIBLE