RV trip planner and GPS

01 (About)

Industry

Travel

Year

2024-2025

Team

1 Designer (Me)

2 Stakeholders

1 Project manager

1 Business analyst

2 Developers

1 QA Engineer

Links

App Store

Google Play

Role

Sole Product Designer

Deliverables

Mobile app

Web app

Admin panel

Design system

Links

App Store

Google Play

Project highlights

40%

Less time to create a trip in a repeat usability test with 8 travelers

3

Connected surfaces: mobile app, web app, and admin panel

6 of 8

6 of 8 travelers called offline access essential

02 (The challenge)

The challenge

RV travelers combine routes, campgrounds, POIs, exact addresses, changing stops, and trip details—often with unstable connection on the road.

The challenge was to make this complexity manageable across mobile and web, supported by internal admin tools.

My responsibility

As the sole Product Designer, I owned the product structure, core flows, UX/UI, design system, documentation, and handoff across all three surfaces.

I worked with the stakeholders, PM, BA, developers, and QA to clarify requirements, cover edge cases, and support implementation.

From insight to decision

Budget planning came too early

Insight

After the soft launch, user feedback showed that most travelers found the budget step premature: at trip creation they didn't yet know enough to estimate costs. Our initial hypothesis, that budget belongs in the creation flow, didn't hold. To see where exactly it broke, our team (PM, stakeholder and me) ran a moderated session with 8 RV travelers. Each created a trip from start to finish while we recorded the run. Most stalled at the budget step.

Decision

After discussing the results with the team, I moved budget planning out of trip creation and into stop details and the trip overview, where travelers have the information to plan costs. The same 8 travelers then repeated the flow, and it took 40% less time. Since both runs used the same participants, some of the gain may come from familiarity with the flow.

Budget planning came too early

Insight

Decision

Before

After

Offline access became a core requirement

Insight

In the same session, 6 of the 8 travelers told us offline access was essential when planning and traveling on the road. Competitor research added a second signal: not all competing products offered an offline mode.

Decision

I turned this into a core product requirement and designed offline access to trip overviews, maps, trip details, and individual stop details. It was released across the product.

Offline access became a core requirement

Insight

Decision

I turned this into a core product requirement and designed offline access to trip overviews, maps, trip details, and individual stop details. It was released across the product.

Map exploration needed a more scalable model

Insight

As stays, POIs, parks, and other locations grew, overlapping pins made exploration harder. Loading every location by default also created unnecessary paid Google API requests.

Decision

I identified the issue, worked with developers to understand the API and cost constraints, and proposed clustering. We grouped locations at wider zoom levels and progressively loaded details as users zoomed in.

Map exploration needed a more scalable model

Insight

As stays, POIs, parks, and other locations grew, overlapping pins made exploration harder. Loading every location by default also created unnecessary paid Google API requests.

Decision