The Problem
Getting a debit card in markets like Nigeria, Ghana, or Kenya wasn't a digital problem, it was a structural one. Legacy bank infrastructure required customers to visit a branch, complete paper forms, and wait three to seven days for fulfilment. For a significant share of account holders, that friction meant never getting a card at all.
The business case was clear: remove the offline dependency and you unlock a dormant user base, cut branch congestion, and grow card-linked transaction volume. What wasn't obvious was how to do it inside the real constraints: multiple card scheme APIs (Mastercard, Visa, Verve, AFRIGO), varying KYC requirements across five markets, and a user base for whom this would often be their first fully digital banking interaction. That last constraint shaped everything.
My Role
I came in as the only designer. No handoff, no existing research, no component library. My first job wasn't to design, it was to define what we were actually building. I worked directly with one PM and three engineers: six weeks of design that got us through POC at our first test bank, GTBank, and 21 weeks total to launch in a live branch.
Three early decisions shaped everything that followed.
I scoped the MVP by cutting. Early conversations had card customisation and multi-card issuance in v1. I made the case to remove both: they added 2+ weeks of build, introduced compliance overhead, and had near-zero value (or were outright friction) for users encountering digital card issuance for the first time. We cut them. Neither made it into v1.
I made the design system a business argument, not a designer preference. The PM wanted to move fast and clean it up later. I ran the numbers: one week of system investment upfront versus an estimated 2+ weeks of compounding handoff friction across the build. We built the system. It paid back inside the first month, and two other product teams later built on it.
I also built the front end for the card request-and-processing flow myself before handing it to engineering. On a regulated card flow, that mattered: it killed a whole category of handoff misreads, took time out of engineering's build, and meant the interaction I'd tested was the exact interaction that shipped.
Research & Discovery
At first the problem looked like straightforward digitisation: let customers request a card without visiting a branch. Discovery showed it was more structural. Card issuance sat across branch operations, KYC, scheme integrations, market-specific rules, and user trust, and designing a clean digital form on top of a broken offline process would have solved nothing.
I combined user and stakeholder discovery to understand both the customer journey and the backstage service model: interviews with cardless and abandoned-request users, conversations across branch, compliance, product and engineering, and service blueprinting to find the operational failure points. Five insights changed the product.
- 01The barrier was access, not demand. Users wanted cards; branch visits, paperwork, queues, and unclear timelines made getting one feel too costly. The opportunity wasn't to digitise the request, it was to remove the offline dependency.
- 02KYC was the biggest hidden blocker. Users often didn't know whether their account was even eligible until late in the process, which produced confusion and failed requests. Eligibility had to surface upfront, before users committed.
- 03Trust mattered as much as speed. Requesting a card this way was a high-trust banking action. Fees, identity requirements, collection, activation, and PIN setup had to be explained in plain language.
- 04Scheme and market complexity had to stay backstage. Users cared about practical outcomes: where the card works, what it costs, how fast they get it, not which scheme sat behind it.
- 05Instant issuance changed the rollout strategy. Cards could be printed instantly at the machine. That shifted the MVP away from delivery and toward instant issuance first; delivery introduced operational complexity (addresses, couriers, tracking, failed delivery) we could defer.
From Platform to Infrastructure, the Case for V2
After launch, I pushed for something that wasn't in scope.
The CVM had one job: issue cards. But the same hardware was already installed in branches across five countries, already trusted by customers, already integrated into bank systems. The banks had paid for the machine and the integration, adding service capabilities on top had marginal cost relative to the ROI of deflecting in-branch service volume.
I brought that argument to leadership: a machine that could handle account opening, funds transfer, card hotlisting, and complaint logging didn't just issue cards, it replaced the entire category of routine in-branch requests that consumed customer-service-officer time. The argument landed.
Results
Within 6 to 12 months of launch:
The v1 design system was adopted by two other product teams as the foundation for their own builds.
That latent-value reframing changed how the business talked about Pryme internally, and it's what made the investment case for v2 straightforward. The day we launched with GTBank, the bank trended on Twitter to raving reviews.
What I'd Do Differently
We launched with strong satisfaction signals but almost no behavioural visibility. For the first 60 days we were inferring where users dropped off instead of seeing it, which made post-launch iteration slower than it should have been. I should have made analytics instrumentation a design requirement during the build, not an engineering backlog item: funnel tracking specified in the design phase means you act on real drop-off data in weeks, not months. I've carried that into every 0→1 engagement since.