One OS – Back office Case Study – Matthew Quain Design

One-Os Back Office: A UX Audit of the Legacy Vehicle Booking Flow

One-Os Back office is a b2b software managing all data around vehicle booking. This includes a variety of large data sets around customers, bookings and vehicles along with dashboards and design configurations for customer facing web sites. In this case study I reviewed How the back office “Create Booking” user flow buries its own steps inside pop-ups, splits customer requests into two disconnected paths, and leaves vehicle extras out of the booking conversation entirely.

EXECUTIVE – SUMMARY PART 1

A booking flow told through a series of pop-ups

The legacy booking flow approaches each step from a hard coded perspective, organising each selection to reduce development time with large data sets. Every phase of this four-step process renders as an isolated, floating modal dialog. These modals stack on top of one another without a shared framework or any visual progress indicator.

For example, Step 1 routes agents to “search for an existing customer” or “create a new one” using tabs due to the limitation of using a series of modals for a booking flow. Similarly both the find vehicles and select tariff modals require searches via large table sets increasing the complexity while only providing the user a back button to return to the previous step. The use of a back button here is not intuitive and can be easily confused for ending the booking flow entirely.

Finally, the summary screen has no provision for add-ons—such as roof racks, child seats, or transmission upgrades. Because these extras are a routine part of rental conversations, agents are forced to add them after the fact on a separate screen once the booking is already finalised. Additional price details and overall cost of booking is also not present till after the booking is complete.

This is fundamental flaw in information architecture and UX consistency. The downstream impact is measurable: slower booking times, steeper onboarding curves for new agents, and avoidable errors at the counter. The following findings break down the flow chronologically through the agent’s journey, accompanied by the five screens that comprise the current experience.

FINDING 1

Every step lives inside its own pop-up

Although the flow consists of four distinct steps, the interface only communicates this progression through contextual body copy (e.g., “Step 1:”, “Step 2:”) nested inside each dialog. The system lacks a persistent stepper, progress bar, or breadcrumb component within the frame or global layout to anchor the user. Because this critical status is reduced to static inline text, the system fails to communicate an explicit system state. This forces the agent to rely on their own working memory to track their location in the workflow, significantly increasing their cognitive load.

Key UX Issues

Absence of a Persistent System State: Progress is only communicated through static contextual body copy (e.g., “Step 1:”, “Step 2:”). Without a persistent stepper, progress bar, or breadcrumb component, the interface fails to broadcast an explicit system state.
Elevated Cognitive Load: Because status indicators are reduced to inline text, agents must actively read and remember their location in the workflow, forcing them to rely heavily on working memory to track their progress.

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 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. Navigation is slow via a back button to return to previous steps. There is also no option to add extras such roof rack, child seat till after the booking is complete. These issues resulted in slow booking times and frustration with agents while reviewing the booking flow in dealerships.

FINDING 2

Step 1’s two tabs within a pop up

“Select Customers” splits into two tabs as a result of placing the booking flow within a set of modals. In general these large data sets via table searches and adding new customers would be best served via breadcrumb navigation. This navigation with defined steps allow the user to return to previous steps easily. While saving modals to open in this instance a modal to add new customer to existing table.

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 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.

FINDING 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 complete this modal booking flow to add these extras. 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 breadcrumb navigation 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.

UX AUDIT PART 2 – TESTING

Low, Mid & High Fidelity Designs

Following the review a series of draft designs were created to test both with stakeholders and customers.

Low-fidelity wireframes: The four-step skeleton, the fields shown at each step, the table and modal sub-flows all need a first pass of clearance from business stakeholders — confirming the sequence matches how a booking actually gets made — and from development, who can flag early whether something like the customer table pagination or the reserved-timer countdown is feasible as sketched.

Mid-fidelity concept: Once the structure is agreed, this draft adds real copy, hierarchy, and enough visual treatment for stakeholders to react to actual content — field labels, pricing, table columns. It’s also the point where development can start commenting on technical implementation in more concrete terms: which elements are dynamic (radio selections, totals recalculating, table sorting), which are static, and where component reuse from the existing design system applies.

High-fidelity direction. Rather than finalizing a single design from this draft, the next step is to build out two distinct flow variants at this fidelity and run them past real customers — through quick preference or usability testing — to see which sequence, layout, or interaction pattern they complete more confidently. Only after that feedback is reconciled with stakeholder priorities and a final technical review from development, the final design shown below was implemented.

UX AUDIT PART 3 – REVIEWING THE CORRECTIONS

From Pop-Ups to One Guided Booking Flow

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.

EXECUTIVE SUMMARY PART 3

Breadcrumb navigation ensures streamlined vehicle bookings

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 (breadcrumbs), instead of four independent pop-ups with no shared chrome.

Tariff group and vehicle are merged together in a single step, freeing up a real step for options and extras instead of editing additional details after the booking is completed. Price is visible from the moment a vehicle is picked, a countdown now holds that vehicle for the agent while the rest of the booing steps are completed. The Confirm Booking steps now presents the vehicle, driver, and dates as something an agent can actually verify at a glance rather than read line by line.

CORRECTION 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.

CORRECTION 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.

CORRECTION 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.

CORRECTION 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.