Designing a collaborative trip planning system
Turning an AI itinerary builder into a collaborative experience to make it easier for multiple travelers to plan the same trip together.
- Role
- Sole Product Designer, Strategist
- Timeline
- 4 weeks (May–June 2026)
- Team
- 2 founders
- Client
- Triwize Journeys
- Platform
- Responsive web app
- Status
- In development
My Role
As the sole designer for this project, I worked closely with Triwize’s two co-founders over four weeks to define and design the Collaboration journey from the ground up. It was the first of three Phase 2 initiatives I led over three months, and the first project I took on after joining as a contractor. My work included defining the scope, design research, competitive analysis, user archetypes, feature definition and PRDs, user journeys, flows, information architecture and mid-fi prototypes covering the main user flows and key edge cases. The designs are currently in development.
Context
From planning a trip alone to planning it together
Triwize’s Smart Planning Platform (SPP) is an AI-powered travel planning app that helps users discover, plan and book their trips all in one place. For Phase 2, the product was expanding beyond individual trip planning to support collaborative trip planning, allowing multiple travelers to plan the same trip together.
Right now, in Triwize’s Smart Planning Platform (SPP), travelers can:
The Opportunity
Planning a trip together with friends can be messy
Most people don’t travel alone. Friends decide where to go together. Someone finds a hotel, another person researches restaurants and eventually someone has to pull everything together into an actual plan. Users jump from social media to flight booking platforms to messaging apps and more to plan a trip with friends.
Triwize saw an opportunity to combine these fragmented parts of travel planning into one seamless experience.
Goals
Business goals
Grow the user base by bringing new users in to collaborate on trips and increase group bookings. Increase engagement by keeping people on Triwize for all their planning needs.
Product & user goals
Make collaborating on a trip simpler and more seamless and help groups accomplish their entire trip plan on one platform. Jumping between apps is what turns planning into something chaotic and unorganized.
The Problem
Group planning isn’t equal participation
This was one of the most important findings from the available research.
- One person usually takes the lead. They may be the person who creates the trip, coordinates everyone or ultimately brings all the decisions together.
- At the same time, the other people in the group don’t necessarily want the same level of control. Some might want to actively plan the itinerary. Others don’t want to be involved in planning at all.
So What?
How can we make a group trip feel like a shared workspace where everyone can contribute in their own way?
To design that, I noted down all the questions I needed to answer for the different scenarios in collaborative trip planning.
- How does a user invite collaborators?
- How much access does a collaborator have?
- Who manages that access, how do they manage it, and how much authority do they have?
- In what ways do co-travelers collaborate with each other?
Understanding Users
Three ways people show up in a group trip
I identified three user archetypes that had distinct behaviors and needs. Each user group’s behavior defined the level of control they had in trip planning.
Defining the collaboration model
I translated each user group’s behaviors into three participation levels.
- Admin
- The person who owns and coordinates the trip.
- Editor
- A co-traveler who actively participates in planning.
- Viewer
- Someone who doesn’t actively contribute to trip planning but needs to be kept in the loop.
Core features and flows
Inviting people in
The first major interaction was getting someone into the trip. There are several ways to invite others: the first friend can be invited from the trip dashboard or from inside the trip itself. The person who starts the trip and invites the others naturally takes the role of Admin.
The Admin can invite people through a shareable link or by email, and choose whether each person joins as an Editor or a Viewer. For Editors, authentication matters, since editing requires an account. For Viewers, we kept the experience lighter: they only needed access to the trip details, so requiring authentication didn’t seem necessary.
When friends open an invite link, they can see which trip they’re joining and what each role can do. I wrote separate CTA copy to make the difference clear: Editors can “Join the trip” and contribute to planning, while Viewers can “See the trip” without actively participating.
Once invited, friends can access every space in the trip
Friends invited as Editors can edit the itinerary, make bookings, and use the AI itinerary builder, much like an individual traveler. Friends invited as Viewers can access every space in the trip, but can’t make changes. I adapted the AI chat for group use, so everyone invited could ask for ideas and plan together. Avatars showed who was part of the trip, and an Updates section kept everyone informed about co-traveler activity.
I brought discussions and decisions into the trip instead of sending people to another messaging app. The in-chat AI bot helps with ideas, mentions make it easy to bring friends into the conversation, and polls and reactions help the group make decisions. Image and file uploads make it easier to share inspiration.
The Admin controls the access, everyone with access controls the trip
Everyone invited can view the trip, but only the Admin can manage access and permissions. Since the product hadn’t launched, we didn’t yet know how people would use collaboration or have the data to justify a more complex system. For V1, we kept control simple: the Admin can invite or remove co-travelers, change their roles, transfer the Admin role, or delete the trip.
When needed, the Admin can remove Editors’ ability to make changes in critical areas like the itinerary and bookings. This helps prevent major changes to the trip plan or unintended purchases, while invited collaborators retain view access to the trip.
Intentional updates and alerts
I introduced an Updates feed that creates a lightweight history of important collaborative actions. When designing this, I wanted to be intentional about what actually deserves a user’s attention. For example: Since Triwize is a trip planning product, not a chat or communication app, I didn’t want every interaction between friends to generate a notification.
I identified three types of updates that were important enough to bring users back into the trip, as shown in the image below.
What stayed out of Phase 2
I had other ideas for the collaboration experience, including features for during and after the trip. Expense management and a memories feature for sharing photos and reflecting on the trip were pushed to Phase 3. Since the product was pre-launch, we wanted to first see how people used collaboration in their trip planning. I focused Phase 2 on establishing the core collaboration model before expanding the scope.
My process and deliverables
I relied heavily on existing user data and research, competitive analysis, and stakeholder discussions to shape the project. My handoff included:
- Research
- Research synthesis, competitive analysis, and user archetypes.
- Product definition
- Feature scope, collaboration model, and permissions.
- Experience architecture
- User journeys, flows, and information architecture.
- Design
- Mid-fi prototypes covering the core flows and edge cases.
The work was handed off to the UI design and engineering teams. The backend and design system are now in development, with the collaboration model and mid-fi designs as the foundation for the next stage.
What I’d validate next
- Do people understand the roles?
- Can travelers easily predict what they can and can’t do?
- Does the notification hierarchy work?
- Do updates surface the information people care about?
- Does the current permission model work smoothly?
- Do Editors want more authority? What are the most and least preferred ways to invite friends? Will people keep using existing social apps to communicate instead of moving trip conversations into a travel planning app? Is there a real need for separate Viewer and Editor roles?
Reflections
One of the most important parts of my role was helping the teams avoid making the experience more complex than it needed to be. In discussions with the founders, I kept making the case for simplicity at this stage of the product.
With a pre-launch product and limited usage data, we needed to establish the core collaboration model first and learn how people used it before adding more.