Cross-Border Remittance App: Lead Product Designer, July 2020–present.
I joined a cross-border remittance platform with no design system and no documented process and built both while the company grew to 100,000+ users and $10M+ in monthly transactions across NGN, CAD, GBP, and AUD corridors.
Lead Product Designer
My Role
Web & Mobile (iOS + Android)
Platform
Onboarding, KYC, Transfers, Design System
Focus
47% → 65% KYC completion
Outcome
The Business Stakes
Remittance runs on trust. People are moving money for family, rent, and business obligations across borders, often in their first digital-finance experience. A confusing flow doesn't just cost a conversion; it costs someone the ability to pay for something real. Each market (Nigeria, Canada, the UK, and Australia) also has its own regulatory requirements, so the product couldn't be "one clean flow." It had to hold up across four sets of rules without splitting into four products.
My Role
I joined as the design function's first senior hire. There was no component library, no documented pattern language, and every screen had been built ad hoc. I owned the full lifecycle (research, journey mapping, wireframing, prototyping, usability testing, and handoff), first on my own, then with Compliance and Operations as the team and product grew.
The Hard Problem
Design one interface flexible enough for very different users (varying financial literacy, languages, and devices) across four regulatory markets. Per-market UIs would kill delivery speed; one rigid pattern would kill usability.
Key Decision
Stage KYC instead of asking for everything upfront: The interviews showed long forms and heavy typing were stopping people. Splitting verification into stages raised completion from 47% to 65% without dropping a single compliance check.
Build one flexible system, not four country versions: I created a component library that adapts to each corridor's rules, so the team designs once instead of four times. This cut design delivery time by 70%.
Bring Compliance in early: I worked with Compliance and Operations from the first draft, so every flow met regulatory requirements before engineering started rather than being reworked afterwards.
Design for different reading levels and devices from the start: I applied WCAG standards and inclusive patterns so the same flow works for users with varying financial literacy, languages, and devices.
Research:
Why people weren't getting verified
Fewer than half of new sign-ups were completing verification. I ran 20 customer interviews to find out why. The answer was consistent: the KYC flow asked for everything at once, with long forms and a lot of typing.
That led to the decision behind the rest of the system: staged KYC. Users give basic details first, and document checks follow in a later stage. Every compliance check stayed; only the order and the effort changed.
In the month after launch, the share of new users completing verification rose from 47% to 65%.
Solution:
The result is a component-based design system spanning onboarding, KYC, send-money, and wallet flows built to flex across markets rather than fork into separate versions per country. A single send-money flow adapts its verification steps, language support, and literacy-level patterns based on the corridor and user profile, instead of requiring four parallel designs. Every pattern in the system carries documented rationale, so new designers and engineers can extend it without re-deriving the reasoning from scratch.
Impact
KYC completion rose from 47% to 65% in the month after the staged flow launched.
Staged KYC became the default pattern across the product, not just the original test flow.
Design delivery became 70% faster once the design system gave the team (which grew from one designer to three) a shared language instead of repeated decisions.
100,000+ users and $10M+ in monthly transaction volume.
What I'd Do Differently
I'd tested the staged KYC pattern with Compliance earlier. I spent longer than I needed building the case internally before bringing them real user data; the evidence would have shortened the conversation and made the decision less personal. I'd also start the design system on day one instead of retrofitting it once the team grew. It's tempting to treat systems work as a luxury for later, but it's cheapest when you build it before you need it.
©2026 All Rights Reserved