SyncTrip

Group travel initially looked like a flight-search problem, but research showed the larger challenge was coordinating different budgets, schedules, and preferences. I helped reframe the product around private constraint collection, group compatibility, and voting so groups could move from individual preferences to a shared decision without forcing sensitive financial conversations.

Planning a group trip often begins with an activity everyone already understands: searching for flights. At first, that made flight search seem like the natural product opportunity. The deeper we looked at the planning process, however, the less the search interface appeared to be the real source of friction.

A group might contain four people with four different schedules, budgets, airport preferences, and levels of flexibility. Each person can find a flight. The difficult part is finding one the group can actually agree on. That became the foundation of SyncTrip.

We surveyed 16 people about group travel behavior and looked beyond the mechanics of booking. Two findings changed our framing. Seventy-five percent of respondents had declined a group trip because of cost, while 50% had said they were “busy” when price was actually the reason they did not want to participate.

Budget was therefore not only a financial constraint. It was also socially sensitive information. That meant a seemingly straightforward solution, such as asking everyone to publicly post their maximum budget, could recreate the discomfort already present in the planning process. The product needed enough information to identify viable options without forcing someone to publicly justify what they could afford.

Our original mental model resembled traditional flight search: destination, dates, filters, results. Research suggested a different system built around individual constraints, shared understanding, viable options, and consensus. That changed our main product question from, “How might we help groups find flights?” to, “How might we help a group turn private individual constraints into a decision everyone can participate in?”

Once we reframed the problem, several product decisions became clearer.

Instead of beginning with a shared spreadsheet or group discussion, SyncTrip begins by inviting each traveler to submit their own constraints, including schedule availability, budget range, and preferences. This gives the system the information it needs without requiring every traveler to negotiate publicly from the beginning.

Users are not hiding information from the group. The product is changing how that information is represented so the group can make progress without unnecessarily exposing a sensitive constraint.

Travel preferences are often flexible. Someone who says they have a $400 budget may actually be willing to pay slightly more for a significantly better itinerary, while someone who prefers an 8 a.m. departure may simply mean they do not want to travel late at night.

We therefore avoided treating every preference as a hard binary filter. Budget ranges and availability windows better represented the way people actually reason about travel and created room for the product to surface meaningful tradeoffs instead of automatically eliminating options.

Traditional flight tools optimize for an individual searcher. SyncTrip needed to communicate how an option worked for the entire group. Instead of asking users to mentally compare everyone's constraints, the product could make compatibility visible.

A flight could indicate that it fits four out of four travelers, for example. That reduces the coordination burden from repeatedly asking, “Does this work for you?” to understanding whether an option already fits the group's submitted constraints.

Identifying valid options still does not create consensus. Groups often become stuck after several acceptable choices have been found. Someone sends a link, another person reacts, a third person does not respond, and hours later nobody knows whether a decision was actually made.

Voting became the bridge between recommendation and commitment. The final SyncTrip flow became Create Trip → Individual Inputs → Group Overview → Flight Options → Voting → Confirmation. Each step exists because of a specific coordination problem, not because it is standard in a travel interface.

We also evaluated the experience around existing flight-search tools, including Google Flights. These products were strong at helping an individual compare flights but largely stopped once the unit of decision became a group. Users were still responsible for invitation management, schedule reconciliation, budget conversations, link sharing, and consensus outside of the product.

That gap suggested that SyncTrip did not need to outperform established tools at basic flight search. Its differentiation could come from the coordination layer surrounding the search.

I worked across the survey, research synthesis, competitive analysis, low-fidelity concepts, high-fidelity prototypes, and final presentation. Our iterations focused on making the relationship between an individual's input and the group's decision understandable.

We repeatedly asked whether users understood what information was private, whether they could see when the group was ready to move forward, whether tradeoffs were communicated clearly, and whether someone could participate without becoming the default trip planner. Those questions mattered more than visual polish.

If SyncTrip moved into production, I would avoid using bookings alone as the primary success metric because a group could use the product successfully and still decide not to travel. The product's job is to improve the decision process.

I would measure invitation-to-constraint submission rate, percentage of groups where every traveler submits constraints, time to first viable group option, voting participation, time from trip creation to consensus, budget-input abandonment, and percentage of groups reaching a confirmed decision. One metric I would pay particular attention to is the time between identifying a viable option and reaching consensus because that is where much of the coordination friction appears to live.

SyncTrip changed how I think about requirements. A requirement like “collect everyone's budget” sounds functional and straightforward until you understand the social context around that information. The research showed that a technically correct product could still create emotional friction.

The better solution was not simply collecting more information. It was understanding which information needed to remain individual, which needed to become shared, and how the product could translate between the two. The project reinforced one of my favorite product principles: do not optimize the most visible step before understanding the entire job. Flight search was visible. Coordination was the real problem.