PRODUCT DESIGN CASE STUDY
Rebuilding Australia's most used camping and caravanning app. It was an offline first site database. It is now a place to discover, plan and book.
Hemant Kumar · Lead Product Designer Native mobile · iOS and Android 2023 → 2026
daily booking value
new sites in 3 weeks
on the offline build
faster to a result
Click to zoom
introduction
A trusted directory that stopped at the moment of decision
WikiCamps Australia is a community built database of campsites, caravan parks, cabins and dump points. Most of its use happens where there is no phone signal. It was very good at helping people find a site. It did nothing to help them secure one.
The product. An offline capable site database. Listings, photos, ratings, reviews and fees all come from users.
The audience. Caravanners, campers, grey nomads and road trippers travelling regional and remote Australia.
The position. WikiCamps was known for having more sites than anyone else. CampsAustraliaWide, CamperMate and Hipcamp were closing that lead quickly.
The brief. Modernise the app, restart site growth and build a revenue stream. All without losing what long time users rely on.
6
experiences redesigned
3+
years of shipped iteration
5
shipped changes covered here
4
measured outcomes
Click to zoom
Research
Site growth had stalled, discovery frustrated people, and nothing made money
Three problems were compounding. Fewer new sites were going into the database. New users were bouncing off the first screen they saw. And the only revenue was app downloads.
Click to zoom
SUPPLY
Site growth had flatlined
WikiCamps was known for having the most sites. That count had stopped growing. CampsAustraliaWide, CamperMate and Hipcamp were catching up fast.
Click to zoom
FILTERS
Three state toggles nobody understood
There was plenty of data showing filters confused people. The three state toggle was the worst of it. No solution had been found.
Click to zoom
DISCOVERY
Map first, with the list hidden
Everyone landed on the map. Users who found that overwhelming did have a list view. It was not easy enough to find, so many left the app instead.
Click to zoom
RELIABILITY
Offline broke at the boundary
Most use happens outside coverage. Moving in and out of network interrupted the experience constantly. Offline data only helped users who had thought to download it.
Click to zoom
REVENUE
One button, in the wrong place
Revenue came from app downloads and one Book button on site details. It was short of target, and the button sat where users had the least intent.
Click to zoom
CONSISTENCY
An ageing UI with no shared system
Years of changes had left inconsistent patterns across screens. There was no shared component language to build on.
Solution: One
Fix the funnel at both ends
More sites going in. More bookings coming out. And a discovery experience in between that people could actually operate. The offline core stayed protected throughout.
01
Make contributing quick
Add a site sits on the highest traffic screen. The flow asks for the minimum up front, and the rest once the site exists.
02
Let people choose the view
A labelled map and list switcher, with the list sheet open by default. The first screen fits the user rather than the other way round.
03
Offline for everyone
A baseline set of offline data ships to every user. Anyone who wants more can download high resolution map and data.
04
Put Book where the intent is
A fixed booking bar across every site details screen and the trip page. That is where the funnel showed people deciding.
Click to zoom
Solution: Two
Lead product designer, end to end
I was the sole design owner. Research, information architecture, interaction, visual design, the design system and handoff. I worked directly with product, business and mobile engineering.
DISCOVER
Research & synthesis
Analytics funnels, heatmaps, app reviews, support tickets and social channels. I used AI to help cluster and summarise.
DEFINE
IA & flows
Restructured navigation into Home, Explore, Book, Plan and Menu. Mapped every state, including refused location.
DESIGN
UI & design system
A component library on Material 3, built with Figma Tokens and used across all six experiences.
NEGOTIATE
Requirements & trade-offs
Worked with developers and business to agree which fields were genuinely mandatory for Add a site. Also to land the booking compromise.
VALIDATE
Prototyping & testing
Figma Make prototypes went into usability testing. Releases were measured in Amplitude, then iterated.
ADVOCATE
Pushing the platform
I challenged the technology position on offline. We shipped a baseline dataset to every user, not only those who downloaded one.
The stack
Figma
Figma Tokens
Figma Make
Claude Design
AI heatmap plugins
Amplitude
Google Analytics
Gemini
ChatGPT
Claude
THE PROCESS
Design thinking, with AI inside each stage
The stages did not change. What changed is how quickly each one closes. AI took on the slow, mechanical parts of synthesis, concept generation and prototype building. That left more of the week for judgement.
01
Empathise
Analytics funnels in Amplitude and Google Analytics. Heatmaps on live screens. App store reviews, support tickets and social channels.
AI · Gemini · ChatGPT · Claude
Clustering and summarising reviews, tickets and notes. Themes worth reading surfaced in hours rather than weeks.
02
Define
Rebuilt the IA around decision order. Agreed the mandatory field set with engineering and business. Mapped every state.
NO AI HERE
Deliberately human. Deciding what to ask for, and what to leave out, was the judgement everything else depended on.
03
Ideate
Concept directions and layout explorations for the site page, browse rails, add a site flow and booking entry points.
AI · Claude Design
Generated concepts and visual directions in minutes. Options could be judged as artefacts rather than argued as descriptions.
04
Prototype
Interaction spec and component behaviour defined in Figma against the component library.
AI · Figma Make
Turned specs into working prototypes with real scroll and real states, rather than clickable mockups.
05
Test
Usability sessions on the prototypes and on shipped builds. Findings logged and prioritised.
AI · AI heatmap plugins
Attention overlays on live screens confirmed or killed a finding quickly. They also pointed at where to look next.
06
Deliver
Spec, tokens and states documented for engineering. Design QA against every build.
AI · Figma Tokens
Kept type, colour and spacing decisions machine readable. Less was lost on the way into the codebase.
The stack
Figma
Figma Tokens
Figma Make
Claude Design
AI heatmap plugins
Amplitude
Google Analytics
Gemini
ChatGPT
Claude
THE CONSTRAINTS
What the design had to survive
Most of the interesting decisions in this project came from working inside hard limits rather than around them.
ENVIRONMENT
No signal, no data
The app is used in the places phones do not work. Users cross the coverage boundary constantly rather than sitting outside it.
AUDIENCE
A large, habituated user base
Long time users had years of muscle memory. Change went out in staged releases rather than one jump.
DESIGN
UI & design system
Listings, photos, fees and reviews come from users and are uneven. The UI had to hold up for sites with very little data.
BUDGET & TECH
No native booking flow
A native checkout was ruled out on budget, time and platform grounds. That forced a compromise rather than the ideal solution.
PERMISSIONS
Location often refused
"Distance from you" underpins the experience, and many users decline location. Every key screen was designed twice.
TRUST
Monetisation without erosion
Booking and deals had to earn their space. A community built utility should not start to feel like a marketplace.
Click to zoom
Click to zoom
THE RESEARCH
Four lenses on the same behaviour
Rather than one large study, the work ran continuous, low cost evidence gathering across a live product, then triangulated. When revenue became the question, the same four lenses were pointed at the booking funnel.
BEHAVIOURAL
Funnel & event analytics
Amplitude and Google Analytics. Which screens carried traffic, and where in the funnel booking intent actually appeared.
ATTENTIONAL
Heatmaps on live screens
AI heatmap plugins showed real attention distribution. That was the basis for reordering the site page and moving the primary action.
ATTITUDINAL
UI & design system
Travellers running real tasks. Find a site, judge it, add one, book it. On prototypes and on shipped builds.
UNSOLICITED
Reviews, tickets & social
App store reviews, support tickets and social channels. Clustered with AI, then read by hand.
6
evidence sources, run continuously
1
funnel, mapped end to end
3 yrs
of releases measured live
Click to zoom
Click to zoom
THE INSIGHTS
What the evidence actually said
Intent was not where the button was. Book lived on site details. The funnel showed people deciding after reviews, fees and trips. None of those pages had a booking entry point.
The handoff broke at the moment of payment. Tapping Book opened an external browser. The jump was jarring, and it came exactly when confidence mattered most.
The list view existed but could not be found. Everyone landed on the map. Users who disliked it had a list view they never discovered. They left the app rather than switch.
Three states were two too many. The filter toggle carried three states. Users could not predict what any of them did. They either got the wrong results or stopped filtering.
Offline failed at the boundary, not in the dead zone. The pain was crossing in and out of coverage. Offline data only protected the users who had downloaded it in advance.
Contribution had become too expensive. Adding a site asked for everything up front. Site growth stalled while competitors grew, and the "most sites" position started to slip.
THE SOLUTION 1
Five changes, five measured outcomes
Each one answers an insight from the previous slide. The next five slides take them one at a time.
THE SOLUTION 2
Add a site: ask for less, get more
The database was the moat. Rebuilding contribution was the fastest way to defend it.
THE PROBLEM
Contribution cost more than it was worth
WikiCamps was known for having more sites than anyone else, and the business wanted to keep that position. The count had stopped growing. CampsAustraliaWide, CamperMate and Hipcamp were catching up fast.
The entry point was buried. The flow asked for everything a listing would ever need before it would accept anything at all. People started and gave up.
WHAT I DID
A visible entry point and a two stage flow
I moved Add a site onto the first landing screen, where the traffic already was, and gave it real prominence.
Then I split the flow. Capture only what is needed to create a site. Collect the mandatory detail after it exists. Agreeing that split meant working through the requirements with developers and business to settle which fields were genuinely mandatory.
The result was one simplified flow that cut the time it takes to add a site.
Click to zoom
Click to zoom
5,000+
THE RESULT
new sites were added within three weeks of launch. It was the largest increase in sites the platform had seen.
THE SOLUTION 3
List view: stop making the map compulsory
The first screen after login suited one kind of user and quietly lost the other.
THE PROBLEM
A list that existed but could not be found
Every user landed on the map. For people who found a map overwhelming, or who simply preferred a list, that was the wrong first impression.
A list view did exist. It was not intuitive enough to discover. The users who needed it most never found it, and left the app rather than switch.
The first screen was making a choice on their behalf, and getting it wrong for a large group of them.
WHAT I DID
A standard switcher, and the list already open
I brought the list view forward and used the switcher pattern most apps already use, so it would be recognised rather than learned. It carries a clear label rather than an icon alone.
Then I removed the need to discover it at all. The list is exposed by default as a half card over the map. Users can swipe it up or down to suit how they want to browse.
The first screen now adapts to the user.
Fewer exits
THE RESULT
first time user drop off fell significantly once people had an entry point that matched their preference.
Click to zoom
THE SOLUTION 4
Filters: three states down to two
A long-standing problem with plenty of evidence and no accepted solution.
THE PROBLEM
Nobody could predict what a toggle would do
There was no shortage of data showing filters confused people. It had been visible for a long time without a fix.
The three state toggle was the core of it. With three states and no clear model of what each one meant, users could not predict the result of their own action. They either got results they did not expect, or stopped filtering and scrolled.
Filters are meant to narrow a search. These were adding work to it.
WHAT I DID
One rule, carried by the default
I restructured the filters and cut the toggle from three states to two. The default carries the meaning. Everything is selected, because by default you are looking for all of it.
Deselecting a checkbox then means one thing only. Exclude this. One rule, learnable in a single interaction, and reversible.
Alongside the state change I simplified the grouping and labelling, so the panel can be read in a scan.
2× faster
THE RESULT
users reached the result they wanted twice as fast, without getting confused by the filters or stuck on them.
Click to zoom
THE SOLUTION 5
Before after
A long-standing problem with plenty of evidence and no accepted solution.
THE PROBLEM
Nobody could predict what a toggle would do
There was no shortage of data showing filters confused people. It had been visible for a long time without a fix.
The three state toggle was the core of it. With three states and no clear model of what each one meant, users could not predict the result of their own action. They either got results they did not expect, or stopped filtering and scrolled.
Filters are meant to narrow a search. These were adding work to it.
WHAT I DID
One rule, carried by the default
I restructured the filters and cut the toggle from three states to two. The default carries the meaning. Everything is selected, because by default you are looking for all of it.
Deselecting a checkbox then means one thing only. Exclude this. One rule, learnable in a single interaction, and reversible.
Alongside the state change I simplified the grouping and labelling, so the panel can be read in a scan.
2× faster
THE RESULT
users reached the result they wanted twice as fast, without getting confused by the filters or stuck on them.
THE SOLUTION 6
Offline: make the safety net the default
The feature existed. It only protected the users who had thought about it in advance.
THE PROBLEM
The interruption was at the boundary
The majority of WikiCamps use happens in areas with no network. Offline is not a nice to have. It is the product working at all.
The real pain was not the dead zone. It was crossing in and out of coverage, which interrupted the experience constantly. Offline data also only helped users who had chosen to download it, and for various reasons many never did.
WHAT I DID
A baseline for everyone, opt in for more
I challenged the technology position and advocated for a baseline set of offline data for all users. Whether or not someone ever downloads anything, the app keeps working without interruption.
We introduced the feature during onboarding so people knew it was there. We also gave users the option to download high resolution map and data if they want it, without interrupting the onboarding journey.
96%
THE RESULT
of users were on the new offline ready build within three weeks. They are covered whether or not they download anything.
Click to zoom
THE SOLUTION 7
Book now: put the action where the intent is
With the app redesigned and the early criticism answered, the question turned to revenue.
THE PROBLEM
One button, on the screen with the least intent
Revenue came from app downloads and one prominent Book button on site details. It was not meeting the business target.
I looked at Google Analytics, the social channels, support tickets and app reviews. The funnel was clear. Users did not have booking intent on site details. They booked after visiting reviews, fees and trips, and none of those had an entry point for booking.
The Book button also opened an external browser. That experience was jarring on its own.
WHAT I DID
A fixed booking bar, and a compromise on checkout
I introduced a fixed, prominent bottom bar carrying Book across every site details screen, and onto the trip page. Whenever someone wants to book, the option is there.
We wanted a native booking flow. Budget, time and technology constraints did not allow it. Rather than ship nothing, I found a middle ground and suggested bringing the booking flow into an in app browser with some style changes.
$5k → $30k
THE RESULT
daily order value, up from five thousand. A six fold increase off the back of these changes.
Click to zoom
Click to zoom
