← All work

          03 — Terrain survey platform
          Product designer · Geospatial analytics product
          Web · Tablet · Android
        

Killed the two-hour onboarding call

Aerial survey software for international clients: upload imagery from a survey flight, train a detector, find objects, get billed for what you used. Every new customer needed an hour and a half of hand-holding from the engineers before they could do any of it.

What the audit found

I ran a UX audit with a junior designer and it turned up two things at once: roughly half the functionality on screen didn't work yet at that stage, and the user flow itself was broken — nothing enforced the order the product actually required. The onboarding call wasn't a courtesy, it was the missing interface.

How we worked

Interviewed the founders and the experienced users to reconstruct how detection and billing really worked, mapped user stories and a CJM, wrote down the technical constraints, and only then went to screens. Several start scenarios had to merge with a payment scenario mid-flow — that's what the flow map was for.

The design principle

Progressive disclosure: the interface opens up as the user completes each step, almost like a game. One CTA per screen instead of a wall of equally loud buttons, with text and picture hints where the concept was genuinely new.

Before: everything at once

The old map screen

Four tool groups, two panels, and two competing "Add" buttons on first open — with no indication that annotating objects had to happen before training, or that training had to happen before anything could be detected. A new user's only viable move was to ask someone.

The old survey map interface — Before — every tool available, no order implied, half of it not yet functional.

After: one step at a time

Onboarding as a sequence

The map opens with a single offer — train a detector for free, pay only for real results — so the free path is the obvious first move and the pricing model is explained by doing it. Then one prompt at a time: annotate an object, draw a working area, run the search.

Start screen with the free training offer — Step 1 — one offer, one button. The business model is the onboarding copy.

Annotating an object on the map — Step 2 — annotate what you're looking for, with the rule stated in the prompt.

Finding objects set-up dialog — Step 3 — set up the search in plain language: what, where, and simple shapes or complex area.

Making the money legible

Payment, the second brief

Billing worked off a deposit that drained at different rates depending on how heavy the task was — the kind of model that feels arbitrary unless the interface shows its work. The cost appears at the moment of the decision, inside the flow, not in an invoice a week later.

In the payment section, users could see what each line item was for and who on the team ran it, follow the history, and add or remove colleagues themselves — the questions that had been arriving as support emails.

Cost shown in the flow with a Pay button — Results are visible for free; the price to unlock them sits right where the choice is made.

Payment settings, bills and history — Every charge itemised by person and action — spend stops being a mystery.

Flow map of the object-finding scenario — The existing object-finding scenario, reconstructed screen by screen against the logic it had to satisfy — the audit board we worked from, and where the payment step had to fit.

90 min → 0engineer-led onboarding removed

~50%of visible features weren't working — found by audit

3platforms, one flow model

Shippedsold and deployed to client

Back to all work ← Home Next: a course built to reach the first deploy Open →