The Explorite prototype on a phone at a cafe table overlooking FlorenceBrowsing Florence, no account
Explorite 03 / 03

Giving a travel group one place to turn competing preferences into a decision.

A travel-discovery concept evolved from research into a live prototype with bookings, reviews, and crew voting.

My contribution

I recorded research sessions, synthesized findings, and designed flows and prototypes. I later directed AI agents through the live build.

Research

The problem

On a two-day trip, a review count and a listicle don’t tell you if an activity is worth half a day. I recorded interviews to understand how travelers actually decide.

I mapped the responses into an affinity chart, drew two personas grounded in what people said, and built a six-screen prototype. The prototype made those flows concrete. It was not an external usability test.

First persona built from interview responsesSecond persona from interviews
PersonasTwo personas built from what travelers said, not what I assumed.
Insight

What the research found

The journey map showed that checking everyone’s availability was the actual hard moment. That changed what I built next.

The trip owner now proposes two to four times. Friends open a share link and vote In, Maybe, or Out without an account. The crew coordination gap the interviews exposed became the core product design.

  1. 01ProposeOwner offers 2 to 4 times
  2. 02ShareFriends open a plan link
  3. 03VoteIn, Maybe, or Out without signup
  4. 04CompareOwner reviews availability
Prototype

Live prototype, August 2026

I directed an AI-directed build on Supabase with a warm-paper interface and a seeded experience catalog. The prototype includes email login, a booking flow with confirmation codes, crew voting using share tokens, messaging to hosts, and a gallery of experiences.

Crew coordination without signup

Share tokens let friends vote In, Maybe, or Out. Invalid tokens return no data. The trip owner sees votes in real time.

Trust through booking status

Reviews can be posted by anyone but only show verified when the writer has a confirmed booking.

Host messaging

Guests message hosts directly. The system supports live delivery and contextual responses.

Data isolation

The app shares infrastructure with this portfolio but uses namespaced tables and row-level security to keep data separate.

The core design choice was putting crew coordination first. That interface is the differentiator, not the activity catalog.

Three Explorite screens on phones: the city index, an experience page, and the byline sign-up
ScreensPicks read like a numbered index, each page says who tried it before it shows a price, and a byline is only needed to book, save, or rally a crew.
Next

Shipped state

The live prototype has seeded experiences. The build includes functional reservation and share-link voting flows, not evidence of customer adoption. No external usability validation has been done yet.

Next, I would test coordination with real travel groups before expanding the catalog. The question is whether proposing a few times and removing signup actually helps people agree.

Research grounding

Interviews and affinity maps from research phase. Live build is August 2026. Personas and coordination flow are grounded in what travelers said.