Campground fully booked? Not for long – turning BC Parks cancellations into a one-click cart hold
Project Overview
Summer campsites in BC's provincial parks are some of the most competitive bookings in the province. Reservations open about three months ahead, popular campgrounds sell out within minutes, and the only way in after that is a cancellation. Those cancellations do happen, but they show up at random times and are usually gone within seconds.
In practice, getting a site meant refreshing the BC Parks reservation website over and over, across several parks and date combinations, and hoping to be looking at the right moment. CampingScout does the watching instead: you describe the trip you want, and it tells you the instant a matching site opens up.
My main goals were...
Let anyone set up an alert in under a minute, with no account, password or app install in the way
Only alert when a site is genuinely bookable for the whole trip, so every notification is worth acting on
Shrink the time between "a spot opened" and "it's in my cart" to as close to zero as possible
Strategic Value
The real competition isn't another app, it's speed. Whoever reaches the reservation page first gets the site. That reframed the whole product: CampingScout isn't a search tool, it's a relay race, and every screen either hands off quickly or slows the user down.
I designed the experience around that handoff: ask for as little as possible up front, match precisely so alerts can be trusted, reach the user wherever they are, and let a browser extension do the last, most time‑sensitive click while leaving the actual booking in the user's hands.
By the numbers
accounts or passwords needed to create an alert
between availability checks on BC Parks
from alert to a site held in your cart
The Challenge
Catching a cancellation isn't hard because it's rare. It's hard because the window is tiny and the path to booking is long.
Manual monitoring: the only option was refreshing the reservation site, park by park and date by date
Partial matches: a site free for one night doesn't help if you need three, or if it can't fit your trailer
Seconds matter: by the time you find the site again on the reservation page, someone else may already have it
Trust: an unofficial tool that touches your booking has to be clear about what it does, and what it never does
Defining my design question
Framing the right question: what stands between a cancellation appearing and a camper actually getting it?
How might we turn a fully booked campground into a confirmed reservation by watching for cancellations on the camper's behalf, and getting them to the booking page faster than anyone refreshing by hand?
Understanding the booking race
I started by mapping every step a camper takes from "I want this weekend" to "I have a reservation", and timing where the minutes and seconds actually went.
Breaking the journey down showed that the slow part wasn't paying. It was everything before it: noticing the opening, remembering which park and dates it was for, navigating back to the right campground, switching to list view, finding the exact site and pressing Reserve. That sequence became the target.
Key findings
People don't want to search, they want to be told. The value is in the watching, not in another way to browse availability
An alert is only useful if it matches the whole stay, the right campground and the right equipment. A false alarm costs trust fast
The last mile is the bottleneck. Getting from the alert to the right site's Reserve button is where cancellations are lost
Asking for an account before showing any value is a reason to leave. Commitment should come after the user has built something worth keeping
My proposed solution
Design decision 1 – Build the alert first, ask for an email last
The Problem This Solved
Most alert tools ask you to sign up before you can do anything. For a free, single‑purpose product, that upfront wall is the most likely place for someone to give up.
The alert builder, with a live summary of exactly what will be watched
My Design Rationale
I designed the builder as five numbered steps (park, arrival dates, nights, sites, notifications) that anyone can complete without logging in. A sticky summary card updates as you go and translates choices into odds: "Watching 100 sites × 1 date = 100 chances to catch a spot". Only at the end do we ask for an email, verified once with a 6‑digit code or magic link. There is no password, ever.
Why I Made This Decision
By the time someone is asked for their email, they've already invested in a trip they care about, so confirming it feels like the natural last step rather than a gate. The summary card also sets honest expectations: watching more sites and dates means more chances, and the user can see that trade‑off directly.
Outcome
Alerts can be fully set up with zero accounts or passwords
Matching on whole stay, campground and equipment means alerts are actionable, not noise
Design decision 2 – Reach people wherever they are, loudly
The Problem This Solved
A cancellation found at 2pm on a Tuesday is useless if the alert sits unread in an inbox. A single channel wasn't fast or reliable enough for something that disappears in seconds.
The in‑page alarm: a looping siren, one clear action, and a way to stop it
My Design Rationale
I layered the alerts: email with a direct link to the exact site and dates, browser push notifications that work even with the tab closed, and, when the dashboard is open, a full‑screen "Spot found — be quick!" overlay with a siren and a single "Open reserve page" button. The dashboard header shows each channel as a status pill, so it's obvious at a glance what's on, what's off, and how to fix it.
Channel status pills turn invisible settings into something users can see and fix
Why I Made This Decision
Urgency is the whole product, so the interface is allowed to be loud, but only when it matters. A 10‑minute cooldown per site and date keeps the same opening from alerting over and over. Early use also surfaced quieter problems, like Chrome putting the dashboard tab to sleep, which I solved so the alarm keeps working in the background.
Outcome
Multiple redundant channels, so one missed notification doesn't mean a missed site
Clear, fixable channel states instead of hidden browser permissions
Design decision 3 – Do the last click for them, but never the booking
The Problem This Solved
Even with a direct link, users still had to find the site on a busy results page and press Reserve before anyone else. On top of that, browsers often block a page from opening a new tab on its own, so the reserve page sometimes didn't open at all.
"Book in one click, not fifty": the extension turns every alert into a cart hold
My Design Rationale
I designed a small Chrome extension that reads the alert link, finds that exact site on the BC Parks page and clicks Reserve, so the site drops straight into the user's own cart. Then it stops. It also opens the reserve tab through a trusted channel the pop‑up blocker doesn't touch. Installing it is a three‑step guide with a copy‑to‑clipboard field, and its toolbar popup is a single on/off toggle.
Install guide and a plain‑language promise: a booking is never completed automatically
Why I Made This Decision
Automating the booking itself would have been faster, but it would also mean handling payment and acting on someone's behalf in a way that feels unsafe. Stopping at the cart hold keeps the user in control, with narrow permissions and copy that says exactly where the automation ends.
Outcome
The time‑critical step goes from a manual hunt to a single click
Users keep full control of checkout and payment, which builds trust
Design decision 4 – Design for the phone in your pocket
The Problem This Solved
Campers are rarely at a desk when a spot opens. But the extension and the in‑page alarm are desktop‑only, and on iPhone, push notifications only work once the site is added to the Home Screen.
Landing, alert builder and passwordless log in on mobile
My Design Rationale
Rather than shrinking the desktop experience, I adapted it to what a phone can actually do. Desktop‑only channels and the "Add to Chrome" banner are hidden on mobile, the search bar stacks into a single thumb‑friendly card, and the phone version of "How it works" walks people through adding CampingScout to their Home Screen so push alerts can reach them.
Why I Made This Decision
Showing features a device can't use is a broken promise. Being honest about what works where, and guiding people to the setup that makes alerts reliable, matters more than visual parity.
Outcome
No dead ends on mobile: every visible option works on that device
A clear path to push notifications on iPhone
A brand that feels like the outdoors
Warm, a little retro, and calm, until it needs to be urgent.
I built a visual language from the experience itself: deep olive and cream from the forest and the tent, a bright campfire orange reserved for actions and alerts, and a Cooper Black wordmark with a nod to classic park signage. The same system carries across the web app, the emails and the extension, so an alert always looks like it comes from the product you trusted with your trip.
The landing page leads with the problem and puts the alert builder right under it
What I got from this project
Shipping teaches you things a prototype can't
Designing and building CampingScout myself meant every decision met reality quickly. Things that looked fine in a mockup, like a browser tab going to sleep, a pop‑up blocker, or a raw log nobody could read, only showed up once real people relied on it. Replacing that log with a simple per‑user activity feed, and adding edit and duplicate for alerts, came straight from watching how the beta was used.
Knowing where to stop is a design decision
The most important line in the product is the one the extension won't cross: it holds the site, and the user books it. Being explicit about what the product will never do turned out to be as valuable for trust as anything it does. I also learned to hide features that weren't ready, like SMS alerts, rather than ship them half‑working, keeping the experience simple while the groundwork stays in place.