Danny Florián

Aspira

Rainger — reservations and permitting for public lands

2024 — 26

Park staff finish the routine reservation 64% faster now that it no longer spans three separate applications.

Role
Principal Product Designer. Design lead on the Rainger platform.
Team
2 PMs · ~14 engineers across three squads · 1 researcher · agency implementation partners
Timeline
2024 — present. Front desk and admin shipping in staged releases.
Owned / influenced
Owned the platform information architecture, the front desk, the product and permit model, the admin and identity surfaces, and the design system. Influenced API shape, migration sequencing, and agency onboarding.
Level of detail

Full case study — context, explorations, tradeoffs and how each number was measured. The short version. Switch to deep dive for context, explorations, every tradeoff and measurement notes.

The business problem

Every agency contract was being quoted against seventeen different applications.

Aspira runs the reservation and permitting software behind public lands — the systems agencies use for campsite bookings, day-use parking, boat launches, pavilion rentals and hunting permits. Contracts are multi-year, won through public RFP, and they renew on exactly one thing: whether the agency’s own staff can run their parks without calling support.

The portfolio had grown largely by acquisition and had arrived at roughly seventeen separate applications with overlapping concepts and no shared model. Every new agency deployment meant standing up, integrating and training across some subset of them. Implementation cost per contract climbed, timelines stretched, and in competitive bids the seams showed in the demo — which is a bad place for seams when a procurement committee is watching.

Downstream the cost was concrete. A seasonal ranger taking a Saturday-morning walk-up booking would check availability in one system, find or create the customer in a second, and take payment in a third — typing the same name three times with a queue forming behind the counter. Seasonal staff turn over every year, so that training cost is annual, not one-time.

The reframe

There was never a campsite, a permit and a rental. There was one bookable thing with a unit of time.

Seventeen applications had modelled seventeen nouns, and each was certain its noun was special: a campsite sold per night, a pavilion per day, a boat launch per use, a round of disc golf per round, marina dry storage per month. Underneath, every one is the same object — something with capacity, availability and a unit of time. The differences that felt fundamental turned out to be pricing rules and cancellation policy, and those are data, not separate products. Once the model collapsed to one noun, a single reservation flow could serve all of them, and the front desk finally had something to be a front desk of.

The work

One grid for availability, one flow for anything you can book.

Rainger front desk showing a fortnight of campsite availability, with reservations, maintenance blocks and a flagged booking.
The front desk. Products down the side, dates across the top, and every state a site can be in — booked, held, under maintenance, flagged — legible without opening anything. Status is never carried by colour alone.
Rainger products index listing cabins, yurts, RV hookups, boat slips and permits with location counts, price and unit of time.
The model, made visible. Reservations and permits sit in one index because they are one thing; the column that actually matters is the unit — per night, per day, per use, per round, per month.
Rainger checkout with payment fields on the left and a running reservation summary on the right.
Checkout, with the reservation restated beside the payment fields. Staff take money on behalf of an agency, so the terms being agreed to are the agency’s and are named as such.
Rainger user administration showing accounts across Aspira and Rhode Island DEM with active, locked and inactive statuses.
Identity across organisations. Aspira staff and agency staff share one directory with different reach, because support cannot help an agency it cannot see.
A Rainger user profile with account actions for password reset, unlock, resend invitation and deactivate.
The account actions a park administrator actually performs, written as plain outcomes rather than system verbs. Most support calls in season are a locked account on a Saturday.
Rainger brand system: wordmark on light and dark, and lockups over outdoor photography.
The brand runs on top of the platform work. Rainger sells to procurement officers and is used by rangers, so the identity had to be credible in a bid document and unembarrassing on a sign at a trailhead.

Explorations that died

  • 01 / 03

    A launcher for the seventeen

    It made the fragmentation navigable instead of removing it. Staff still re-typed the same customer into three systems — we would have shipped a tidier table of contents for the same problem.

  • 02 / 03

    A separate flow per product type

    Five product types meant five flows to maintain and five places for refund and cancellation policy to quietly drift apart.

  • 03 / 03

    Agency-configurable screens

    Requested in nearly every discovery call. Every configurable surface becomes a support surface and makes the next migration harder. We configure the data and fix the screens.

Tradeoffs

What got cut, and why.

  • Per-agency theming. Agencies wanted the software to look like their own. They get a logo, a name and a single accent colour. Anything beyond that turns one product into forty products at QA time, and public-sector accessibility obligations have to be verified against every combination — a promise I was not willing to make forty times.
  • The legacy report suite. Dozens of reports had accumulated over the years and most were run by nobody. We shipped the handful with real usage plus raw export, and made agencies ask for the rest. Some of those requests are still open, and that is the honest cost of the decision.
  • Switching the old applications off. The seventeen do not die on a date. They are strangled surface by surface, which means dual-write paths and reconciliation for as long as the migration runs. Slow, expensive, and the only version that does not risk an agency’s summer season.
  • Field and offline use. Rangers work outdoors and often without signal, and that is a real product. It is also not this one: the front desk was designed for the desk it is named after, rather than shipping a compromised responsive layout early and calling the field case handled.

Impact

The routine reservation is 64% faster, on one screen instead of three applications.

  • 64%

    Faster to complete a walk-up reservation.

    Measured: instrumented task timing from search to payment confirmation, against a scripted run of the same scenario on the legacy applications. Pilot agency, front-desk staff.

  • 3 → 1

    Applications touched in the routine transaction.

    Measured: task analysis of the walk-up booking with front-desk staff at the pilot agency, before and after.

  • −41%

    Instructor-led training per seasonal hire.

    Measured: agency-reported training hours per seasonal staff member, first season on the consolidated front desk against the prior season.

Reflection

Collapsing seventeen nouns into one was the whole job, and winning that argument took far longer than designing the screens — the model had to survive people whose product was being absorbed into it. What I would do differently is publish the model early as a plain-language document rather than a Figma file, so the debate could happen before anyone had drawn anything. The screens were never the contentious part.