Q8
Product design
/
2023–2025
UI and UX design, user flows, design system, feature design, developer handoff
One portal, two operations that behave nothing alike. A fuel refund takes days and goes through a person: a receipt photographed at the pump, an administrator reviewing it in a back office, emails keeping the driver posted in between. A parking session takes seconds and goes through a system that may or may not answer. Same driver, same app, and both have to read as one product.
I designed all of it, twice – the first version of this product and its rebuild – along with the back office behind it and the emails that come out of it.
One portal for two things: claiming back money spent on fuel, and starting a parking session.
A driver can run more than one truck, so I built licence plates as a small fleet list: add one, wait for it to clear approval, then make it active. Only the active plate can start a parking session or file a claim, and neither the active plate nor one still pending can be deleted – only the ones already cleared. Three states, and what can be done to a plate follows from which one it is in.
A driver’s plates, each with its own vehicle type and status – only one can be active, and a new one waits for approval first.
Parking is a map of zones, a rate, and a cut-off set before the session starts, so it can never run longer, or cost more, than intended. It runs on an outside provider’s system, so I designed the failure cases as carefully as the flow itself. A dead connection needed as much design as a working one: the driver sees what happened, that a retry is underway, and how many attempts have been made.
Parking, working and not – left, a zone with its rate and cut-off set; right, the provider failing to respond, with the retry count showing.
A refund claim needs a photograph of the till receipt and a reason written out – forgetting the company card and paying with a personal one, for example. An open field, not a dropdown: the ways a driver ends up paying out of pocket don’t fit a fixed list.
Filing a claim – the photograph of the till receipt, and beneath it an open field for the reason the refund is being asked for.
A submitted claim doesn’t disappear into a queue. A status email goes out the moment it is received, saying roughly how long the review takes, with the receipt attached. On the other end an administrator works through incoming claims in a back office: a request table, filters, and a detail panel putting the uploaded receipt next to the accept or decline. The app, the back office and the emails all came from the same place – Q8’s logo gave the colours, and the layout, components and patterns were built out from there, so the three surfaces read as one product rather than three tools that happen to share a client.
The other half of the loop – the status email sent the moment a claim is queued, with the receipt attached.
Two services that work nothing alike, three surfaces, and one of them running on somebody else’s system. The driver is meant to notice none of that.