One OS – Back office Case Study – Matthew Quain Design

The Hidden Steps: A UX Audit of the Legacy Vehicle Booking Flow

How the backoffice “Create Booking” wizard buries its own steps inside pop-ups, splits customer intake into two disconnected paths, and leaves vehicle extras out of the booking conversation entirely.

EXECUTIVE – SUMMARY PART 1

Booking flow errors, told through a series of pop-ups

The legacy Create Booking flow gets a reservation from open screen to confirmed booking, but the path there is harder than the task requires.

Every one of its four steps is rendered as its own floating modal dialog, stacked on top of the last with no shared frame and no visible progress. Step 1 also leans on a pattern that doesn’t fit the decision it’s asking an agent to make: routing them to “search for an existing customer” or “create a new one” through a pair of tabs, when tabs are meant for content a person might switch between at will — not a one-time either/or fork at the start of a task (see Finding 2). Across the three screens where a vehicle, its dates, and its price are actually chosen, there is no provision anywhere for the extras — a roof rack, a child seat, an automatic‑transmission upgrade — that are a routine part of any rental conversation. Those have to be added after the fact, on a separate screen, once the booking already exists.

None of this is a capability gap. It’s an information‑architecture and consistency problem, and it shows up as slower bookings, harder onboarding for new agents, and avoidable mistakes at the counter. The findings below walk through the flow in the order an agent experiences it, illustrated with the five screens that make up the journey.

F I N D I N G – 1

Every step lives inside its own pop-up

The flow has four steps, and the interface says so — but only in body copy (“Step 1:”, “Step 2:”…) printed inside each dialog. There is no persistent stepper, progress bar, or breadcrumb rendered above or around the content that stays on screen as the agent moves forward. The only place “step 4 of 4” exists is a sentence the agent has to read and remember.

Compounding that, each step is its own independent modal window, floated on a dimmed backdrop, rather than steps within one continuous wizard frame. When Select Tariff Group opens, the Select Customer dialog it replaced is simply gone — no shared header, no carried-over chrome, nothing visually tying the two together. Functionally, the agent isn’t moving through a wizard; they’re opening a new pop-up on top of the last one, four times in a row.

Fig 1 – Step 1, opened as a floating dialog. The gold outline traces the full modal boundary — this is the entire “Step 1of 4,” rendered with no visible relationship to the page underneath or the steps ahead. An agent mid-flow cannot see how many steps remain, cannot jump back more than one screen at a time via a Back button.

Fig 5 – Step 4, the last dialog in the stack. Four screens later, this is still just another independent pop-up, floated on its own dimmed backdrop with no shared frame or carried-over progress tying it back to Step 1.

F I N D I N G – 2

Step 1’s two tabs within a pop up

“Select Customers” splits into two tabs — Station Search for an existing customer, New Customer for a new one — but tabs are the wrong pattern for this kind of decision. They’re built for content a person might switch between at will, not a one-time fork made once at the start of a task. Fig 1 shows the baseline: Station Search is a plain customer lookup, with the New Customer tab sitting beside it as the only signal that “this customer doesn’t exist yet” is even an option.

Fig 1 – Station Search tab. A pure customer lookup with a separate tab for adding new customers. A limitation of using as series of modals in steps as oppose to a guided breadcrumb navigation.

Fig 2- New Customer tab. A “Create an On-Line Account” checkbox sits right at the top of the form with no explanation of what checking it actually does — whether it emails the customer a login, changes which fields below become required, or just flags the record for later. The agent is left to guess, or ask, before deciding whether to check it.

F I N D I N G – 3

A Complex Vehicle Search — options & extras unavailable in the booking process

From here the flow is straightforward: lock in a tariff group, station and dates (Step 2), pick a specific vehicle unit by VIN (Step 3), then review and confirm (Step 4). What’s missing is anywhere in between for the add-ons that come up in almost every real rental conversation — a roof rack, a child seat, upgrading to an automatic transmission, extra insurance, a GPS unit. None of it is offered across any of these three screens.

As it stands today, those options only become available after the booking already exists, on a separate screen the agent has to leave this wizard to reach. That turns what should be one continuous conversation with the customer — “would you like anything else with that?” — into two disconnected trips through the system: finish the base booking blind to any extras, submit it, then go find a second screen to attach what the customer actually asked for.

Fig 3 – Select Tariff Group (Step 2). Pick-up/return station and start/end date-time are entered here — the one place in the flow that now captures them, regardless of which Step 1 tab the agent used. The tariff list beneath it shows a per-day rate but no path to add options at this or any later step. Worth questioning the step boundary itself: “Tariff Group” is also a column on every row of Step 3’s vehicle table (Fig 4), and a customer booking through a dealership normally chooses a vehicle first, not a tariff group — so Steps 2 and 3 could reasonably be one screen.

Fig 4 – Select Vehicle (Step 3). The agent chooses a specific physical unit by scanning VINs and license plates, with no thumbnail, badge, or highlight tying rows back to the tariff and model already chosen a screen earlier. Still no mention of extras. The “Tariff Group” column repeats what Step 2 (Fig 3) just asked for — since that data is already sitting right here next to each vehicle, splitting tariff and vehicle selection into two separate steps looks harder to justify than combining them into one.

Fig 5 –Summary (Step 4). “Vehicle Details” is fully itemized — tariff group, manufacturer, model, VIN, plate, status — with no equivalent line for extras, because at the point of confirmation none can exist yet. “Confirm Booking” finalizes a reservation that, by design, cannot yet include the add-ons the customer may have asked for. Nor is there a running price total.

WHY IT MATTERS

All of these findings call for new functionality — the flow is limited in scope and creates additional work and unnecessary confusion. What it needs is fewer, more honest boundaries: one continuous wizard instead of four stacked pop-ups, and a path for extras that sits after vehicle selection. The use of pop-ups should be reserved for viewing additional details or adding new details (+ new customer) on steps which already have large data sets.

U X A U D I T · PA R T T W O — R E V I E W I N G T H E C O R R E C T I O N S

From Stacked Pop-Ups to One Guided Wizard

A follow-up review of the updated Create Booking flow, captured during a live walkthrough of the dealership back office. Every finding from Part One has a direct answer here.

E X E C U T I V E S U M M A RY — PA R T T W O

The wizard finally looks and behaves like one flow

The updated Create Booking flow was reviewed live against the dealership’s day-to-day back-office use, working the same journey an agent runs many times a day.

All four steps now live on one page frame behind a persistent stepper, instead of four independent pop-ups with no shared chrome. Tariff group and vehicle are chosen together in a single step, freeing up a real step for options and extras instead of a bolt-on screen reached after the booking exists. Price is visible from the moment a vehicle is picked, a countdown now holds that vehicle for the agent while the rest of the wizard is completed, and Confirm Booking presents the vehicle, driver, and dates as something an agent can actually verify at a glance rather than read line by line.

C O R R E C T I O N 1

Tariff and vehicle selection are now one step

The old Step 2 (Select Tariff Group) and Step 3 (Select Vehicle) are merged into a single “1: Select Vehicle” screen. Every vehicle card already carries its tariff class and per-day rate, so the agent picks a vehicle once instead of narrowing by tariff group first and then hunting through a separate VIN table for a match — the exact duplication flagged in Part One’s Finding 3.

The step that duplication freed up is now genuinely useful: “2: Options & Extras” gives insurance tiers, kilometer packages, a child seat, an additional driver, a roof rack, and a navigation system their own screen, captured as part of the same booking before it’s confirmed — instead of a separate screen the agent had to leave the wizard to reach.

Fig 6 – Step 1 — Select Vehicle. Tariff class and price now sit on the vehicle card itself, resolving the Step 2/3 overlap raised against Fig 3 and Fig 4 in Part One.

Fig 7 – Step 2 — Options & Extras. Roof rack, child seat, additional driver, insurance tier, and kilometer package are all captured here, mid-wizard, instead of on a screen reached only after the booking already exists.

C O R R E C T I O N 2

A persistent steps via breadcrumbs replaces four independent pop-ups

Every screen in the updated flow now carries the same header: “1: Select Vehicle > 2: Options & Extras > 3: Customer Details > 4: Confirm Booking,” with the current step highlighted and completed steps checked off. It stays on screen for the whole journey, so an agent always knows where they are and how many steps remain — directly answering Part One’s Finding 1.

Completed steps are checked and clickable, the agent can also jump straight back to an earlier one instead of only moving forward. That turned out to matter in practice during the live back-office review: a customer decides mid-booking, or even while an agent is already on Customer Details or Confirm Booking, that they’d like a roof rack or a child seat after all. With the old flow that meant finishing the booking blind and finding a separate screen afterward; with the stepper, the agent clicks back to “2: Options & Extras,” adds it, and continues forward again without losing anything already entered.

Fig 8 – Step 3 — Customer Details. The agent can see the full journey, their place in it, and can revisit a completed step — including the one that holds the extras a customer asks for late — instead of being limited to whatever the current pop-up shows.

The stepper also reflects a broader change in how the flow uses pop-ups. The one pop-up remaining in the flow is launched from a “+ New Customer” as dealership preference was to allow maximum space to search for current customers via a table.

Fig 9 – Create New Customer. A modal used for what modals are for: adding one new record on top of a page that’s otherwise built to browse a large table. This allows for the agent to remain on step 1 and add new customers to the table directly via the one time modal.

C O R R E C T I O N 3

Price is visible from the first screen, and a reservation timer protects the vehicle

Each vehicle card at Step 1 already shows its price, so the agent and customer see cost before anything is committed to. From Step 2 onward, a running Total (Gross) and Total (net) sit fixed in the top right of every screen — the running total that Part One’s Finding 3 flagged as missing from the old Fig 3 and Fig 5 now follows the booking all the way through.

A new “Reserved For” countdown appears next to that total from Step 2 on, holding the selected vehicle for the agent while they finish Customer Details and Confirm Booking. That closes a conflict window the old flow left open: nothing previously stopped two agents from independently working toward the same physical unit at the same time.

Fig 7 – Reserved For, and a running total. The countdown holds the vehicle against double-booking while the agent completes the rest of the wizard; gross and net totals stay visible from step 2 onwards.

The customer can be quoted a running total at every step, and the countdown prevents the exact double-booking conflict an agent-facing tool has to guard against.

C O R R E C T I O N 4

All relevant information to confirm a booking

The vehicle is presented as a single card — photo, license plate, VIN, tariff group, color, and station — rather than a plain itemized list, while Driver Details and Dates & Times sit beside it in their own clearly labeled blocks. An agent can verify who’s driving, when, and from where at a glance before the customer enters a binding contract.

A new “Price Details” button opens an itemised breakdown — vehicle base price, insurance, child seat, delivery and pick-up fees, early and late fees — so the agent can answer “what am I actually paying for” in seconds instead of retracing the whole flow with the customer.

Fig 10 – Step 4 — Confirm Booking. Vehicle, driver, and dates are each scannable at a glance, with Price Details one click away.

Fig 11 – Price Details Modal. An itemised breakdown — base price, insurance, extras, and fees — available without leaving the confirmation screen.

WHY IT MATTERS

Every finding from Part One has a direct, working answer in the updated flow: a stepper that makes the wizard legible and reversible, tariff and vehicle folded into one step with extras given a real one of their own, price and a reservation timer visible throughout, and a confirmation screen built to be verified rather than read. What was four disconnected pop-ups is now one continuous booking, with the modal pattern reserved for the one place it actually belongs.