RotaOverland brings planning, vehicle readiness and on-road decisions into one connected experience for overland travelers.
RotaOverland explores how travelers can keep routes, vehicle preparation, convoy coordination and shared expenses connected throughout an expedition. The design challenge was to preserve context as priorities shift from planning to travel, including the uncertainty of intermittent connectivity.
I defined the journeys, information architecture and interface patterns around the expedition as the central product object, then translated that direction into a navigable prototype, design foundations and landing page. This case explains the trade-offs behind that scope and uses interface studies and simulated interactions to make the proposal tangible; field use and offline reliability remain to be validated.
Read the context and decisions ↓Four views of the product concept, interface studies and design foundations.
Long screens scroll vertically inside the image.
Related trip tasks in one expedition context.
Interface studies for the journey and shared activities.
Reusable visual foundations and interface patterns.
The product story translated into a public-facing page.
An overland trip begins long before the engine starts. Routes, dates, companions, vehicle checks, offline maps and shared expenses are usually spread across different apps, messages and notes.
I shaped the concept around the expedition as a shared context for planning, preparation and travel. My scope covered journeys, information architecture, UX/UI, a navigable prototype, a landing page and reusable design foundations.
The design problem was to preserve trip context as travelers move from preparation to the road. I prioritized clear readiness and connectivity states, while treating offline reliability and field readability as requirements to validate rather than demonstrated capabilities.
How might we help travelers feel prepared, connected and in control throughout an entire expedition?
Two working profiles guided the concept: travelers coordinating their own preparation and organizers coordinating a convoy. They are design hypotheses, to be refined through conversations and task-based testing with overland travelers.
I mapped discovery, planning, preparation, travel and the post-trip record as one lifecycle. Choosing the expedition as the central object keeps related decisions together, at the cost of a broader product scope than a route planner alone.
Turn a desire into a destination.
Route, dates and participants.
Vehicle, checklist and offline.
Navigate, alert and record.
Expedition summary and history.
The concept groups route, convoy, vehicle readiness, checklists and expenses around each expedition. This favors continuity across tasks, but requires a clear distinction between information shared with the convoy and information belonging to the individual traveler.
The prototype prioritizes creating an expedition, preparing it and entering Travel Mode. Occurrence reporting and expenses are contextual actions. The trade-off is less information on the primary screen in exchange for an extra step to inspect detail; this needs task-based validation.
Reusable foundations define status semantics, touch targets, the primary action and online, offline and syncing patterns. These patterns describe intended behavior; field legibility, accessibility and recovery from connectivity loss still require implementation checks and user testing.
The following examples connect the design decisions to their supporting exploration. Original prompts are available on demand.
The flow treated expense splitting as part of the expedition lifecycle, with explicit offline states, synchronization conflicts, proportional rules and a clear human checkpoint before settlement.
Create an extremely detailed step-by-step user flow for the Convoy Expense Splitting feature...
The constraints became layout rules: large touch targets, persistent offline status, shallow hierarchy and niche-specific modules for POIs, mechanical preparation and convoy finances.
Generate structured ASCII/text wireframes for three main screens of an overland app...
AI accelerated flow coverage and early layout exploration. Defining the expedition as the product’s central object — and deciding which information mattered while driving — remained human product judgment.
AI helped explore flows and prototype interfaces. I chose the expedition as the central product object and prioritized offline behavior, field readability and human control over shared expenses.
This reconstructed example contrasts fragmented trip information with the proposed expedition context. It explains the design hypothesis; it is not a measured before-and-after comparison or an original historical screenshot.
Duplicated context · weak offline confidence · no shared expedition status
Use a simulated expense flow to inspect participant selection, splitting rules and queued synchronization feedback. The fragment demonstrates interface states, not a production offline synchronization service.
Choose the participants to calculate each share.
Queued for synchronizationThe expense remains available to the convoy while offline.
Fictional data. The fragment demonstrates offline state, calculation and synchronization feedback from the functional concept.
Once the product narrative was clear, the same principles were translated into a landing page. Instead of presenting a list of features, the page follows the traveler’s story — from planning with confidence to staying connected on the road.
The result is a product concept, navigable prototype and reusable interface foundations. The next validation should ask travelers to create a trip, identify missing preparation, record a shared expense and interpret a connectivity change. Observe completion, errors, help requests and understanding of pending synchronization; no measured usability gains are claimed here.
Trip management established as the product's central experience
Planning, vehicle, convoy and expenses connected in one context
Dedicated Travel Mode designed for speed, focus and offline confidence
Reusable design system and brand foundation ready to evolve
Organizing the concept around a lifecycle clarified where each capability belongs. It also exposed a scope risk: adding convoy, vehicle and financial tasks can make a travel tool harder to learn. The next iteration should validate the core preparation-to-travel transition before expanding secondary features.
