Transporter
A fuel logistics system for MRS Oil Nigeria: one web portal and four apps, all working on the same trip. I joined a team of four designers mid-project, with no handover.
- Client
- MRS Oil Nigeria
- Role
- UX designer
- Team
- 4 designers
- Timeline
- 6 to 8 months
- Platforms
- A portal and four apps
Why it matters
Nigeria moves over 66 million litres of fuel a day, more than 90% of it by road tanker. Around 200,000 barrels are lost to theft and diversion every day, and tanker explosions have been linked to over 1,800 deaths between 2009 and 2025. So fuel logistics there is a safety problem as much as a money one.
The client runs 400+ stations and thousands of trucks a day. Dispatch, checks at the depot, and payment all acted on the same trip, with nothing connecting them. Transporter puts movement, verification and money on one set of facts, from the depot to the delivery.
Five platforms, one trip
An order placed in the portal becomes a trip for a driver, with a fuel voucher. An attendant scans the voucher at the depot, the depot manager sees what went out, and the customer tracks the delivery. Every platform acts on the same trip.
Portal
Orders, trips, invoices, vehicles, drivers and support.
Driver
The trip, its stops, the voucher.
Attendant
Scans vouchers at the pump.
Depot manager
Stock in every tank.
Customer
Orders and deliveries.
The call I made first
The designer who owned the flows had left, and nobody handed anything over. So for a few days I read our Figma file and the client's old system side by side. The old system handled the cases. Our new design didn't have flows for them.
Our redesign showed multiple customers, multiple orders and four cargo types on screen, with nothing behind them. Everything designed so far was one customer, one product, wet cargo.
| Order | Customer | Product | Qty |
|---|
Why stopping was hard
Nothing looked broken, the client hadn't raised it, and every Monday the client wanted to see more than the Monday before. Stopping meant reopening an approved flow and admitting we'd missed something.
So I argued about cost, not about being right. Orders feed scheduling, scheduling feeds trips, trips feed invoicing, and invoicing wasn't designed yet. It was fifteen days now against maybe two months later. It took several days to land. The client gave us the time without a fight.
The 15 days
The senior designer and I owned the rework, on a whiteboard first. We went after the edge cases too. The hardest: on a trip shared by several customers, if one customer's part of the load is contaminated, what happens to everyone else?
When we presented it, the client had only ever seen one happy path. Now they were looking at their actual business. Every flow after it held up, and invoicing was built on solid ground.
Key decisions
Fill trucks before adding trucks
A big order rarely fits one truck. Scheduling puts trucks that already have room at the top, so the fleet runs full before anyone sends out another truck. The summary tracks scheduled against remaining litres until the order is covered.
Quantity Summary
Wet cargo · PMS · 100,000 ltrs
Est. start 26 Nov, 11:53 am
Est. delivery 28 Nov, 5:07 pm
The voucher, designed against one kind of fraud
The company pays for the fuel, not the driver, so a driver could hand the voucher to a friend and have the friend's truck filled at the company's cost.
So redeeming a voucher is an identity check. The attendant scans the QR and sees the driver's photo and vehicle number from the trip. Then the amount goes in, and the driver signs on the attendant's phone. It can't be submitted without both.
At the pump
Adewale Rasaq B
BUU 599ZDMON/FV/23/06/00006
Adewale Rasaq B
Driver Code · 9964
ActiveMON/FV/23/06/00006
Fueling In ProgressTime since start
00:00
Fuel Voucher
Confirmation form
Voucher redeemed
400 ltrs of PMS to BUU 599ZD
The driver's reading is never the only one
The driver isn't paying for fuel either, so nothing stops a personal detour on company fuel. The driver enters the odometer before a voucher can be redeemed, but the distance doesn't rest on that number. The attendant records it at the pump and the customer at delivery, and neither has a reason to cover for the driver.
The driver enters a reading too, before the voucher is redeemed. It's checked by two other people.
An order in five steps, because five things are decided
The rebuild made ordering longer, so a summary sits beside every step: cargo, parties, route and times. You always see what you've already decided while you fill in the next part. Cargo type decides everything after it, so it's a big card with a photo, not a dropdown. (That one was already there when I joined.)
Showing the handoff, not the apps
Five apps that talk to each other are almost impossible to review one screen at a time. So for fueling, we showed the client the exchange itself: the driver's screen beside the attendant's, every step down the side. The client responded to it better than anything else we showed, because they could follow the whole exchange instead of imagining it.
And before every client call, I spent an hour clicking through the whole prototype, so the client never hit a dead end in a demo and their feedback stayed on the product.
What I couldn't do
I never spoke to a single user: no drivers, attendants, depot managers or customers. Our team spoke to our founder, the founder spoke to the client's CEO, and everything came down that line. Nobody on the team watched a driver use the app.
With the same access I'd design it the same way, but it wasn't tested with users, and I won't say it was. One day at a depot would have been worth more than a month of client calls, and I'd push harder for that now.
Outcome
The system went live, and it held as the fleet grew 50%, from about 10,000 to 15,000 trucks. Around ₦40 billion in transport value runs through it every day. I won't claim the design grew the fleet. What I can stand behind is that the foundation we rebuilt in those first weeks held.
"Implementing Transporter has been a game-changer for our fleet management. It's like having a digital co-pilot that ensures safety, efficiency, and control every step of the way."
What I learned
The most important decision here came before I designed a single screen, and it wasn't design. It was convincing three people senior to me to reopen work they'd already approved. What worked was dropping the argument about being right and making it about cost.
And when the product is fuel moving through Nigeria, a design mistake can mean stolen fuel, lost money, or worse. Almost every hard decision here exists because someone in the chain has a reason to lie. That's a different problem from designing something people enjoy, and it's one I've come to enjoy.
