QuickMart
The backend for a chain of 200+ stores and fuel stations across Nigeria, rebuilt from a system that had never been designed. Same client company as Transporter.
- Client
- QuickMart
- Role
- Product designer
- Team
- 3 designers
- Timeline
- 6 to 8 months
- Status
- Live across the network
Where this started
QuickMart is a convenience store attached to a petrol station, in every state of Nigeria. It's run by the same company as Transporter, and it came with the same problem: a backend built by developers with no designer involved. No documentation, no contact with the developers, and one person on the client side, the CEO, who I could only reach through my founder.
I'd just come off Transporter, so I knew the shape of the problem. QuickMart was worse. Transporter had broken flows. QuickMart had whole sections of data with no forms behind them.
Reading a system with no manual
The account we were given was a dummy, and every customer in it looked different. There was no "add customer" flow, which is what would normally tell you what a customer is made of. So I opened record after record and wrote every field I saw into my notebook, until I had a full customer.
Customer
The differences turned out to be useful: a customer who'd bought something had purchases, one with vouchers had vouchers, a business had delegates. Before Jay could design a screen, someone had to work out what it should contain, and that was my job. When something was unclear and I couldn't reach the CEO, we designed it the way we thought it should work, and the client confirmed it or added a field or two.
The Monday demo
The client didn't want our process. Every Monday they wanted to open a prototype and see more than the week before. So we finished one full flow at a time before showing it: for customers, the form, then the list, then the three types, then one type end to end.
The prototypes behaved like real software. Every form had an empty and a filled state, every dropdown opened, every list filtered. The client's feedback landed on how it worked, and a hole in a flow showed up while we wired the prototype, before a developer built on it.
Key decisions
Three kinds of customer, kept apart
Three pricing models, three permission models and three ways of redeeming, in one product. The risk is staff acting on the wrong one. So the account type is tagged everywhere, the three never share a screen, and the layout stays the same so nobody relearns the product.
One voucher list, every state
A voucher here is a full transaction, and it moves through 8 states. Redemption works per item, so a customer can collect some products and leave the rest. I found the states by reading the old system. In the demo, instead of showing one and asking the client to imagine the rest, we built the list so every voucher was in a different state, and opened them one by one.
Voucher transfer was the client's idea. With no delivery, someone who ordered online but couldn't collect was stuck. Now the voucher moves to someone who can, with their ID recorded, and the order location and the pickup store are shown as two maps, since they're often different places. My part was making it clear where the voucher stands.
Two stock thresholds, so a store never runs dry
The old system had nothing to stop a store running out. Restocking isn't instant: a store reorders from a hub, and the hub takes days to deliver. So a single "out of stock" flag fires far too late. Jay and I added two thresholds. The first is an early warning and the point to reorder. The second means refill now. Between them, the order has time to arrive.
Pricing without an MRP
Nigeria has no MRP, so every store sets its own price for every product, and it varies by region, by store and by customer type. Prices here don't get rewritten, they drift: up ₦2 or ₦3, or a small percentage. So we designed around adjusting, not retyping. Pick a region or a store, pick a product or everything, and move the price by a percentage or a naira amount.
| Product | Alaka Store | MRS Creek Road | Victoria Island |
|---|
What was hard
Nothing broke the way the order flow did on Transporter. The hard part was understanding the business: SKUs and variants, bundles, three kinds of customer in one store, prices per customer and per region, restocking from hubs. Learning it took as long as designing for it.
And as on Transporter, I never spoke to a user: not a store manager, a corporate admin, a delegate or a customer. Everything came from the client's CEO through my founder. The rules came from the client. What we owned was making them usable.
Outcome
The system is live across QuickMart's stores. I left shortly after, so I don't have usage numbers. What shipped: three customer systems, 200+ stores pricing on their own, and an 8-state voucher system with per-item redemption, rebuilt in 6 to 8 months from a dummy account and no documentation.
What I learned
This project tested one skill: reading a system nobody could explain and rebuilding it from the inside. Most of my real work happened in a notebook, opening record after record until the model showed itself. Having done Transporter for the same client first is why I could move fast. At this size, the whole job is keeping it clear enough for a team to run.
