Digital Banking · Under NDA
A bank shipping physical debit cards to customers' homes, with no way for them to see where the card was. I owned the delivery status tracking: benchmarked three banks that already had it, then designed the part most of them still handle badly, what the customer sees when the card never arrives.
Card delivery
Card being prepared
Request confirmed, card queued for production
Card being printed
Physical card produced at the bank
Handed to courier
Waiting for pickup
In transit
Courier and tracking number surfaced in-app
Delivered
Card received, ready to activate
Card delivery
Card being prepared
Request confirmed, card queued for production
Card being printed
Physical card produced at the bank
Handed to courier
Waiting for pickup
In transit
Courier and tracking number surfaced in-app
Delivery failed
Card returned to the bank. Your old card is deactivated for security.
The full card issuance journey (request, address, PIN, activation) was built by a product design team. My piece was the delivery status: the screen a customer opens after ordering the card to find out where it is. This case study covers that piece only.
The bank had no delivery tracking for physical debit cards at all. You requested one, then waited without knowing anything. Competitors had shipped this years earlier, so we weren't solving a novel problem. We were closing a gap that had stayed open too long.
Tracking the happy path is easy. What kept coming up in my benchmarking was the failed delivery: card undeliverable, returned to the bank, and how little most apps say when it happens. That silence is exactly when a customer starts to panic about where their card ended up.
I studied how Jago, blu by BCA Digital, and Mandiri each handled card delivery, focused on three questions: how many stages they expose, how they notify at each one, and what they do when delivery fails. All three answered differently, and that's what made the trade-offs visible instead of guessed at.
The status stages weren't handed to me. I built the sequence from the benchmarking, aiming for enough steps that the wait feels accounted for and few enough that it doesn't read as noise. Then I checked each one against a state the backend could actually report.
When delivery fails, the backend returns the card to the bank and deactivates it. I designed that as a first-class state, not an error message: say plainly what happened, say the old card is deactivated for security, and put the free reorder directly in that same view.
Printing sits between prepared and handed to courier, because in the benchmarking that gap was exactly where people lost confidence the card was even moving. From there the path forks. Most cards resolve into a plain “delivered.” When one doesn't, that fork is a real state too: the failed delivery is stated plainly, with why the old card is now deactivated and the free reorder right there instead of a call to support. Both endings are shown side by side at the top of this page.
There's no adoption number to report yet, and I'm not going to make one up. What I can point to is the process: the stage sequence came from comparing three banks instead of one team's assumption, and the failed-delivery state went from an unspecced gap to an actual part of the flow.
Reflection
Arriving late to a feature everyone else already has sounds like a disadvantage. It isn't. You get to see where the existing versions go quiet. Every bank I studied tracked a successful delivery well; the one that fails is where the design work actually was.
