Vehicle Operations Platform

The brief was to replace the spreadsheets. They were accurate, though. Whoever kept one was out in the lot with the cars.

What made the job hard was the number of places it was spread across. One car moving through cleanup meant a form, a sheet, a tab for the cleanup request and another for stock out. Whoever was doing it had to remember where the car had got to. Anything outside Google’s tools was done by hand. To reach the dealer system or the finance platform you picked up the phone. The tables keep the part of the spreadsheets that worked, which was colour you could read without opening anything, and put the rest on a screen people are already in.

Research with service advisors, cleanup managers and reception, the model of the stages a car goes through, the table and Get Ready screens, the print layouts, and the shared set of parts they are all built from.

I started with a junior UX designer I was tutoring. She left as the Cleanup module finished and Get Ready began. I carried on alone, then brought another designer up to speed. They moved to a different project soon after, and I was on my own again. Two more joined near the end. Four changes, and each one meant going back over the vocabulary and the stage model from memory.

Everything on this page is a recreation. The client is not named; their branding, real identifiers, customer data and internal documents are replaced with fictional equivalents built for this portfolio. Figures appear only where they describe my own process, and anything commercially sensitive is left out.

The platform’s own name is confidential, so “Vehicle Operations Platform” is my description of what it does. The marque, vehicle identifiers, branch names, customer records and staff names on these screens are invented, though the screens behave the way the real ones do.

The situation

Each store had its own way of working: its own forms, its own spreadsheets, its own process. Everything reached the same place at the end, but each store got there differently, and almost nothing was standard across the group.

The spreadsheets updated live, so that was not the problem. The problem was how many places a person had to look. On an ordinary day someone here worked across ten or more open tabs: cleanup request forms, stock in, stock out, and the sheets behind them. The number of clicks, scrolls and tab switches depended on how many of those tabs the task touched, and anything the screens did not show was remembered. The work was spread out, and keeping track of it took attention people needed for the rest of their job.

User feedback

The project started on a big shared board, not in a design file. We mapped the existing operation step by step across five dealerships and one cleanup centre, from a car arriving on a truck to a customer being handed the keys. Next to it we wrote down the tool they already had: a form feeding a read-only spreadsheet with four tabs, exactly as it worked in practice, including its standing instructions.

What changed the design came out of remote working sessions with the people doing the job: service advisors, cleanup managers and dealership receptionists. This was not lab research and there is no sample to quote. The people who would use it said what went wrong, in their own words. Two of them are quoted below.

One of the things that came out of those sessions was about blame. When a car was late, cleanup was usually blamed, because cleanup is the visible stage: the car is parked there and clearly not finished. A cleanup manager often has less information than anyone else involved. Cars arrive with keys and nothing else, requests are changed afterwards by someone they never speak to, and there is no view of what is coming next week. The delay usually started earlier, and there was no way to show that.

One record, three sets of states

Three of the five modules keep a vehicle record, and each needs different information from it. The register holds what the car is to the business: stocked in, stocked out, delivered, or void. Get Ready holds what still has to happen to it. Cleanup holds what the cleanup centre is doing with it.

So each module has its own set of states, and nobody is shown one they have no use for. A stocked-in status is not shown in Cleanup, and a cleaning status is not shown in the register. The one state that appears twice is the handover: Get Ready sets Ready For Cleanup, and that is the state Cleanup picks the car up in.

Each module also has its own way of writing off a record. The register voids a car. Get Ready cancels a job. Cleanup can do either, and can also mark a request as a duplicate. A duplicate is not the same as a cancellation, and duplicates only happen where requests are raised.

The register, and the modules around it

Each team opens the module it works in and sees the same car the others see. Every action on a car is recorded against the person who made it: the vehicle record shows the last one, and the log shows all of them.

Cancelling a job, sending a car back to stock in and voiding a record each ask for confirmation, and say plainly that the action cannot be undone. The machines are shared, but each person signs in with their own account, so an accidental change is recorded under the name of whoever was signed in.

It is a desktop system, and that was deliberate. Almost everyone here works at a desk for hours, so the tables are dense: many rows on screen at once, small buttons, keyboard shortcuts assumed. Drivers are the exception. They move cars between stores all day and never sit at a desk, so their screen is built for a phone. The rest of the system stays on the desktop.

The cleanup manager no longer assigns anyone. The client asked for that. A car joins a queue the moment a dealership requests it, soonest delivery date at the top, and a driver takes the next one down. What the driver’s page shows is deleted five minutes later. He can still mark a car picked up. He just does not decide who goes.

The look changed twice

The first build used Material Design, because the client asked for it by name. After the first module shipped they said it felt dated and asked for something more modern, and they were right, though not for the reason they gave: that library is built for consumer apps, and its shadows, spacing and animation are wrong for a table somebody reads for eight hours.

So we evaluated alternatives and rebuilt on a variation of shadcn/ui, drawing most parts from scratch. That component set was then used beyond this project. It became what the reseller platform was built from, and later an internal design system.

Key decisions

Three decisions, below. The first two settled an argument between two groups of users who both had a case. The third was mine, and it was wrong.

What testing changed

Ten rounds of testing ran throughout the project, remotely, with the people who would use it. One was what the front-desk lead called a chaos test: several receptionists working the same screens at once, at the volume of a real delivery morning. It was the first time the system was used by more than one person at a time, and that changed what we found.

By the later rounds the problems listed at the top of this page were no longer coming up. No tab switching, no work done by hand, no missing record of who did what. What came up instead were ordinary usability problems, and those were fixed in turn. This is what testing showed, not what a store has reported. The system is still in deployment testing and has not shipped.

What I’d do differently

The brief was three months and narrow. The project has run two years and the scope is still growing. We were helping the client work out what they wanted as we went. It started with three days to mock up a “what if we built this for you” version. They accepted it. Most of what I would do differently comes from that.

None of these are about a screen. They are about the order things were done in, and about not planning for a project that was always going to grow.