Voyage: the full case study

Summary

The problem

An international trip is not one purchase. It is a chain: flights, a hotel, transfers, local transport passes, activities, insurance, currency, documents and visas, then everything that happens during the trip itself. Each link usually lives in a different app or website, and the links depend on each other. A flight delay is not just a flight problem; it can cost a hotel night, a pre-booked tour and a transfer.

Travellers carry that dependency map in their heads. The effort is uneven: planning is slow but calm, while disruption is fast and stressful, and often happens at night, in a foreign airport, on a weak phone connection.

Why existing AI assistants fall short

• Chat without action. Many assistants give good advice and then send the traveller off to book it elsewhere. The thinking is done for them; the work is not.
• Action without limits. Assistants that do book things rarely explain where their authority ends. One unexpected automatic change is enough to make a traveller distrust every later suggestion.
• Personalisation that feels like surveillance. Recommendations improve when the system learns, but learning that the traveller cannot see feels intrusive and is impossible to correct.

So the design question was not “what can the AI do?” but “what should it be allowed to do, when, and how will the traveller know?”

Where Voyage aims to sit

Travel products today cluster at two ends. Booking platforms are excellent at search and transactions and largely leave the traveller alone once they have paid. Human travel agents and premium concierge services handle the whole trip, including disruption, but cost too much for most leisure travellers. Voyage aims at the space between: concierge-level coordination across a whole trip, delivered by AI for routine work and by people for the hard cases, at a price closer to a booking platform. That positioning only works if travellers trust the AI with the routine work, which is why trust, not features, is the centre of this case study.

Role and approach

I worked end to end. I wrote the business requirements document and the scope options, designed the product in Figma, built the prototype with Claude as a coding partner, wired the in-product AI to the Claude API, and defined the rules the in-product AI follows.

Five questions before any AI feature

No AI feature reached a wireframe until I had answered five questions about it:

1. Who benefits? The traveller’s goal, or the product’s engagement numbers?
2. What does a wrong answer cost? The answer sets the feature’s autonomy level.
3. Can the traveller understand it? If I cannot explain the AI’s reasoning in a sentence, the feature is not ready.
4. Can they override it? Every suggestion or action needs a visible way back.
5. How does it fail? I designed the failure state before the success state.

AI in two roles

AI played two different parts in this project, and I kept them separate. As a build tool, Claude helped me write requirements, generate components and draft documentation; I reviewed and overrode it as I would a fast junior colleague. As a product component, Claude powers the concierge inside Voyage; there, its behaviour is constrained by the autonomy model and a strict response format.

Who it is for

The prototype models eight traveller types, because the same trip changes shape depending on who is travelling: solo, family with children, family with older relatives, honeymoon, business, luxury, students and budget-conscious. A honeymoon in Bali and a family trip to Japan need different suggestions, different pacing and different disruption rules.

For design decisions, those eight types collapse into three modes that a single traveller can move between, sometimes within one trip.

The third mode drove the hardest decisions. A product designed only for calm planning breaks exactly when the traveller needs it most.

The autonomy model

Every AI capability in Voyage sits on one of four rungs. The rung is set by the cost of a mistake to the traveller, not by how confident the model is. A confident model can still be wrong, and in travel a wrong action costs money, time and sometimes safety.

Three rules that hold across the ladder

• Moving up a rung needs a reason. A feature starts at “suggest”. It only earns “act, then tell” when a mistake is cheap to reverse and waiting would cost the traveller more.
• Every action is announced. Nothing on the “act” rung happens silently. The traveller sees what changed, why, and what else they could choose.
• Money is never on the “act” rung. The AI never charges a payment method or spends wallet balance without an explicit confirmation, however small the amount.

One trip, every rung

The clearest way to see the model is to follow one trip through it. This is an illustrative scenario that applies the rules end to end: two travellers, seven days in Bali in late December, a $3,000 budget.

Three weeks before: suggest

The couple describe what they want in the conversation. The concierge asks for dates and party size one at a time, then offers a few options for each part of the trip: a quiet inland stay, couple-friendly experiences, a transfer. They choose; each choice appears in the trip summary with the running total against their budget. The AI did most of the research; the couple made every choice.

Ten days before: suggest, then a gate

In the booking flow, Voyage recommends travel insurance because the plan includes a volcano sunrise trek, and says that is why. Pre-trip tasks appear from the itinerary: visa on arrival details, a reminder about local currency, a packing note for the trek. On the review screen they see every item, its cancellation terms and the total, then confirm once.

Day one: inform

On the way to the airport, a gate change and a heavy rain warning for the evening arrive as alerts. Neither needs a decision. The alerts say so in their first line.

Day one, later: act, then tell

The connecting flight is cancelled. A seat on the same airline leaves two hours later the same evening, at no extra cost, and their hotel check-in is unaffected. Voyage moves them, then tells them what changed, why it acted, and shows the other options if they prefer one. They read one line and get on with their evening.

Day five: hand to a person

A volcanic ash advisory threatens flights off the island for the return. The alternatives involve a different day, a new hotel night and a changed onward connection. This is beyond the AI’s limits, so Voyage hands the case to a support agent with the whole trip and the options already attached, and tells the couple a person is on it and when to expect an update.

Across the trip, the AI did a great deal of work. It acted on its own exactly once, in the one situation where acting could not hurt.

Chat and search as equals

The default for a new AI product is to make the chat box the front door. I tested that idea against the three modes and it failed two of them. The explorer benefits from conversation. The decider does not want to describe a flight to a bot when a date picker is faster. The traveller in motion needs one clear button, not an open-ended text field.

Voyage therefore gives conversation and search equal weight from the first screen. The important detail is the hand-off: a traveller who starts in chat and then opens search finds the destination, dates and party size already filled in, and anything they choose in search appears in the conversation’s trip context. Neither mode is a dead end.

The concierge

This is the heart of the prototype. It has three columns: past conversations, saved trips and travellers on the left; the conversation in the middle; and a live trip summary on the right that lists every item added, by category, with the running total.

One question at a time

The concierge never asks for everything at once. It asks the single most useful thing next and offers the right control inline: a calendar for dates, counters for adults, children and infants, chips for hotel facilities. A traveller can answer by tapping rather than typing, and every answer is visible in the thread.

Options, then a choice

For each part of the trip, the concierge shows a small set of option cards, such as flights, hotels, transfers, restaurants, insurance and currency, each with its price and the facts needed to compare. The traveller chooses; the AI adds the choice to the trip summary and moves on. In the demo, a business trip from San Francisco to Dallas for a family of four comes together this way, from flights to dinner reservations, before a single “book entire trip” action at the end.

Asking before reusing

When the AI can save the traveller effort with data it already holds, it asks first. It offers to auto-fill passenger details from passports saved on a previous trip, and to apply hotel loyalty points, and only does so after a yes.

Trade-off: the AI could build the whole trip from one message. Asking step by step is slower, but every item in the summary is one the traveller has seen and chosen.

Discovery

For the explorer, discovery turns a vague wish into a shortlist. Destinations can be filtered by budget, trip length and experience type, such as adventure, luxury or wellness, and browsed by region. Each destination shows an AI match score for this traveller.

A match score is easy to make impressive and hard to make honest. Each card places the score next to the concrete facts a traveller can check for themselves: budget from, typical duration, best months to go and style tags such as wellness or family friendly. Results can be sorted by match, budget or rating, so the AI ranking is one view rather than the only one. The next step is to show the two or three Travel DNA signals behind each score, so a 96% reads as a reason, not an oracle.

Booking and money

Booking is one guided flow across seven steps, so the traveller books a trip rather than seven separate products. A trip summary stays on screen throughout, showing progress, each category and the running total. The AI recommends at each step, with its reason in plain view, but never advances the flow on its own.

1. FlightsSearch, compare, select
2. HotelsAvailability and ratings
3. CurrencyExchange for the destination
4. InsurancePlans with a recommendation
5. Local transportTransfers, passes, rentals
6. ActivitiesTours and experiences
7. Pre-trip tasksDocuments, health, packing, then one confirmation

Recommendations with reasons and terms

On the flights step, the AI marks one option as recommended and says why in an “AI tip”: non-stop, the best balance of price, comfort and schedule for a family. Every option shows its cancellation terms on the card, such as free cancellation until a date or non-refundable, so the traveller weighs flexibility at the moment of choice, not after paying. Nothing is charged until the traveller confirms the whole trip.

Insurance and pre-trip tasks

These two steps are where AI adds quiet value. Insurance recommendations are based on the trip’s actual contents, such as adventure activities or travellers over a certain age, and say so. Pre-trip tasks are generated from the itinerary and destination: documents, visas, vaccinations, travel passes. Both stay on the “suggest” rung; neither buys anything for the traveller.

Disruption handling

This is where the autonomy model matters most. Once a trip starts, Voyage monitors flight status, price changes, weather along the route, travel advisories and natural hazards. Most of these simply inform. Flight disruptions are different, because the right response is often a booking change, and the best alternatives disappear within minutes.

Why semi-automatic

Fully manual handling wastes the minutes that matter. Fully automatic handling risks fixing the flight while breaking the trip: arriving a day late to a non-refundable hotel, or missing a connection the AI did not consider. Semi-automatic handling acts only when acting cannot hurt.

What the prototype shows

The Real-Time Assistant puts this into practice for a Japan trip. A three-hour flight delay is flagged “action needed” rather than handled silently. An earthquake alert explains what happened and what it means for the traveller, then states in advance what the AI will do: send a safety status to emergency contacts. Three clear actions follow: I’m safe, contact hotel, emergency help. A panel lists everything Voyage is monitoring, such as flight status, weather, advisories, prices, hotel availability and visa updates, so the traveller knows the scope of its attention.

Designing the alert

Every disruption alert answers four questions in the same order: what happened, what Voyage did about it, what it means for the rest of the trip, and what the traveller can do now. The order matters. Under stress, people read the first line and act. That line must tell them whether they need to do anything at all.

Safety is never behind the AI

Emergency contacts, local emergency numbers, the embassy and the hotel are reachable in one tap from the trip screen, alongside an SOS action. None of it requires opening a chat. In an emergency, a conversational interface is a barrier, not a help.

Personalisation the traveller controls

Voyage learns from past trips and from what travellers tell it. The design decision was how visible that learning should be.

Silent learning makes recommendations better and the product creepier. So the Travel DNA profile shows what the AI has learned, labelled with its source, “learned from 12 trips”: preferred season, average trip length, preferred regions, booking lead time, typical budget and travel companions. Next to it are two controls, recalibrate and clear learning data. Stated preferences sit separately: travel styles and amenities the traveller selects, with a line stating exactly how the AI will use them, such as filtering out stays that do not match. In privacy settings, AI learning can be switched off, and sharing data with partners is off by default.

Profiles that change the rules

Family profiles and accessibility needs are not just preferences; they change behaviour. A booking that includes a child or a traveller with mobility needs moves disruption handling up to “hand to a person”, because an automatic rebooking that ignores those needs is exactly the kind of mistake the ladder exists to prevent.

Trust patterns

Across the product, the same six patterns repeat. Together they are the practical form of the autonomy model, and they are reusable in any AI product that acts for its users.

Failure states

For each AI feature I designed the failure first. When the concierge cannot find a good option, it says so and suggests what to relax, rather than offering a poor match. When data is missing, such as no live status for a flight, the alert says the information is unavailable rather than implying all is well. When the AI is unsure about an inferred preference, it asks rather than assumes.

How the concierge talks

In a conversational product, the words are the interface. I wrote conversation rules for the concierge the same way I would write interaction rules for a component, and they are part of its system instructions.

• State assumptions out loud. If a traveller says “December”, the concierge says which dates it is assuming and invites a correction, rather than silently choosing.
• One question at a time. When information is missing, it asks for the single most useful thing next, such as dates before budget, instead of a form disguised as a paragraph.
• Never invent availability. Prices and availability come only from the inventory service. The model can describe and compare, but it cannot make up a flight or a room rate.
• Say what it cannot do. If a request is outside what Voyage can book, it says so plainly and suggests the nearest thing it can help with.
• Match the moment. Planning conversations can be warm and exploratory. Disruption messages are short, factual and lead with whether the traveller needs to act.

From the prototype

Each turn asks for one thing, offers the fastest way to answer it, and asks permission before reusing personal data.

During and after the trip

Trip dashboard

Once booked, each trip gets a card with its status, upcoming, planning or completed, and a dashboard that shows cost by category, a day-by-day itinerary and quick actions to rebook, share, download or contact support. Loyalty points from airlines and hotels are aggregated in one view with their redemption value, because travellers rarely know what their points are worth.

Memories

After the trip, Voyage offers a photo gallery with AI-sorted albums, such as best moments, food and scenery, a location-tagged journal with optional mood tags, and AI-written trip stories that can be shared with companions. These sit firmly on the “suggest” rung. The AI drafts albums and stories; the traveller chooses what to keep, and nothing is shared without them choosing to share it. Memories are private by default, because photos and journals are the most personal data in the product.

Trade-off: private-by-default sharing reduces the viral reach that a travel product might want. I treated that as the cost of being trusted with people’s photos.

Design standards

Voyage uses a token-based design system defined in Figma and carried into code through Tailwind, so the concierge and the rest of the product share one visual language. Beyond the usual standards, I set three that are specific to travel.

• Design for the worst moment. Disruption and emergency screens are designed for one-handed use on a phone, in poor light, under stress: large targets, short sentences, the decision first and the detail second.
• Plain language over travel jargon. Fare classes, layover rules and insurance terms are explained in the traveller’s words at the point of decision, not in a glossary.
• Accessibility needs travel with the trip. Needs stated in a profile are carried into suggestions, booking choices and disruption rules, so the traveller does not have to repeat them at every step.

On phones, the concierge keeps the conversation first and moves the trip summary behind a single tap, so the thread and its inline controls get the full screen.

How it is built

The prototype is a React frontend with a Node and Express API, Postgres for trips, itineraries and bookings, and the Claude API for the concierge. The frontend deploys on Vercel and the API on Railway. Travel inventory is mock data for now; the architecture keeps a service layer per supplier so real flight, hotel and activity APIs can replace the mocks one at a time.

A response format that enforces the design

The most important engineering decision was a design decision. The concierge does not return free text. It returns a structured response with three parts: the conversational reply, a list of suggestions, and any preference updates. Each suggestion must include a reason. Because the format is enforced in code, the trust patterns cannot quietly erode as prompts change.

{
  "response": "Natural language reply",
  "suggestions": [{
    "type": "activity | hotel | flight | transport | visa | forex | ...",
    "title": "...", "price": 25, "rating": 4.8,
    "details": { "duration": "2 hours" },
    "reasonForSuggestion": "Why this fits the traveller"
  }],
  "personaUpdates": { "interests": ["temples"] }
}

Suggestions without a reason are rejected before they reach the interface. Preference updates are never applied directly; they are shown to the traveller to confirm.

Guardrails outside the model

Three checks run on the server, not in the prompt. Any price or availability in a reply must match the inventory service, or the suggestion is dropped. Any action above the “suggest” rung is checked against the disruption rules for that booking, including the travellers’ profiles, before it runs. And any step that would move money is blocked unless it comes from the traveller’s explicit confirmation on the review screen. Putting these rules in code means a cleverly worded request cannot talk the model past them.

Working with AI on code

I used Claude to generate the concierge interface and the API skeleton from my designs and the response contract. As with any generated code, I reviewed each piece, cut what did not match the design, and kept the rules about autonomy in my own hands: they live in the response contract and in server-side checks, not in a prompt the model could talk itself around.

Scope and strategy

The designs cover eight services. That breadth is the product’s differentiator and its biggest risk, so I wrote the requirements with three delivery paths and their trade-offs rather than a single plan.

For the prototype I designed the full-service experience, because the autonomy model only proves itself when the AI is coordinating across services, for example when a flight change affects a hotel. For a real launch, my recommendation would be to build in stages, starting with the services where disruption handling matters most.

Business model hypothesis

The requirements assume a commission on bookings across services plus a premium subscription for features such as proactive monitoring and priority human support. This is a hypothesis, not a validated model, and testing willingness to pay for monitoring is on the list below.

Where I overrode the AI

I built Voyage with AI tools, and they consistently pushed towards more automation and less explanation. These are the moments I said no.

Gaps and test plan

Voyage is a concept prototype. I would rather be precise about what that means than let the polish suggest more than it is.

What I would test first

1. The “act, then tell” rung. Show travellers realistic disruption alerts at each rung and measure whether they understand what happened and whether they trust the automatic rebooking. This is the riskiest assumption in the product.
2. Visible personalisation. Compare silent learning with the Travel DNA prompts. Does seeing what the AI learned increase trust, or does it feel like nagging?
3. Placing suggestions. Does adding items one by one feel like control or like busywork? If it is busywork, a “add all to plan, then edit” option may be the better balance.
4. Willingness to pay for monitoring. The premium tier depends on travellers valuing proactive disruption handling before they have needed it.