Card Delivery Status — Closing a Visibility Gap.
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. I 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.
This feature hasn't launched publicly, so the client, product name, and interface are withheld. No screens here, by choice. What follows is the reasoning and the structure I arrived at, and I'm happy to walk through the actual work in an interview.
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 gap
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.
The part nobody designs
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.
Benchmarking three banks that already had it
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.
Deriving the stages instead of inheriting them
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.
Designing the failure state as a real state
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.
Five states, not four. 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,” ready to activate. When one doesn't, that fork is a real state too: a failed delivery is stated plainly, paired with why the old card is now deactivated, with the free reorder sitting right there instead of sending anyone to call support.
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
Then one of two outcomes
Delivered
Card received, ready to activate
Delivery failed
Card returned to the bank, old one deactivated, reorder free
The state sequence, not the interface. Redrawn here since the screens stay private until launch.
This one is designed and handed off, still waiting on a launch date, so there's no adoption number to report 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.
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.
More case studies.
See the rest of the portfolio — design systems, dashboards, and everything in between.