Sample data, working flows
No engineering team or live data. Every flow, from search to payment, runs on sample trips.
Trips that start with something worth doing
Role: Sole UX Researcher, UX/UI DesignerTimeframe: 5 weeks + prototypeStatus: Interactive prototype
I designed a U.S. travel app where every trip starts with something to do. Flights, stays and cars are optional add-ons, and Ody, an AI trip sidekick, knows your plans.
- Problem
- Planning a U.S. trip means juggling a dozen open tabs with no single source to trust.
- Approach
- Designed and tested the core screens in Figma, then rebuilt them as a working prototype and kept revising the design through use.
- Result
- A working prototype you can use on this page: book a Charleston tour, then add only what gets you there.
- 5Traveler interviews
- 3Competitors analyzed
- 5Usability testing participants
- 21Prototype versions
The prototype runs on sample data. Ody's answers, payments and airline accounts are simulated.
Planning a U.S. Trip Meant a Dozen Open Tabs
American Odyssey is a U.S. travel app concept. Travelers bounce between blogs, review sites and map apps that each cover one piece of a trip, so American Odyssey keeps finding, booking and planning a trip in one place.
How might we help travelers plan and explore U.S. destinations with clarity and confidence, all in one place?
The answer started in Figma as curated trip packages, with Ody, an AI travel companion, built in. The working prototype turned it around: you start with something to do and add only what gets you there.
Working Constraints
A crowded category
Tripadvisor, Google Travel and Roadtrippers already cover pieces of the job, so the app had to earn its place.
Five travelers
Five interviews and five testers: enough to point a direction without proving one.
Five weeks, then a rebuild
Five weeks alone from research to hi-fi design. The working prototype came after.
Every Competitor Solved One Piece
How I WorkedI used ChatGPT as a thinking partner for a first competitive framework, patterns across my interview notes, early persona drafts and brand direction. I checked every claim against the apps and my notes, and every decision on this page is mine.
Current Travel-Planning Pain Points
According to McKinsey & Company, domestic travel dominates in the Americas, with domestic trips making up most travel spending and lodging nights expected to reach 19 billion a year by 2030. More trips mean more sifting through crowded platforms and scattered sources.
Research Goals
- How travelers plan U.S. trips and choose where to go
- Where researching and organizing a trip breaks down
- Which discovery features matter when choosing what to do
- What competitors offer and where they fall short
- Whether travelers want one curated app with AI help
Competitive Analysis
I compared Tripadvisor, Google Travel and Roadtrippers on how they support planning and where they fall short.
Each covers a piece, from reviews to road trips, but none carries a whole U.S. trip or personalizes it with AI. That gap became American Odyssey's focus.
Travelers Wanted Fewer, Better Options
Interviewing Users on U.S. Travel Planning
I interviewed five travelers by phone and video about how they choose destinations and build itineraries. Six themes kept coming up:
Travel planning feels scattered
Planning sprawls across tabs and apps until it feels like work.
Personalized recommendations keep things clear
Suggestions have to fit their budget and timeframe. Generic lists don't help them decide.
Trip organization is a major pain point
Even seasoned travelers keep bookings and notes in scattered docs and screenshots.
AI can simplify decision-making
They want quick, personal answers, like what to pack or when to go.
Too many apps ruin the flow
A trip often spans five or more platforms, and details get lost between them.
Trusted curation beats endless options
Endless results and conflicting advice leave them stuck. They want fewer, better options.
Interview Results
U.S. trip planning is fragmented and draining. Travelers want fewer, better options and one place to keep a trip together.
Primary Persona
The most consistent needs came from travelers overwhelmed by scattered information. Harper became the persona every feature answers to.
Determining the User Flow
The information architecture starts broad on Explore and narrows to one activity. Flights, a stay and a car are optional steps before checkout, and Plans, Offers and Ody are each one tap from anywhere. The map shows the flow as it ended up in the final build.
The Brand Color Read as a Warning on Price
Five travelers tested the Figma prototype in person.
What Worked
Ody as a companion
Testers warmed to an AI that plans alongside them.
Flights and lodging together
They liked booking both in one place.
Optional activities
They valued adding activities inside the booking.
What Broke Down
Activity count
They wanted to see how many activities a booking held.
Ody's look
Several found Ody's character design off-putting.
Red prices
Prices in the brand's red read as a warning.
One photo per trip
They wanted to swipe through more photos.
What Changed Because of It
- Red prices: prices are navy now, and red stays with the brand.
- Activity count: the activity you're booking stays pinned to the top of each step.
- More photos: inn pages open on a swipeable gallery.
- Ody's look: the next thing I'd redesign.
From Figma to the Final Build
The first version lived in Figma, and it's the one five travelers tested. Its compass logo joins the A of American and the O of Odyssey, and the compass's deep red set the palette, which proved harder to hold back than it looked.
The Hardest Call: Where Ody Lives
Ody was the core feature, so its placement mattered most. A dedicated tab is easy to find, but help that only lives in its own tab pulls a traveler away from what they're looking at.
Option A
A dedicated assistant tab
Gains: one obvious place to ask.
Costs: asking means leaving the trip you're looking at.
Option B
Prompts on every screen
Gains: help right where the question comes up.
Costs: an assistant everywhere starts competing with the content.
What I chose
Both, connected by context. Ody keeps its own tab, where a traveler picks a trip and Ody already knows its details. An Ask Ody prompt also sits partway down each destination page.
The working prototype kept both: Ody opens on your booked trip, and Ask Ody sits on Explore beside your next activity.
What the Research Turned Into
Because
Trip planning often spans five or more platforms, and details get lost between them.
01
One app for the whole trip
So
Everything from first idea to packing list lives in one app, and a selected trip carries into Ody and Plans.
Because
Interviewees felt paralyzed by endless results and conflicting recommendations.
02
Fewer, better options
So
Explore leads with curated angles in, so a traveler can find something without knowing what to search for.
Because
Even experienced travelers track bookings and notes in scattered documents and screenshots.
03
Organization built in
So
Plans keeps every booking for a trip in one view, next to a checklist for getting ready.
After testing, I kept designing in a working build. Planning trips in it like a traveler showed what the frames couldn't. Each screen below goes from Figma to my first build to the final build, starting with color and then in the order a traveler meets them.
Built with Claude from my Figma frames and a written spec. I made every design call across 21 published versions.
Color
Red stepped back
In Figma, red filled whole screens, and testers read red prices as a warning. My first build moved the interface to navy and kept red for the brand. For the final build I added what happens next, because people open a confirmation to make sure everything is handled.
Figma First build Final build
Next activity
Your next activity, at a glance
Figma opened Explore with a flight check-in card, and my first build replaced it with the whole trip, day by day. That panel pushed everything else below the fold, so the final build shows the next activity and only the next three days, with the rest a tap away in View booking. Travelers see what's coming up right away, and new activities start on the first screen.
Figma First build Final build
Explore
Explore starts with something to do
Figma sold whole trips, and my first build carried those packages over as designed. A trip usually starts with one thing worth doing, so I rebuilt Explore around activities and let flights and stays follow. A $20 tour is an easier first yes than a $299 package.
Figma First build Final build
Activity page
Booking starts on the activity page
In Figma the tour was an extra you added to a package, and my first build kept that with an Add to trip button. When activities became the starting point, I put the date and the Book button on the tour page itself, so the decision happens where the tour won someone over.
Figma First build Final build
Getting there
Getting there became optional
Booking in Figma meant a fixed package, and my first build still required flights before payment. With the activity booked first, the final build made everything that gets you there an add-on you can skip. Locals book a tour in one step, and nobody pays for a flight they don't need.
Figma First build Final build
Flights
Flights compare airlines and count your points
Every flight in Figma and my first build was a United flight, already included in the price. Optional flights had to compete, so the final build compares five airlines and pulls in your linked miles. Price and points in one list spare travelers the app-hopping interviewees complained about.
Figma First build Final build
Rentals
Bikes and shuttles gave way to rental cars
Rentals were an empty "Need one?" box in Figma, and my first build filled it with bikes or a shuttle pass from the package. Bikes don't get far past downtown, and the package was gone, so I switched to cars from nine rental companies for whatever days you need. Airport and downtown pickups fit however someone arrives.
Figma First build Final build
Plans
Plans sorts bookings by type
Plans in Figma put a trip search above the trip card. My first build split out stays and rentals but kept flights and activities inside the trip. Bookings stand on their own now, so each kind gets its own tab, and on the day of a trip the ticket or check-in time someone needs is one tap away.
Figma First build Final build
Offers
Points come from the trip
Figma borrowed from restaurant loyalty apps like Chick-fil-A and Chipotle: points first, then what they buy, with a progress bar on every offer. My first build kept that order and put the balance on a navy pass that counts down to the next reward. In the final build every booking earns points and shows them at checkout, and Offers sits after Plans in the tab bar. Rewards feel earned by the trip, and booking stays the main job.
Figma First build Final build
AI assistant
Ody knows what you booked
Figma gave Ody a trip card above its greeting, and my first build wired that whole Charleston trip into the answers. In the final build Ody centers on the activity you booked, so answers start from your tour's meeting point and your inn. Personal answers without re-explaining the trip are what interviewees asked for.
Figma First build Final build
Live prototype
Try it yourself
Everything above works here. Start with the Activity of the Month on Explore, then add only what you need.
What I Would Measure If It Shipped
The core question: does starting with an activity lead to trips people take?
North star: booked activities that travelers go on, per active traveler each quarter.
Leading indicators:
- Activity page to booking rate
- Share of bookings that add a way to get there
- Time from first search to booking
- Ody conversations that end in a booking or a saved activity
- Return rate for a second trip
What a win looks like: new travelers book a first activity within a visit or two, many add what gets them there, and enough come back for a second trip to show it's more than a novelty.
Reflection
What the work taught me, and what I would do differently with the next one.
The brand's red worked against the product
Red made sense for an American travel brand, but on prices it read as a warning. The fix was to separate brand recognition from interface meaning, so red marks the brand and navy does the work.
Building it turned the product around
Using a working version made the package model feel backward, since most trips start with one thing worth doing. Starting from the activity reshaped Explore, booking and Plans. Next time I'd prototype booking before polishing any screen.
Five testers point a direction
The sessions caught what I missed, like Ody's look and the red prices. Five people can challenge a choice. They can't validate a product.
The next conversation is with engineering
The prototype makes booking and Ody feel instant. The hard parts sit underneath: live inventory, airline accounts, and what Ody does when an answer is wrong. That conversation should start before another visual pass.
The test that matters is whether someone takes the trip.
Thank you for viewing my work.
Shown below are a few of my other projects.
