RoamMate
Designing a Zero-to-One Travel App Around One Persona, Not a Destination List
ZERO-TO-ONE PRODUCT DESIGN MOBILE APP
RoamMate is a travel-planning app built around a bet: travelers don't struggle to find destinations, they struggle to know whether a destination actually fits who they are.
DURATION | PLATFORM | MY ROLE |
8 Weeks | iOS Mobile App | Product Design, end to end |
Role note: I owned design end to end: IA, wireframes, visual direction, UI, and developer handoff.
Product and business strategy, revenue model, local sourcing, monetization phasing, was owned by the product lead on the project. This case study covers design decisions only.
Snapshot
8 | 2 | 1 of 3 |
quiz questions, each tagged to what it powers | wireframe rounds before any visual design | mood-board directions chosen |
Status: Final UI and developer handoff assets are complete. Nothing is built or tested yet, so this case study covers design decisions, not results.
PHASE 1 OF 5
The Opportunity
Travel apps show you places. None of them show you whether a place fits who you are.
The pattern informal conversations kept surfacing the same gap: generic destination lists ignore travel personality ·
The reframe build a persona-matching engine that happens to recommend destinations, not a destination browser with a quiz bolted on
This came from a handful of conversations, not structured research.
PHASE 2 OF 5
Structure
Decide what the first version is, and how it hangs together.
The IA

Three zones: onboarding, core app, profile and settings. Drawn from the V1 wireframes, when booking still sat behind the core loop.
Scoping decisions
Quiz 8 questions, each tagged to what it powers, none there to feel thorough
Talk to a Local async Q&A only in phase 1, paid calls and community notes deferred
Itinerary three curated trip loops instead of a blank planner
Question | Feeds persona | Feeds recommendations |
Spontaneity under time pressure | Yes | Yes |
How you recharge after solo sightseeing | Yes | Yes |
Experience type (multi-select) | No | Yes |
Comfort zone openness | Yes | Yes |
Travel companions | No | Yes |
Budget range | No | Yes |
Dates & duration | No | Yes |
Preferred regions | No | Yes |
Paid calls and community notes weren't cut for being weak ideas. They sit behind a riskier question: will a first-time user trust an async answer from a stranger at all.
Sign up after the quiz, before the reveal. Users finish the quiz, see a blurred preview of their persona, and create an account to unlock it. The account is asked for once there's something to unlock.
PHASE 3 OF 5
Wireframes
Two rounds: prove the loop, then add depth.
V1: the core loop
Quiz, persona, destination discovery and details, Talk to a Local, profile and settings. Booking was a faded placeholder.
V2: the parts V1 only implied
Travel DNA persona and destination cards share one screen after signup
Destination details rebuilt on the full card structure, from why it fits you to a trusted local note, ending in one CTA: Build My Trip
Build Trip booking grew from a placeholder into a full flow: trip details, curated options, trip summary, payment
PHASE 4 OF 5
PHASE 5 OF 5
Handoff and What's Next
Hand developers a kit, not a file drop.
Foundation 430 × 932 base frame, type scale, color tokens from neutrals to success and warning states
Components primary, secondary and FAB buttons, each with default, hover and disabled states, plus navbar and icons
Assets one export pack per flow, at 1x, vector or bitmap depending on the asset
What ships first:
Quiz, persona, destination cards, and async only Talk to a Local, the smallest loop that tests whether persona matching changes how someone plans a trip
Build Trip is fully designed but sequenced last on purpose, no point polishing checkout before anyone has validated the front half of the funnel
What this will need to prove once it's live:
Whether an 8 question quiz feels fast or like a wall, completion rate is the first real signal
Whether a destination card drives action, opening a trip loop or asking a local, not just scrolling past
Whether async trust is enough before any paid layer gets built
What this taught me:
Sequencing, what gets tested before what gets built, is design work in its own right
A quiz question earns its place by feeding something downstream, not by seeming thorough, that test applies to any onboarding flow
Removing a decision from the user, three curated options instead of a blank canvas, is a real design deliverable, it doesn't need a shipped product to prove its value







