Redesigning Kuda's mobile and web onboarding flow across both platforms, reducing 63 clicks to under 30 and lifting overall account creation conversion from 13% to over 20%.
ROLE
Product Design
PLATFORM
Mobile
Web
BACKGROUND
Kuda is a leading digital bank in Nigeria serving over 7 million customers. Despite strong product growth, one problem persisted quietly in the background — getting a new user from download to open account was harder than it needed to be.
The onboarding flow had a conversion rate of around 13%, meaning roughly 4 in every 5 users who started the process never completed it. With 63+ interactions required to open an account across both mobile and web, and each interaction demanding a small but real amount of mental energy, the friction was adding up — and users were dropping off.
This project was a structured design experiment to find out: what happens to conversion when we reduce that friction?
Problems
The onboarding journey was split into two phases. Getting from download to first login required 20 clicks across 12 screens, collecting just 4 pieces of data — email, password, username, and phone number. That part was manageable.
The real friction started after first login. From there, users faced 43 clicks across 31 screens to complete account opening — collecting 18 pieces of data including KYC requirements like BVN or NIN verification, a selfie match, transaction PIN, passcode, and address. Every piece of data lived on its own screen, with no field grouping, no bundling of related actions, and no smart defaults to reduce manual input. The same fragmented experience existed across both mobile and web.
The data confirmed it — roughly 80% of users who started onboarding never made it through.
*Old onboarding flow — 43 screens / 63 clicks (mobile)
Research & Benchmarking
To understand how Kuda's onboarding compared to the broader market, we conducted a competitive analysis across 8 digital banks and fintechs globally — including Opay, PalmPay, Carbon, FairMoney, Monzo, Chime, and Revolut.
The findings were stark. The industry standard for a similar volume of data collection was 15–25 screens and 25–35 clicks. Kuda was running at nearly double — 43 screens and 63 clicks — while collecting a comparable amount of data to most competitors.
The gap wasn't about what we were collecting. It was about how we were collecting it. High-performing competitors shared a consistent set of UX patterns that Kuda's flow lacked entirely:
Bundling related fields together (e.g., Name + Date of Birth)
Smart defaults and autofill to reduce manual input
Replacing confirmation screens with lightweight toast notifications
Combining actions like camera permissions and selfie capture into one step
Inline validation instead of separate confirmation screens
Chime completed onboarding in 15 screens and 25 clicks. Revolut in 18 screens and 28 clicks. Both collected a similar volume of data to Kuda. The opportunity was clear — this wasn't a data problem, it was a design problem.
My ROle
I was the sole designer on this project, working closely with the Product Manager who led the problem definition and experiment framework. My responsibilities spanned the full design process — from analysing the existing flow and contributing to the competitive research, to redesigning the affected screens across both mobile and web, and specifying the exact changes needed for each experiment stage.
This wasn't a typical redesign brief. The work had to be structured as a controlled experiment — every design change needed to be scoped, isolated, and measurable. I worked within a LaunchDarkly feature flag framework, designing two distinct variants of the onboarding flow that could be served to different user groups simultaneously for A/B testing.
That constraint shaped every decision. Rather than redesigning the entire flow at once, we prioritised the highest-impact, lowest-risk changes first — and I had to be deliberate about what we changed in Stage 1, what we deferred to Stage 2, and why. It was as much a strategic exercise as it was a design one.
Solution
Stage 1 focused on the highest-impact, lowest-risk changes — reductions that could be implemented quickly, tested cleanly, and measured in isolation without disrupting the core flow or compliance requirements. All changes were applied across both mobile and web.
1. Screen Reduction
The old flow was littered with standalone confirmation screens that existed purely to tell users something had been done. None of these required user input. We replaced them with toast notifications, removing multiple screens in one move. We also merged screens collecting related information that had been unnecessarily split — combining "What you'll need", "Get Started", and the address primer into a single screen. The Choose Account screen, only relevant for non-Nigerian users, was made conditional — skipped entirely for the majority of Kuda's user base.
*New onboarding flow — reduced screens (mobile)
2. Auto-Focus
On every data entry screen, the relevant input field now auto-focuses on load and the keyboard appears automatically. A small change, but across a long flow those extra taps compound quickly.
*Auto-focus on data entry screens
3. Experiment Control
All Stage 1 changes were isolated behind a LaunchDarkly feature flag, allowing us to run a clean A/B test across both platforms simultaneously. Every design decision was also a hypothesis we could measure. The result: a flow reduced from 43 screens to approximately 22 — roughly a 50% reduction in screen count while collecting the same data.
Impact
Overall conversion from Onboarding Started to New Account Created improved from ~13% to over 20% — a 7 percentage point increase against a target of 2–5%. The improvement held consistently across January 2026 and the broader January–March 2026 period.
Address submission conversion jumped from 83% to 95% — a 12 point improvement at one of the flow's most historically painful steps
BVN or NIN Phone Completion improved from 42% to 77% — a 35 point swing representing tens of thousands of additional users making it through.
Over the three month period, 35,900 new accounts were created vs 27,600 in the same period the prior year — nearly 8,300 additional accounts despite fewer total registrations starting the flow.
The redesign didn't just hit the target. It more than doubled it.
Mixpanel Data
Note on liveness check
The significant drop between "Liveness Check Started" and "New Account Created" is not a product of this experiment. The liveness check is handled by a third-party SDK, and research showed that a large portion of drop-offs at this step are caused by device incompatibility — many users on lower-end devices are unable to complete the biometric check successfully. This is a known limitation outside the scope of Stage 1, and the team is actively exploring alternative integrations that support a wider range of devices, including low-end ones. Resolving this step represents the single largest remaining opportunity to improve end-to-end conversion.
Takeaways
Less is a design decision:
Removing a screen isn't just a UX improvement, it's a product decision with measurable consequences. Every screen we cut was a deliberate choice backed by data, user feedback, and competitive benchmarking.Constraints make you more creative:
Designing within a feature flag framework meant every change had to be isolated, testable, and reversible. That constraint forced sharper thinking — identifying the highest-leverage changes and sequencing them deliberately.Toast notifications are underused:
Replacing full confirmation screens with toasts was one of the simplest changes we made — and likely one of the highest-impact. Toasts delivered the same information in context, without breaking the user's momentumCompetitive research is a design tool:
The benchmarking exercise directly shaped the solution. Seeing that Chime achieved full onboarding in 15 screens while Kuda needed 43 gave us a concrete target and a clear mandate.
