Fleet-management workflow redesign: from searching to finding what's wrong.

Nobody opens a fleet tool to browse. They open it because something is wrong.

PumpPay is a B2B fuel-management platform. Fleet owners use it to control how their vehicles and drivers refuel, at their own depots and at public fuel stations.

I'm the product designer at PumpPay. I oversee the design of the application and its build, so that what ships matches how our users really work. This case study covers one change in how I understood those users, and the redesign that followed: the management screens moved from a search-first model to a filter-first one, and editing moved out of separate pages into a panel beside the list.

The old flow assumed you already knew what you were looking for.

The management screens were built around search. You went to Vehicles, found the one you wanted and clicked it. A panel opened with its details. To change anything you clicked Edit, which took you to a separate page. You made the change, saved, and were returned to the panel, which you then closed to get back to the list.

Two things were wrong with that. Every edit pulled you away from the list, so you lost sight of the other vehicles while working on one. And search only helps when you know which vehicle has the problem. Most of the time, that is exactly what the person doesn't know.

A fleet owner's question is "what isn't working?", not "where is this vehicle?"

Fleet owners are busy. They want the fleet to run without their involvement, and when the platform is funded and configured, it can. So when an owner, a fleet manager or an admin clerk does sit down at the screen, it is usually because something is blocking the pipeline.

A filtered list on the left, the selected record on the right.

Filters narrow the fleet to the vehicles that need attention. Selecting one opens it in a panel beside the list, where it can be edited and saved without leaving the page.

● Live in production

Filters can be stacked, and they are saved to the account, so the view someone set up yesterday is the view they see today. Search is still there, and it behaves like one more filter: type a registration and it narrows the same list, alongside whatever filters are already on. The same pattern now runs on the merchant side of the platform, where site managers have the same need to spot what is out of line.

Three things the screen has to make quick.

Each one was designed so the list never leaves the screen.

1. Find what's wrong

The filter panel covers what a fleet office actually asks about: date, driver, vehicle, fleet, site, transaction status and type, on-chain status, limit status and type, province, fuel grade and reward programme. Every selected filter has to match, and the panel says so in plain words, so an empty result is explained instead of looking broken.

2. Look without losing your place

Selecting a row highlights it and opens its details in the right-hand panel. The arrow keys move up and down the list and the panel follows, so checking ten vehicles doesn't mean loading ten pages.

3. Fix it where you found it

Create or change a refuel limit, edit the vehicle, change a driver's permissions, disable a vehicle or freeze a card, all inside the panel. A limit is set in rand and litres with an expiry; once it is used up, another can be issued. A confirmation message appears and the list updates behind it.

I spent a day on site, then changed my mind.

There was no long research programme. I visited two customers in Johannesburg on the same day: Woodford Car Hire at OR Tambo International Airport, which refuels at its own on-site depot, and Siyathembana, whose drivers fill up at public fuel stations. At each I spoke first with the people who run PumpPay in the office, then with three or four of the drivers who use it at the pump.

Until then I had been arguing for the opposite. My roadmap proposal doubled down on search, including bringing back past searches. The site visits and that conversation showed me I was improving the wrong thing. The founder approved the change of direction, and the rest of the team came on board once the reasoning was laid out.

Two ideas I let go of.

Both looked good. Neither served the people using the product.

A prototype everyone could click through.

I built a Figma prototype that showed the separate screens collapsing into one list and one panel, and took it to each part of the company.

Design work only lands if the people building and selling it understand the problem it solves, so the prototype was as much an explanation as a specification. I wrote the specs in Figma, took part in setting the acceptance criteria, and checked the build against the design as it came through.

Four decisions that shaped it.

Each one came from the same idea: reduce what the person has to remember.

Visible beats clever.

The hardest part was not technical. It was giving up ideas I liked as interface design because they made the product harder to use. The work was solved as a user-experience problem first, and the interface was drawn to serve that.

What changed, and what I'd do next.

The pattern went to development in Q1 2026 and is live. The core screens use it today, and the rest of the product is on the roadmap to follow.

I didn't measure this as carefully as I should have. Support requests go to our sales team first, and far fewer have been passed on to me since launch, but I don't have a number. By my own estimate, checking a 20-vehicle fleet one vehicle at a time, at about a minute each, is 20 minutes. With filters, the vehicles that need attention are on screen within a minute or two. Adoption was smooth. Customers understood the change without being walked through it.