E-commerce · Fintech · BNPL
Paysmosmo
Redesigning trust, one checkout step at a time.
Paysmosmo had a compelling idea: let Nigerians buy electronics on flexible six-to-eight-month payment plans. But a confusing checkout, a broken mobile experience and disconnected financial tools were pushing users away before they ever completed a purchase. We had 8 weeks to fix it.
Introduction
Paysmosmo came to our team with a real problem and a real opportunity. Nigerians were already stretching their budgets creatively: borrowing from family, using informal savings circles and buying on credit from local shops.
Paysmosmo wanted to formalise that behaviour digitally. Buy the gadget or appliance you need today, and pay it back over six to eight months, transparently and predictably.
The idea was sound. The product wasn't. The checkout was confusing, the site barely worked on phones, and the savings features were buried where nobody would find them.
After 8 weeks of research, iteration and design, we had a solution ready to build. The client withdrew while development was under way.
The problem
When we first explored the existing product, three things became immediately clear: users were arriving, getting confused, and leaving. The platform had the right ingredients (a catalogue, a BNPL payment model, savings tools and investments), but they didn't work together, and several of them were broken.
A checkout nobody could finish
Multiple unclear steps, no progress indicator, and no sight of the monthly instalment or total repayment until the very last screen. Most people abandoned it.
A site that didn't work on phones
It was designed desktop-first. On mobile, where most of the audience browsed, buttons overlapped, forms were nearly unusable and key information was cut off.
Financial tools that felt bolted on
Savings and investments lived in a side menu nobody opened, with no link between buying something and managing money. Two different apps sharing a URL.
No visual consistency
Sections had clearly been designed at different times by different people. For someone deciding whether to trust a platform with their payment details, that matters enormously.
Research and discovery
We spent the first two weeks in research mode. The goal wasn't to validate the redesign we already had in mind; it was to understand what was actually going wrong, and why.
Stakeholder interviews
Structured interviews with the founding team and product manager revealed three things:
- The team knew the checkout was broken, but not where people were leaving: the flow had no analytics at all.
- Savings was a strategic priority, not a nice-to-have. The business model depended on it, but the design didn't reflect that.
- The target user wasn't who we assumed. Not young urban professionals, but traders and micro-entrepreneurs in their late 20s to 40s, with irregular income, who make large purchases strategically.
Conversations with potential users
We spoke with eight potential and current users who matched the target profile. Patterns emerged quickly:
- Trust was the primary barrier. "How do I know the site won't just take my money?" came up in almost every conversation.
- People wanted the total cost upfront. "I just want to know what I'll pay each month and what it adds up to." The product only showed this at the final step.
- Mobile was the default. Without exception, everyone said they'd use it on their phone.
- Savings felt abstract. People liked the idea, but most had never found the feature. "I thought that was just for transfers," one person said.
Feedback and competitors
The three most common complaints in existing user feedback mapped directly to what we'd heard: checkout confusion, mobile failures and distrust of the payment process. We also audited AliExpress and Jumia for e-commerce patterns, and CDcare and CredPal for BNPL flows in Nigeria. The platforms people trusted most made security visible at every decision point. Trust wasn't assumed; it was designed.
We'd assumed the problem was the checkout. It was deeper: the whole product felt untrustworthy, and the checkout was just where that distrust became a hard stop. The redesign couldn't just fix the steps. It had to fix the feeling.
Design approach
Three principles guided every decision across the 8 weeks:
- 01
Transparency before commitment
Users should know the monthly cost, total cost and repayment schedule before they take any irreversible action. No surprises.
- 02
Mobile is the primary canvas
Every component, flow and interaction designed mobile-first. Desktop would be the adaptation, not the other way around.
- 03
Connect spending and saving
Savings shouldn't feel like a separate product. Every purchase moment is also a financial moment.
Solution highlights
01
Responsive design
Designing mobile-first wasn't a constraint; it was the strategy. We started every screen at 375px and scaled up. That forced real decisions about what was essential above the fold, and gave us a product that worked for the actual user, not an imagined one at a desktop.
02
A simpler BNPL checkout
The original checkout had seven steps with no progress indicator. We redesigned it as four: browse, select plan, review schedule, confirm. The key change was showing the monthly instalment and total repayment on the product page itself, so by checkout the commitment wasn't a surprise. It was a confirmation.
We added explicit trust signals at payment entry: how funds are held, a visible security badge and a clear cancellation policy. These weren't decorative; they responded directly to what users said they needed to feel safe.
03
Integrated financial tools
Instead of a side menu, financial tools became part of the post-purchase experience. After a BNPL order, users can set up automatic savings towards their next instalment. The framing moved from "here's a savings feature" to "here's how next month's payment is ready without thinking about it."
Design process
A component library
Midway through, it became clear the visual inconsistency wasn't a polish problem; it was a trust problem. So we paused feature design for three days and built a component library from scratch: buttons, inputs, cards, navigation, errors, empty and loading states, and the BNPL plan selector.
Iterations
Two of the key component iterations. There were more across the 8 weeks, but the navigation bar and product card show the clearest before-and-after thinking.
High-fidelity designs
Landing pages
Three landing pages: a general page showing the full breadth of the product, a page for the savings tools, and one focused on the online store.
Mobile app
A mobile app mirroring everything in the web app, optimised for smaller screens.
The part that didn't happen
Eight weeks in, the designs were production-ready. Then the client withdrew.
The component library was documented, the prototype covered every core flow, and engineering were already building. I won't pretend that wasn't frustrating. This was a product I believed in.
But it gave me something a launched product sometimes doesn't: a very clear view of what I would have validated, what I would have measured, and what I might have got wrong.
Designing for financial trust is fundamentally different from designing for convenience. In a food delivery app, a confusing UI is annoying. In a BNPL platform, it's a reason to leave and never come back. I've taken that into every financial product I've worked on since.
Want to talk about this project? I'd genuinely like to hear from you.