The AI assistant that reframed how KAYAK thinks about search

At a glance

**One entry point.** A single natural-language prompt with prior plans kept alongside it, in place of a forest of search forms.

**What sits in the middle.** A prompt is parsed into KAYAK's structured filters, then returned as live, bookable results. That bridge is the product.

**Three jobs, one workspace.** Where to travel, when to travel, and what to book, without the traveler moving between tools to do them.

The brief

Turning natural language into travel actions

KAYAK runs on structured queries. A traveler types a sentence. Something had to convert one into the other, and none of it existed.

The project started in June 2024 with a four-person team exploring how a freeform query could become a search KAYAK could actually run. I defined the information architecture and the interaction model: how a GPT-generated response and KAYAK’s structured data combine into one results layout that adapts to whatever the prompt turned out to mean.

The scope was the full arc a traveler moves through, from a vague sense of where to go, to when it is cheapest, to which flight to book.

The results page

Designing for reuse before visual detail

The thing that differentiates KAYAK.ai from a chatbot is live inventory. The results page had to make that obvious.

The question was how to present KAYAK’s live travel data so the difference between this and a general-purpose LLM is legible on sight. Polishing any one screen came later. First I worked out how GPT-generated text and KAYAK’s structured returns could occupy one adaptable layout.

**Anatomy of a response.** An LLM-generated title and summary, a live data widget straight from KAYAK, and follow-up questions generated from what the search actually returned.

Every part of that response has a different source and a different reason to exist. Separating them at the structure level is what let the layout absorb prompts nobody had anticipated.

What shipped first

Phase 1

The first launch covered the whole scenario end to end, from a sense check on destinations to a booked flight.

The full arc, in one workspace. Getting a sense of where to go, finding the best time to travel, comparing flights on a timeline, and booking.

Key screens from the Explore to Flights flow

**When the destination is vague.** A prompt with no fixed place surfaces the Explore widget; a prompt with no fixed dates surfaces Best Time to Travel. The system answers the question actually being asked.

**When the traveler knows what they want.** Specific dates return live KAYAK flight data, with saving and sharing so a trip can be planned with other people. Booking completed on KAYAK for v1.

Scaling it

Phase 2: expanding the AI components

After launch we needed new features fast, on an early-stage product where most of the variables were still moving.

**Atoms to organism.** A compact AI design set built on top of KAYAK's existing design system, so new surfaces assemble from pieces instead of being redrawn.

The answer was not to design faster. It was to make the pieces small enough and regular enough that a new feature is an assembly job. I built a compact AI design set on top of KAYAK’s existing design system, structured atomically so it could be expanded without renegotiating the whole layout each time.

The rebrand landed as configuration

Because the components were already built to adapt, a change of visual direction did not become a rebuild. When the branding team introduced a new strategy, applying a full light theme was a settings change.

**One system, two themes.** The dark-to-light switch went through the component set rather than the screens, so nothing had to be redrawn.

Ten widgets from one structure

The clearest place the system-first approach paid off was the widgets that display KAYAK’s live data.

**Header and body, doing different jobs.** The header carries what was searched and how to refine it; the body carries the inventory. Splitting them is what lets a new vertical reuse both.

Each widget has a clear header and body, and the two areas scale independently. The header holds the query and its controls; the body holds whatever the vertical returns. That separation is why the set expanded to ten variations in a short window without any of them being a special case.

**The set, after expansion.** Flights, stays, cars, packages, explore, flight tracker and best-time-to-fly, all assembled from the same two-part structure.

Comparing without leaving

Phase 2 also closed the loop, so a traveler could finish a comparison inside KAYAK.ai rather than being handed off to another page to do it.

**The detail view, reused.** The right-hand panel is KAYAK's existing product page, so the transition is seamless and the whole comparison stays inside the AI workflow.

Where it went

Bringing AI into KAYAK.com

A year after launch, the patterns proven here became the starting point for AI on KAYAK's core product.

A new team formed to bring AI capabilities into KAYAK.com itself. Alongside leading design for KAYAK.ai, I was asked to help move these experiences across, which meant refining early patterns into components that hold on any KAYAK surface.

**The same input component, twice.** What started as KAYAK.ai's prompt field became the AI mode entry point on KAYAK.com, on desktop and mobile.

On mobile. The same interaction model at phone width, where the results widget carries more of the work.

That handoff is its own case study. It was possible because the pieces being moved were components with defined edges, rather than layouts that only made sense on the page they were drawn for.

What it added up to

Reflections

No experiment numbers on a zero-to-one product. What it can show is what the system absorbed after launch.

What the structure returned

10 Widget variations from one header-and-body structure
1 theme A full rebrand applied as configuration

What I'd carry into the next one

01 Structure before surface On a product where the requirements move weekly, the reusable piece is worth more than the polished screen. The polish can come second; the structure cannot.
02 Split a component by who owns each part The widget header is the query and the body is the inventory. They have different owners and different reasons to change, and separating them is what made ten variations cheap.
03 Design the seam, not the screens The product is the layer between a sentence and a structured search. Everything visible is downstream of getting that conversion right.
04 Build for the handoff you can't see yet Nobody planned for these patterns to move into KAYAK.com a year later. They could because they were components rather than layouts.

The most valuable decision on this project was made before any of it looked like anything, and it was to build a system. Everything that came cheaply afterwards came cheaply because of that.