Onit Bank
Designing For Trust & Viral Growth
Onit is transforming banking in Africa by offering free, seamless transactions and financing options tailored to the needs of underserved M/SMEs in Kenya. Our mission is to empower individuals and businesses to grow and manage their finances effectively, leveraging innovative solutions to promote financial inclusion and drive economic development through a fair, digital-first banking ecosystem.
The objective:
Banking is broken: Launch a zero-fee digital bank
Build trust in a price-sensitive, competitive market
Achieve growth without high marketing budgets
Seamlessly migrate credit users to the banking platform
Mapping constraints:
Business Constraints
❌ Limited marketing budget
❌ Skewed existing user base primarily expecting loans
❌ Needed to achieve viral growth (CAC had to be near zero)
❌ Tight timeline: 6 months to launch
Technical & Regulatory Constraints
❌ Integration with existing banking infrastructure/ processes
KYC regulatory requirements
Consumer protection disclosures (transparent pricing, T&Cs, data protection, real time transaction notifications & receipts)
❌ Real-time transaction processing limits
❌ Intermittent connectivity
❌ Low-end Android devices + feature phones
User Constraints
❌ Distrust of "free" financial products
❌ M-Pesa behavioral lock
❌ Very high Day 7 and Day 30 churn norms in market
❌ Low digital literacy
How do you build trust and drive viral adoption when users are skeptical, locked into a competitor's network, and you have limited resources?
The Problem
Kenya's 2.4M SMEs face an expensive & fragmented banking system.
M-Pesa charges 1-3% per transaction and controls 95%+ of mobile money movement in Kenya. Traditional banks require $500+ minimum balances, and account opening takes weeks. This leaves 65% of SMEs to operate entirely in cash, losing an estimated $2B annually to inefficient financial establishments, limiting their ability to grow.
My Role: Lead Designer, Growth.
Lead the design of trust-building experiences and viral growth mechanics to drive app adoption and retention.
Team: Cross-functional team of designers, product managers, engineers, and operations building for iOS, Android and USSD
Key Finding: The Cash Trap SMEs relied heavily on cash transactions and informal lending networks, not by choice, but because:
Traditional banks had high fees and minimum balances
M-Pesa was expensive for business transactions
Informal networks (family, suppliers) filled the credit gap
What This Meant for Design: We couldn't just build "a better banking app"; we had to design for the entire ecosystem of relationships: how merchants pay suppliers, how they collect from customers, how they access credit, and how they build trust in a new system.
The Onit Ecosytem
To design the right solution, I needed to understand how money actually flowed through the economy. We studied the broader financial ecosystem in Africa, focusing on how SMEs interact with consumers, suppliers, and financial institutions. Our findings indicated that SMEs often rely on cash transactions and informal lending networks due to the inefficiencies and high costs associated with traditional banking.
SMEs weren't avoiding digital finance because they didn't understand it, they were rationally opting out of systems that didn't serve them.
I created this Onit Persona diagram to explain the ecosystem’s interconnectedness to the Product, Engineering and Design Teams.
*Image created using Midjourney and FigJam
Research & Design Process
Phase 1: Deep User Research
Conducted 40+ interviews with SME owners across 3 cities
Synthesized insights from 1,000+ survey responses with the lead product manager
Key findings: Users didn't trust "free" but were desperate to save money
Users had no idea how much they were spending on M-Pesa fees month on month
Phase 2: Constraint Mapping
Mapped regulatory requirements vs. user friction for KYC flows
Identified viral mechanics used by successful products (Monzo, Chipper Cash, Cash App, NCBA)
Defined north star metric: Viral coefficient K>1
Phase 3: Rapid Prototyping & Design Iterations
Created 5 different approaches to communicating "free"/ cost savings
Tested trust-building elements with dedicated focus groups
Iterated on referral flow designs (tested 2 variations)
Phase 4: Constraint-Driven Design Decisions
Made key trade-offs (detailed next)
Built design system for velocity
Prepared for beta launch
Key Decisions & Tradeoffs
#1: Tiered KYC
The Constraint Conflict:
✅ Regulatory requirement: Full KYC before account access
❌ User need: Immediate value or high drop off
❌ Business need: High completion rates
Options:
Full KYC = regulatory compliant but 27 steps to full completion - high drop off.
No KYC = Instant access, great KYC but non compliant
Tiered KYC = Balanced approach with more techincal complexity
Decision: Tiered verification
Created "first basic account" with transaction limits
Users could add/ send small amounts immediately
Progressive verification unlocked higher limits and business features
Clear communication about what they could do now vs. later with business accounts
The trade-offs
✅ Immediate value → reduced early churn
❌ More complex system to build (engineering push-back)
Multiple account states instead of one (for credit users as well)
Transaction limits had to be enforced dynamically
More complex testing, monitoring, and support tooling
Why it mattered
We turned KYC from a blocker into a retention lever. As this was the first introduction to the product, the engineers were on board with the higher lift required for tiered KYC.
Impact:
Users who completed Tier 1 had 3× higher Day 7 retention than those forced into full KYC upfront.
#2: Designing for Trust and Transparency
The Constraint Conflict:
✅ Business model: Zero fees
❌ User skepticism: "Free" seemed too good to be true
❌ Need to differentiate: M-Pesa was familiar (even if expensive)
My designs to explore different approaches to communicating "free"/ cost saving on transactions
Design Decision: Show, Don't Tell
Designed real-time cost comparison: "Lose KES45 on M-Pesa fees. Send for KES 0 Onit.
Created a running "total saved" counter dashboard
Made fee comparisons on transactions visible and simple
Later: Test social proof: "Your friend Jane saved KES 450 this month"
The Trade-offs:
✅ Made "free" credible through demonstration and loss aversion
✅ Created competitive differentiation
❌ Required complex calculations in real-time
❌ Set expectation that we'd never charge fees (business constraint)
Why It Worked: Users needed proof, not promises. Showing real time savings built trust faster than any marketing message.
#2: Designing for Trust and Transparency
The Constraint Conflict:
✅ Business model: Zero fees
❌ User skepticism: "Free" seemed too good to be true
❌ Need to differentiate: M-Pesa was familiar (even if expensive)
My designs to explore different approaches to communicating "free"/ cost saving on transactions
Design Decision: Show, Don't Tell
Designed real-time cost comparison: "Lose KES45 on M-Pesa fees. Send for KES 0 Onit.
Created a running "total saved" counter dashboard
Made fee comparisons on transactions visible and simple
Later: Test social proof: "Your friend Jane saved KES 450 this month"
The Trade-offs:
✅ Made "free" credible through demonstration and loss aversion
✅ Created competitive differentiation
❌ Required complex calculations in real-time
❌ Set expectation that we'd never charge fees (business constraint)
Why It Worked: Users needed proof, not promises. Showing real time savings built trust faster than any marketing message.
Design & Documentation
With research insights in hand, I began designing Onit to address the identified challenges. Key design decisions included:
Digital KYC Process: Enabling users to open an account in under two minutes using a digital Know Your Customer (KYC) process.
Zero Transaction Fees: Allowing SMEs to collect revenues from bank transfers and mobile money providers without incurring transaction fees.
Simple Interface: Creating an intuitive, user-friendly interface for both SMEs and consumers to manage their finances effortlessly.
The design process began with competitor research to understand the merchant’s current realities and service offerings. I went through the onboarding and KYC journeys of multiple African and non-African financial apps. Chipper Cash, NCBA, NALA, and Abeg to name a few. This helped us understand the number of steps and common design patterns merchants were used to.
I tested our user journeys and developed interactive prototypes, which we tested in the field to gather feedback. These iterations helped us refine our designs based on real user input. We studied countless user flows on UXcam and held in-person design workshops with users to capture their feedback early on in the design process.
Developing a design system at this point was key to establishing a consistent design language and reusable components that would enable us to design for speed as we included new features and expanded our product offering. Documenting these design standards was crucial to maintaining coherence across the platform and allowing designers in the team to understand the decisions made along the development process.
Reduction in Support Burden Through Self-Service Design
The Problem: Credit repayment flows inherited from Shara created confusion around loan terms, due dates, and payment options - generating high support ticket volumes.
My Approach:
Analyzed top 50 support ticket categories to identify pain points
Conducted usability testing on existing repayment flows revealing critical confusion points
Researched SME cash flow patterns showing irregular income cycles
The Solution:
Redesigned loan repayment interface with clear visual hierarchy and plain-language explanations
Introduced flexible payment scheduling aligned with SME cash flow realities
Created in-app education module explaining digital banking fundamentals for first-time users
Designed proactive notifications for upcoming payments and available payment options
Impact:
Support ticket volume related to payments decreased by over 60%
Support cost per active user substantially reduced
User satisfaction with repayment experience notably improved in surveys
Key Design Decisions & Rationale
1. Offline-First Architecture
Decision: Designed transaction flows to work with intermittent connectivity
Why: Field research revealed unreliable data access in many merchant locations
How: Created queuing system allowing users to initiate transactions offline, completing when connectivity restored
Result: Substantially reduced failed payment attempts and user frustration
2. Tiered KYC Approach
Decision: Balanced regulatory compliance with user friction through progressive verification
Why: Users needed immediate access but full verification required time
How: Instant basic accounts with transaction limits, unlocking higher limits as verification completed
Result: Minimized drop-offs while maintaining regulatory compliance
3. SMS Fallback Experience
Decision: Created parallel SMS-based interface for feature phone users
Why: Not all target users had smartphones or reliable data
How: Designed USSD menu flows mirroring core app functionality
Result: Captured significant additional market segment otherwise excluded
4. Plain Language and Education
Decision: Removed financial jargon and built in-app learning
Why: Many users were first-time digital banking users
How: Rewrote all copy at 6th-grade reading level, created contextual tooltips and help modules
Result: Measurably improved task completion and reduced confusion-based support tickets
#SendOnit
#GetOnit
#SaveOnit
#SendOnit #GetOnit #SaveOnit
Testing & Iteration
Prototype Testing:
Developed and tested 15+ interactive prototypes with target users in field settings
Iterated rapidly based on real-time feedback from actual merchants
Behavioral Analysis:
Monitored UXCam session recordings weekly to identify friction points
Conducted quarterly usability testing with 10-15 users per cycle
Tracked and addressed drop-off patterns at each funnel stage
Beta Launch Learning:
Launched beta to controlled user group for real-world validation
Collected continuous feedback through in-app surveys and support channels
Made iterative improvements based on actual usage patterns vs. assumptions
Cross-Functional Collaboration:
Ran bi-weekly design workshops with PM and engineering to align on goals
Facilitated monthly retrospectives to improve team process
Collaborated closely with operations team on KYC requirements and fraud prevention
The Onit Ecosytem
We studied the broader financial ecosystem in Africa, focusing on how SMEs interact with consumers, suppliers, and financial institutions. Our findings indicated that SMEs often rely on cash transactions and informal lending networks due to the inefficiencies and high costs associated with traditional banking. We also examined how digital payment solutions and mobile money systems are being adopted and used across the region.
I created this Onit Persona diagram to explain the ecosystem’s interconnectedness to the team.
*Image created using Midjourney and FigJam
Persona Development
A crucial part of our research was developing archetypes and personas. I facilitated a persona deep dive with the Product managers, design team and members from the operations and engineering teams. By including different members of the team with insights into the customer journey at various touch points, we were able to holistically analyze the opportunities for growth and better empathize with our users, understanding their needs, frustrations, and motivations.
I used the Jobs to Be Done (JTBD) framework to structure our findings. This is one of my favorite frameworks to help identify existing, everyday jobs users are trying to accomplish, the problems they face, and how they measure success. For example, a corner shop owner’s job was to manage daily transactions efficiently, while a cash office manager’s job was to ensure timely salary disbursements.
By focusing on these jobs, we designed solutions that directly addressed the core needs of our users.
Learnings:
Context is Everything: Designing for emerging markets requires deep understanding of infrastructure constraints, cultural behaviors, and economic realities. Solutions that work in developed markets often fail without significant adaptation.
Trust Must Be Designed: In markets with limited financial literacy and history of exploitation, every interaction either builds or erodes trust. Transparency isn't a feature—it's a foundation.
Systems Thinking Scales Impact: Individual feature designs create local improvements, but design systems multiply team capacity and ensure consistent experiences as products scale.
Metrics Tell Stories: While not every metric was available, connecting design decisions to user behavior and business outcomes helped stakeholders understand design's strategic value.