Case study 03 · Native mobile · Personal project · In progress
Roamly: the trip assistant you actually check
Once a trip is booked, everything about it scatters: the itinerary in one app, the flight in email, the packing list in Notes, the dinner debate in a group chat. Roamly makes the trip itself the unit, so the itinerary, documents, packing and an assistant that can actually help all live in one place that knows which trip, which day and who's coming.
- 14 screensMid-fidelity, from onboarding to the active-trip home, itinerary, assistant, checklist, budget and profile.
- 1 active tripEvery tab is scoped to the trip you're on, so the app always has the context.
- Tables, not flightsThe assistant can book a table or an activity in the moment. Flights and hotels stay out.
01 Context
None of the apps holding your trip know a trip is happening.
Once a trip is actually booked, the useful information about it scatters right away. The itinerary lives in one app, the flight confirmation in email, the packing list in Notes, and the group chat arguing about dinner somewhere else entirely. Each app holds a piece of the trip. None of them knows the trip exists.
This is a personal project: no client, no PRD and no design system to inherit. I wanted this app to exist for years, so I defined the positioning, the IA and a token system from scratch.
02 Problem
Travel apps are good at booking, then they disappear.
The moment of booking is well served. The two weeks of prep and the trip itself, when you actually need help, are not. That's when people are checking passport dates, coordinating a group, and standing on a street wondering where to eat.
Most travel apps are built for the moment of booking. Roamly is built for everything after it.
03 Discovery
Three working personas, built to be tested.
These come from my own trips and assumptions about the people I travel with, not formal research yet. I wrote them down early so they could shape the IA and then be proven wrong in feedback interviews.
- The Over-PreparerHas a spreadsheet. The anxiety isn't picking a destination, it's missing something practical before leaving: a passport date, a document, an item to pack.
- The Group CoordinatorDoes most of the logistics for a partner, family or friends. Needs the itinerary, packing list and open questions somewhere shared, not in their head or a group chat no one reads back.
- The In-the-Moment AskerAlready on the trip and needs a real answer fast: where to eat tonight, whether to tip here. Doesn't want to leave the app and compare five review sites.
What I'll test first: whether pre-trip logistics really cause more anxiety than choosing where to go, whether groups would actually use a shared checklist, and whether people trust an in-trip assistant to act for them, not just recommend.
04 Insights
They're the same traveller at different moments.
These aren't three customers. It's one person: anxious about prep two weeks out, coordinating the group the week before, then asking a question on a street in Positano. What "helpful" means changes at each moment, and designing for that shift is the real IA challenge.
05 Opportunity
Make the trip the unit, not the booking or the task.
How might we give a traveller one place that knows the trip, the day and who's coming, so the right help shows up at the right moment, from prep to the trip itself?
06 Solution
One active trip, with every tab scoped to it.
Instead of a feature list, the navigation is built around whichever trip is open. Home, Itinerary, Assistant, Budget and Profile all know the day, the destination and the context behind whatever's being asked.
| Surface | What it does | When it matters |
|---|---|---|
| Explore | Destination guides, neighbourhood picks and curated ideas, organised by travel style tags | Before there's a trip to attach an idea to |
| Itinerary | Day-by-day schedule, route and timed stops; the default view once a trip exists | Glanced at quickly, not read start to finish |
| Assistant | AI scoped to the active trip; recommends and, where it makes sense, acts (book a table, surface a route) | Questions that come up while planning or while there |
- Decision
- Ask who you're travelling with in onboarding (Solo, Couple, Family, Friends, Business), not as a late search filter.
- Why
- A solo trip surfaces differently than a family one, so recommendations are shaped from the first session instead of starting from zero.
- Trade-off
- One more onboarding step. Filters still exist inside search.
- Decision
- Put the assistant inside the trip, not in a separate chatbot.
- Why
- Ask "recommend a sunset dinner spot" and it answers with a specific place for this trip, not a list of links.
- Trade-off
- An assistant that can act touches the transaction, which I originally wanted to avoid entirely.
- Decision
- Make packing and prep a shared surface, not a private list.
- Why
- Checklists are shared with whoever's coming, with live presence ("Sarah is editing") and tips pulled from the day's weather. Same collaborative surface as the itinerary.
- Trade-off
- Presence and shared editing add complexity a solo list doesn't need.
- Decision
- Surface documents and logistics on the home screen, not in a folder.
- Why
- Passport expiry, flight terminal and destination weather show up for the active trip, so "did I check that?" stops being a recurring worry.
- Trade-off
- The home screen has to earn every slot; logistics compete with discovery content.
Going in, I wanted to avoid booking entirely and stay a pure discovery layer. The assistant made that line hard to hold: the most useful answer to "where should I eat tonight?" is often one tap from booking it. So the direction leans in, but stays narrow. Roamly books a table or an activity in the moment, never flights or hotels.
07 System
Calm and legible under pressure.
Navy is the primary, with a warm cream and gold secondary and a deep brown tertiary, each with a full tint-to-shade ramp rather than a single hex. Travel planning means scanning under time pressure (gate numbers, document deadlines, weather), so the interface stays quiet by default and saves saturated colour, like the orange action buttons, for the one thing that needs attention.
Discovery screens are photography-forward: full-bleed images, generous crops, cards with room to breathe. Planning and logistics screens (itinerary, checklist, documents) put structure first, because those are the screens people use quickly and repeatedly, not the ones they linger on.
08 Build
Designed within iOS and Android conventions.
I worked with native navigation patterns, gesture handling and component vocabulary on both platforms while building a distinct product identity. I used AI-assisted workflows to speed up research synthesis and interface exploration.
Add one example where a platform convention changed a design decision.
09 Results
Where the project is now.
14 screens at mid-fidelity, covering onboarding, the active-trip home screen, itinerary, AI assistant, checklist, budget and profile. The information architecture is settled, component patterns are consistent across screens, and the content voice is defined.
Next: high-fidelity polish, an interactive prototype of the Explore-to-Itinerary flow and the assistant, and feedback interviews with people who match the Over-Preparer, Group Coordinator and In-the-Moment Asker profiles, to test the assumptions behind them. After that, I'll decide between a lightweight prototype build and keeping it as a Figma piece.
10 Reflection
Scope discipline is a design skill, including knowing when to move the line.
- 01
A scope line is a hypothesis.
"No booking" made the early product clear. The assistant showed where it was wrong, so I narrowed it to tables and activities instead of dropping it.
- 02
Design for moments, and label your assumptions.
The same traveller needs different help two weeks out and on the day. The personas behind that idea are my assumptions, written down so the next round of interviews can check them.
- 03
No brief is still a brief.
Without a client or PRD, I had to define the positioning myself before any screen made sense.