You shouldn’t need to know where you’re going before a travel product becomes useful
I joined Intripid as the founding product designer and defined destination discovery, trip planning, AI-assisted planning, collaboration, brand identity and the system connecting them — from zero through multiple rounds of testing and iteration.
- Company
- Intripid
- Role
- Founding Product Designer
- Stage
- 0→1
- Scope
- Product strategy · UX/UI · Brand · Design systems · AI-assisted planning
- Team
- Sole designer · 2 founders · engineering (2 leads + 2–3 interns) · CX
- Validation
- Multiple rounds of user testing and iteration
Four decisions that shaped the product
- Discovery~15 questions→six primary signals
- RecommendationBroad possibility space→3 reasoned choices
- PlanningFragmented planning→One trip state
- AI assistanceBlank prompt→Contextual, reviewable proposals
Destination should be an output,
not an input
Most trip-planning experiences become useful once the traveller already knows where they want to go.
Intripid started earlier.
What if you know when you can travel, what kind of trip you want, how far you are willing to go, and what you can spend — but not the destination?
I reviewed 
TripAdvisor, 
TripIt, 
Wanderlog, 
Tripoto and 
Wonderplan. The recurring assumption: the destination is already known. After that, planning, booking and collaboration usually split across tools; recommendations are generic or missing; and days are hard to rearrange on a calendar.
Category default
Destination → Plan
Intripid
Dates + constraints + preferences → Destination → Plan
- AHow much context is enough to recommend confidently without interrogating the traveller?
- BHow do we narrow possibilities enough to help someone decide instead of creating another catalogue?
- COnce a destination is chosen, how do time and geography become one planning model?
- DHow can AI help without hiding decisions or taking control away from the traveller?
01 / Discovery
Earning a recommendation
The first challenge wasn’t planning the trip.
It was earning the right to recommend one.
A form would have been the default
15 → 6
Early versions of Destination Discovery asked roughly fifteen questions and contained long experience and activity lists.
- EarlyProduct and the founders initially leaned toward richer preference collection. More context should, in theory, produce a better recommendation.
- TestingTesting exposed the other cost. Every additional answer asked the traveller to do more work before Intripid had returned anything useful.
- DecisionI proposed one rule for the critical path: a question stays only if it can materially change the recommendation.
- ResultWe aligned on six primary signals. Everything else could move later, when it became relevant.
Kept as primary signals
- 01Dates
- 02How far
- 03Origin
- 04Budget
- 05Must-haves
- 06Activities
Dropped after testing
- Who’s joining?
- Cuisine preferences
- Dietary restrictions
- Preferred transportation
- Travel pace
Every extra answer could theoretically improve the recommendation. It also spent attention before the traveller had a place.
The problem wasn’t form length. It was asking for work before returning value.
Six signals, one geographic space
Each remaining question has to change the recommendation. Origin and budget carry follow-up states because they are easy to get wrong.
When is this trip actually possible?
When is this trip actually possible?
Show the filter, don’t hide the wait
Recommendation logic should not feel opaque. The traveller should be able to see what the system is checking as it narrows the set.
Constraints
- Dates
- Reach
- Budget
- Must-haves
- Activities
While matching
During processing the product narrates reachable ports rather than spinning.
- Foundx possible destination ports
- Searchingfor cities near the reachable ports
- Analyzingwhich ports are reachable
- Eliminatingunreachable ports
- Okaylet’s see where you can get to…
Recommendation means choosing
Showing more destinations felt safer — it reduced the chance that we would hide a good option. I pushed in the opposite direction. If Intripid returned another long list, we would recreate the search problem we were trying to solve. We treated recommendation as a commitment: return three destinations, and make each one argue for why it belongs.
Small output
Three deliberately bounded recommendations.
Distinct reasons
Each option should make a different case.
Inspectable fit
Each recommendation explains why it fits.
That changed the recommendation screen from a ranked list into a decision surface.
Recommendation creates a new question
Why should I trust this one?
A recommendation needed more than a score. The brief translates the recommendation back into evidence the traveller can evaluate: why it fits, which selected preferences it satisfies, whether the timing is feasible, approximate cost context where relevant, and why it is meaningfully different from the other recommendations.
Identity
Keep both attachments, make them one character
The identity was not a blank page. The founders were attached to two things: the hummingbird and the existing palette. Replacing either would have solved my design problem while ignoring something they already valued. I treated both as constraints.
Instead of replacing the hummingbird, I changed its role. A sharp mark could identify the brand; a character could carry mood through the product — curious during discovery, focused while planning, calm when the traveller needed reassurance. The palette changed in the same way: from something decorative into semantic colour roles across the experience.
The result kept what the founders recognised while giving the product a communication system it could actually use.
Inherited
Sharp hummingbird mark
existing palette
- Purpleanchor
- Orangewarmth and action
- Tealfreshness and movement
- Pinksoftness
CuriousFor discovery, recommendations, and “where should I go?” moments.
FocusedFor itinerary building, planning, and AI-assisted organization.
ExcitedFor completed plans, trip inspiration, and moments of progress.
PeacefulFor reassurance, calm planning, and stress-free travel messaging.
CaringFor support, tips, and moments where the brand needs empathy.
OverwhelmedFor empty states, errors, or moments that acknowledge planning stress.
02 / Planning
Making the trip actually work
Choosing the destination only changes the problem.
Once the place was decided, uncertainty stopped being geographic. It became time.
The category scattered the trip
In the products I reviewed, planning, booking and collaboration usually lived in different tools. Recommendations were generic or missing. Activities were hard to rearrange on a calendar. Seeing stays, activities, timings and movement together was the exception.
Split across tools
- Planning
- Booking
- Collaboration
- Recommendations
One trip state
- AnchorCalendar as the place the trip is made
- BlocksStays, activities and movement as timed pieces
- EditChange the plan without leaving the plan
As the planner grew, the same activity needed to exist across the calendar, map, itinerary, collaboration surfaces and eventually the advisor. With engineering, we had to decide whether those views should own separate state or read from the same trip. Separate state would make each surface easier to treat independently, but synchronisation would become the product problem. I pushed for one Trip state. The calendar became the planning anchor; map and itinerary became different ways of reading the same object.
A trip is not a list
A list can tell you what you want to do. It struggles to tell you whether Tuesday actually works.
Reducing possibility
One tripThree readings
Intent → Recommendation → Trip
Represented as
- Calendar
- Map
- Itinerary
Calendar, map and itinerary are readings of that trip — not separate products.
- Assisted by
- AdvisorThe advisor proposes against it.
- Shared with
- TravellersTravellers share it.
- Alongside
- HomeHome is the signed-in place for profile and trips.
A selected place has to keep time in view
A stay occupies nights on the calendar and a location on the map at the same time.
The same trip needed more than one way to read it
The calendar is for constructing the trip; itinerary is for reading it in sequence.
Designing the conflict model
Real itineraries overlap, bookings lock, and travel takes time. Conflicts became first-class itinerary states rather than temporary warnings.
- OverlapTwo things occupy the same time for the same traveller.
- Tight turnaroundLess travel time than the route needs.
- Impossible commuteThe places cannot be reached in the time between them.
The mobile planner wasn’t a smaller desktop planner
Parity was the obvious goal. A week-wide calendar, persistent map and side panels already worked together on desktop, so carrying the same model to mobile initially seemed like the safest path.
But compressing the desktop planner preserved the interface and lost the decision. On a phone, the more useful question was: what context does the traveller need right now?
The representation changes. The underlying plan does not.
Desktop
Parallel context
Calendar, geography and controls can sit together.
Change the activity without leaving the week Time, place, who is going, booking, and whether the stop is fixed or flexible stay next to the day they belong to.
Phone
Sequential context, not a separate planning model
Bring forward only what the current decision needs.
A full-page change, not a scaled week grid Time, place, who is going, booking, and fixed or flexible.
03 / Assistance
AI should move the decision forward — not make it disappear
Why not just add a chatbot?
A general assistant was the obvious starting point: open a conversation and ask the traveller what they need. I pushed against that model because Intripid already knew the trip. Asking someone to explain Tuesday, the free gap, the conflict and the places they had saved would make conversation reconstruct state the product already had. We changed the model from prompt-first to state-first.
Blank assistant
Reconstruct it in conversation
- Identify the problem
- Explain the schedule
- Explain constraints
- Ask for a solution
- Interpret the answer
- Update the plan
Contextual advisor
Begin from the state already created
Trip state
- Stops · locations · gaps
- Travel time · conflicts
- Saved ideas
The advisor reads the trip
The advisor opens on Tuesday. Six stops. Nothing is breaking. About four hours are still unscheduled. Instead of asking the traveller to explain the day, the advisor can immediately offer three useful directions: fill the gap, give the day air or ask for something specific.
Interaction contract
The assistant proposesThe traveller decides
Reading the trip solved context, but it introduced a second question: how much authority should the assistant have? I did not want a useful suggestion to silently rewrite someone’s itinerary. We carried that principle into a reviewable proposal model: the system could identify and explain a move, but the traveller kept the final decision.
Systemproposes
Observe
The advisor opens on the day as it actually is: stops, a conflict, free time, and ideas that would fit.
Identify
An overlap, a gap, a day that needs air.
Propose
A concrete move — shift dinner, fill the gap, give the day space — sits next to the activity it would affect.
Explain
The reason is narrated against this itinerary, not as a generic travel tip.
Humandecides
Preview
The traveller can see what would move, and what the resulting day would look like, before the calendar changes.
Apply
Apply it, reject it, ignore it, or edit by hand. The decision stays visible.
04 / Together
One trip, different participation
A shared itinerary does not mean every traveller is doing the same thing. The trip remains one shared object while participation, visibility and conversation can differ.
The trip wasn’t the whole product
Planning lived inside a broader traveller experience. The signed-in home brought profile, existing trips and starting a new trip into one place.
05 / Design engineering
I wanted the interaction to be judged, not just the screens
For this portfolio, I rebuilt the core Intripid flows in working frontend code so the interaction model can be explored directly rather than inferred from static mockups.
- destination discovery
- recommendation logic
- Mapbox behaviour
- calendar planning
- itinerary view
- drag/drop
- conflicts
- advisor states
- collaboration surfaces
- responsive behaviour
Move through discovery, choose a destination, and plan the trip yourself.
Open Intripid ↗From “I have five days”
to “this is the trip.”
The product begins before you know where you are going, and ends when the plan is concrete enough to live.